Docker で Tomcat、MySQL、Redis をインストールするための詳細な手順

docker 検索 tomcat 

docker プル tomcat

docker run -it -p 8080:8080 tomcat

docker pull mysql:5.6

docker run -p 12345:3306 --name mysql -v /zzyyuse/mysql/conf:/etc/mysql/conf.d -v /zzyyuse/mysql/logs:/logs -v /zzyyuse/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.6
 
コマンドの説明:
-p 12345:3306: ホストのポート 12345 を Docker コンテナのポート 3306 にマッピングします。
--name mysql: サービス名を実行 -v /zzyyuse/mysql/conf:/etc/mysql/conf.d: ホストの /zzyyuse/mysql ディレクトリにある conf/my.cnf をコンテナの /etc/mysql/conf.d にマウントします
-v /zzyyuse/mysql/logs:/logs: ホストの /zzyyuse/mysql ディレクトリの下のログ ディレクトリをコンテナの /logs にマウントします。
-v /zzyyuse/mysql/data:/var/lib/mysql: ホストの /zzyyuse/mysql ディレクトリの下のデータディレクトリをコンテナの /var/lib/mysql にマウントします。 
-e MYSQL_ROOT_PASSWORD=123456: root ユーザーのパスワードを初期化します。
-d mysql:5.6 : バックグラウンドプログラムはmysql5.6を実行します

docker exec -it 操作成功後の MySQL コンテナ ID /bin/bash 

docker exec myql サービスコンテナ ID sh -c ' exec mysqldump --all-databases -uroot -p"123456" ' > /zzyyuse/all-databases.sql

docker run -p 6379:6379 -v /zzyyuse/myredis/data:/data -v /zzyyuse/myredis/conf/redis.conf:/usr/local/etc/redis/redis.conf -d redis:3.2 redis-server /usr/local/etc/redis/redis.conf --appendonly yes 

vim /zzyyuse/myredis/conf/redis.conf

# Redis 設定ファイルの例。
#
# 設定ファイルを読み込むには、Redisが
# 最初の引数としてファイルパスを指定して開始:
#
# ./redis-server /path/to/redis.conf
 
# 単位に関する注意: メモリサイズが必要な場合は、
# 通常の形式では 1k 5GB 4M などとなります:
#
# 1k => 1000 バイト
# 1kb => 1024バイト
# 1m => 1000000 バイト
# 1mb => 1024*1024 バイト
# 1g => 1000000000 バイト
# 1gb => 1024*1024*1024 バイト
#
# 単位は大文字と小文字を区別しないため、1GB、1Gb、1gB はすべて同じです。
###################################### 含まれるもの #######################################
 
# ここに1つ以上の他の設定ファイルを含めます。これは、
# すべてのRedisサーバーに送られる標準テンプレートがありますが、
# サーバーごとの設定をいくつかカスタマイズします。インクルードファイルには
# 他のファイルも同様なので、これを賢く使用してください。
#
# オプション「include」はコマンド「CONFIG REWRITE」によって書き換えられないことに注意してください
# 管理者またはRedis Sentinelから取得します。Redisは常に最後に処理された
# 行を構成ディレクティブの値として含める場合は、includesを記述したほうがよいでしょう
実行時に構成の変更が上書きされないように、このファイルの先頭に # を追加します。
#
# 代わりに、includesを使用して設定を上書きすることに興味がある場合は
# オプションを使用する場合は、最後の行として include を使用することをお勧めします。
#
# /path/to/local.conf を含める
# /path/to/other.conf を含める
 
####################################### ネットワーク ###########################################
 
# デフォルトでは、「bind」設定ディレクティブが指定されていない場合、Redisは
# サーバー上で利用可能なすべてのネットワーク インターフェイスからの接続用。
# 選択した1つまたは複数のインターフェースを聴くことができます。
# 「bind」構成ディレクティブの後に 1 つ以上の IP アドレスが続きます。
#
# 例:
#
# 192.168.1.100 10.0.0.1 をバインドする
# 127.0.0.1 ::1 をバインドします
#
# ~~~ 警告 ~~~ Redisを実行しているコンピュータが
# インターネットでは、すべてのインターフェースにバインドすることは危険であり、
# インスタンスをインターネット上の全員に公開します。デフォルトでは、
# 次のbindディレクティブにより、Redisは
# IPv4ルックバックインターフェースアドレス（これによりRedisは
# 同じコンピュータで実行されているクライアントからの接続のみを受け入れる
# は実行中です。
#
# インスタンスがすべてのインターフェースをリッスンするようにしたい場合は
# 次の行をコメントするだけです。
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#127.0.0.1 をバインドします
 
# 保護モードは、次のようなことを避けるためのセキュリティ保護レイヤーです。
# インターネット上に開いたままになっている Redis インスタンスはアクセスされ、悪用されます。
#
# 保護モードがオンの場合:
#
# 1) サーバーは、
# 「bind」ディレクティブ。
# 2) パスワードが設定されていません。
#
# サーバーは、
# IPv4およびIPv6ループバックアドレス127.0.0.1および::1、およびUnixドメインから
# ソケット。
#
# デフォルトでは保護モードが有効になっています。
# 他のホストのクライアントがRedisに接続できるようにしたい場合
# 認証が設定されていない場合や、特定のインターフェースセットが設定されていない場合でも
# は「bind」ディレクティブを使用して明示的にリストされます。
保護モード はい
 
# 指定されたポートで接続を受け入れます。デフォルトは 6379 (IANA #815344) です。
# ポート 0 が指定された場合、Redis は TCP ソケットをリッスンしません。
ポート 6379
 
# TCP listen() バックログ。
#
# 1秒あたりのリクエスト数が多い環境では、バックログを多く確保する必要があります。
# クライアントの接続が遅いという問題を回避するために。Linuxカーネルは
# はそれを/proc/sys/net/core/somaxconnの値に暗黙的に切り捨てるので、
# somaxconn と tcp_max_syn_backlog の両方の値を上げるようにしてください
# 望ましい効果を得るために。
TCPバックログ511
 
# Unix ソケット。
#
# 待ち受けに使用するUnixソケットのパスを指定します
# 着信接続。デフォルトはないので、Redisはリッスンしません
# 指定されていない場合は Unix ソケット上になります。
#
# unixsocket /tmp/redis.sock
# unixsocketperm 700
 
# クライアントが N 秒間アイドル状態になった後に接続を閉じる (無効にするには 0)
タイムアウト 0
 
# TCP キープアライブ。
#
# ゼロ以外の場合、SO_KEEPALIVEを使用して、不在時にクライアントにTCP ACKを送信します
通信回数。これは次の 2 つの理由で役立ちます。
#
# 1) デッドピアを検出します。
# 2) ネットワークの観点から接続を維持する
# 真ん中に装備。
#
# Linux では、指定された値 (秒単位) は ACK を送信するために使用される期間です。
# 接続を閉じるには 2 倍の時間が必要であることに注意してください。
# 他のカーネルでは、期間はカーネル構成によって異なります。
#
# このオプションの適切な値は300秒で、これは新しい
# Redis 3.2.1 以降の Redis のデフォルト。
TCP キープアライブ 300
 
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ 一般的な ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃
 
# デフォルトでは、Redis はデーモンとして実行されません。必要な場合は「yes」を使用してください。
# Redis はデーモン化されると /var/run/redis.pid に pid ファイルを書き込むことに注意してください。
#デーモン化しない
 
# Redisをupstartまたはsystemdから実行すると、Redisは
# 監視ツリー。オプション:
# 監督なし - 監督なしのやり取り
# 監視付き起動 - Redis を SIGSTOP モードにして起動を通知します
# 監視対象 systemd - $NOTIFY_SOCKET に READY=1 を書き込んで systemd にシグナルを送る
# 監視付き自動検出 - upstartまたはsystemdメソッドに基づいて
# UPSTART_JOB または NOTIFY_SOCKET 環境変数
# 注意: これらの監視方法は、「プロセスの準備ができました」という信号のみを送信します。
# スーパーバイザーへの継続的なライブネス ping は有効になりません。
監督なし
 
# pidファイルが指定されている場合、Redisは起動時に指定された場所にそれを書き込みます
# 終了時に削除します。
#
# サーバーがデーモン化されていない状態で実行されている場合、pidファイルは作成されません。
# 設定で指定されます。サーバーがデーモン化されている場合、pidファイルは
# は指定されていない場合でも使用され、デフォルトは "/var/run/redis.pid" になります。
#
# pidファイルを作成するのがベストエフォートです。Redisがそれを作成できない場合は
# 何も悪いことは起こらず、サーバーは正常に起動して実行されます。
pidファイル /var/run/redis_6379.pid
 
# サーバーの詳細レベルを指定します。
# 次のいずれかになります:
# デバッグ (開発/テストに役立つ多くの情報)
# 詳細 (めったに役に立たない情報が多いが、デバッグ レベルのような混乱はない)
# 通知 (適度に冗長、おそらく本番環境で必要な内容)
# 警告 (非常に重要/重大なメッセージのみが記録されます)
ログレベル通知
 
# ログファイル名を指定します。また、空の文字列を使用して強制的に
# Redisは標準出力にログを記録します。標準出力を使用する場合は、
# ログ出力ですがデーモン化されており、ログは /dev/null に送信されます
ログファイル ""
 
# システムロガーへのログ記録を有効にするには、「syslog-enabled」をyesに設定するだけです。
# 必要に応じて、他の syslog パラメータを更新します。
# syslog 有効 いいえ
 
# syslog ID を指定します。
# syslog-ident redis
 
# syslog 機能を指定します。USER または LOCAL0 ～ LOCAL7 の範囲で指定する必要があります。
# syslog 機能 local0
 
# データベースの数を設定します。デフォルトのデータベースはDB 0ですが、
# SELECT <dbid>を使用して接続ごとに異なるものを選択します。
# dbid は 0 から 'databases'-1 までの数字です
データベース 16
 
################################### スナップショット ####################################
#
# DB をディスクに保存します:
#
# <秒数> <変更内容> を保存
#
# 指定された秒数と指定された時間の両方が経過した場合、DBを保存します。
# DB に対して書き込み操作が何回発生しました。
#
# 以下の例では、動作は保存されます:
# 少なくとも 1 つのキーが変更された場合、900 秒 (15 分) 後
# 300秒（5分）後、少なくとも10個のキーが変更された場合
# 60秒後に少なくとも10000個のキーが変更された場合
#
# 注意: すべての「save」行をコメントアウトすることで、保存を完全に無効にすることができます。
#
# 以前に設定した保存をすべて削除することもできます
# 空の文字列引数を 1 つ持つ save ディレクティブを追加することでポイントを獲得
# 次の例のように:
#
＃ 保存 ""
 
120 1 を節約
300 10 を節約
60 10000を節約
 
# デフォルトでは、RDBスナップショットが有効になっている場合、Redisは書き込みの受け入れを停止します
# (少なくとも 1 つのセーブ ポイント) と最新のバックグラウンド セーブが失敗しました。
# これにより、ユーザーはデータが永続化されていないことを（厳しい方法で）認識することになります
# ディスクに正しく保存しないと、誰も気づかず、
# 災害は起こるでしょう。
#
# バックグラウンド保存プロセスが再び機能し始めると、Redisは
# 再度書き込みを自動的に許可します。
#
# ただし、Redisサーバーの適切な監視を設定している場合は
# 永続性が必要な場合は、この機能を無効にして、Redisが
# ディスクに問題があっても通常通り動作を続けます。
# 権限など。
stop-writes-on-bgsave-error はい
 
# .rdb データベースをダンプするときに LZF を使用して文字列オブジェクトを圧縮しますか?
# デフォルトでは、ほとんどの場合に有効なので「はい」に設定されています。
# 保存中の子プロセスでCPUを節約したい場合は「no」に設定してください。
# 圧縮可能な値やキーがある場合、データセットは大きくなる可能性があります。
rdb圧縮はい
 
# RDB バージョン 5 以降では、CRC64 チェックサムがファイルの末尾に配置されます。
# これにより、フォーマットは破損に対してより耐性を持つようになりますが、パフォーマンスが低下します
# RDBファイルの保存と読み込み時にコストがかかる（約10％）ため、無効にすることができます
# 最高のパフォーマンスを実現します。
#
# チェックサムを無効にして作成されたRDBファイルのチェックサムは0となり、
# ロードコードにチェックをスキップするように指示します。
rdbchecksum はい
 
# DBをダンプするファイル名
dbファイル名 dump.rdb
 
# 作業ディレクトリ。
#
# DBはこのディレクトリ内に、指定されたファイル名で書き込まれます
# 上記の 'dbfilename' 構成ディレクティブを使用します。
#
# 追加専用ファイルもこのディレクトリ内に作成されます。
#
# ここではファイル名ではなくディレクトリを指定する必要があることに注意してください。
監督/
 
##################################### レプリケーション #######################################
 
# マスタースレーブレプリケーション。slaveofを使用してRedisインスタンスをコピーします。
# 別の Redis サーバー。Redis レプリケーションについて、すぐに理解しておくべきことがいくつかあります。
#
# 1) Redisのレプリケーションは非同期ですが、マスターを設定することで
# 少なくとも接続されていないと思われる場合は書き込みの受け入れを停止します
# 指定された数のスレーブ。
# 2) Redisスレーブは、
# マスターは、比較的短い時間の間レプリケーションリンクが失われた場合、
# 時間。レプリケーションバックログサイズを設定することもできます（次の
# 必要に応じて、このファイルのセクションに適切な値を設定します。
# 3) レプリケーションは自動的に行われ、ユーザーの介入は必要ありません。
# ネットワーク パーティション スレーブは自動的にマスターに再接続しようとします
# それらと再同期します。
#
# スレーブ <マスターIP> <マスターポート>
 
# マスターがパスワード保護されている場合（「requirepass」設定を使用）
# 以下のディレクティブを使用すると、スレーブに認証する前に
# レプリケーション同期プロセスを開始します。そうでない場合は、マスターが
# スレーブ要求を拒否します。
#
# masterauth <マスターパスワード>
 
# スレーブがマスターとの接続を失った場合、またはレプリケーションが
# がまだ進行中の場合、スレーブは 2 つの異なる方法で動作できます。
#
# 1) slave-serve-stale-dataが「yes」（デフォルト）に設定されている場合、スレーブは
# クライアントのリクエストに応答しますが、データが古い可能性があります。
# これが最初の同期である場合、データ セットは空になることがあります。
#
# 2) スレーブサーブステイルデータが「no」に設定されている場合、スレーブは次のように応答します。
# すべての種類のコマンドに対して「マスターとの同期が進行中です」というエラーが発生する
# ただし、INFO と SLAVEOF に適用されます。
#
スレーブサーブ古いデータ はい
 
# スレーブインスタンスが書き込みを受け入れるかどうかを設定できます。
# スレーブインスタンスは一時的なデータを保存するのに便利です（データ
# スレーブに書き込まれたデータは、マスターとの再同期後に簡単に削除されますが、
# クライアントが書き込みをする際にも問題が発生する場合があります。
# 設定ミス。
#
# Redis 2.6 以降では、スレーブはデフォルトで読み取り専用になります。
#
# 注意: 読み取り専用スレーブは信頼できないクライアントに公開されるようには設計されていません
# インターネット上では、インスタンスの不正使用に対する保護レイヤーにすぎません。
# 読み取り専用スレーブはデフォルトですべての管理コマンドをエクスポートします
# CONFIG、DEBUGなど。限られた範囲で改善できます
# 読み取り専用スレーブのセキュリティを「rename-command」を使用してシャドウイングする
# 管理上/危険なコマンド。
スレーブ読み取り専用 はい
 
# レプリケーション SYNC 戦略: ディスクまたはソケット。
#
# -------------------------------------------------------
# 警告: ディスクレスレプリケーションは現在実験段階です
# -------------------------------------------------------
#
# レプリケーションを続行できない新しいスレーブと再接続スレーブ
# 差分を受け取るだけのプロセスでは、「完全な
# 同期"。RDB ファイルがマスターからスレーブに送信されます。
# 送信は 2 つの異なる方法で行われます。
#
# 1) ディスクバックアップ: RedisマスターはRDBに書き込む新しいプロセスを作成します
# ディスク上のファイル。その後、ファイルは親によって転送されます
# スレーブに段階的にプロセスを実行します。
# 2) ディスクレス: Redisマスターは、新しいプロセスを作成し、
# ディスクにまったく触れずに、RDB ファイルをスレーブ ソケットに転送します。
#
# ディスクバックアップレプリケーションでは、RDBファイルが生成されている間に、スレーブがさらに
# 現在の子プロセスが生成するとすぐに、キューに入れられ、RDBファイルとともに提供される。
# RDBファイルは作業を終了します。ディスクレスレプリケーションでは、
# 転送が開始されると、到着した新しいスレーブがキューに入れられ、新しい転送が開始されます
# 現在のものが終了すると開始されます。
#
# ディスクレスレプリケーションが使用される場合、マスターは設定可能な時間だけ待機します。
# 複数のスレーブが転送を開始するまでの時間（秒）
# が到着し、転送を並列化できます。
#
# 低速ディスクと高速（広帯域）ネットワークでは、ディスクレスレプリケーション
# の方がうまく機能します。
repl-ディスクレス同期なし
 
# ディスクレスレプリケーションが有効な場合、遅延を設定することができます
# サーバーは、ソケット経由で RDB を転送する子プロセスを生成するために待機します。
# 奴隷たちに。
#
# 転送が開始されると、配信できなくなるため、これは重要です。
# 新しいスレーブが到着し、次のRDB転送のためにキューに入れられるので、サーバーは
# より多くのスレーブが到着するまで遅延を待機します。
#
# 遅延は秒単位で指定され、デフォルトでは5秒です。無効にするには
# 0 秒に設定するだけで、転送はすぐに開始されます。
repl-ディスクレス同期遅延 5
 
# スレーブは事前に定義された間隔でサーバーにPINGを送信します。変更可能です
# この間隔は repl_ping_slave_period オプションで設定できます。デフォルト値は 10 です。
# 秒。
#
# repl-ping-スレーブ期間 10
 
# 次のオプションは、レプリケーションのタイムアウトを設定します。
#
# 1) スレーブの観点から見た、SYNC 中のバルク転送 I/O。
# 2) スレーブの観点から見たマスターのタイムアウト (データ、ping)。
# 3) マスターの観点から見たスレーブのタイムアウト (REPLCONF ACK ping)。
#
# この値が値より大きいことを確認することが重要です
# repl-ping-slave-period に指定されていない場合はタイムアウトが検出されます
# マスターとスレーブ間のトラフィックが少ないとき。
#
# 再実行タイムアウト 60
 
# SYNC 後にスレーブ ソケットで TCP_NODELAY を無効にします?
#
# 「はい」を選択した場合、Redisはより少ない数のTCPパケットを使用し、
# スレーブにデータを送信するための帯域幅が少なくなります。ただし、これにより遅延が発生する可能性があります。
# スレーブ側に表示されるデータ、最大40ミリ秒
# デフォルト設定を使用する Linux カーネル。
#
# 「いいえ」を選択した場合、スレーブ側でデータが表示されるまでの遅延は
# 削減されますが、レプリケーションに使用される帯域幅は増加します。
#
# デフォルトでは低レイテンシに最適化されていますが、非常に高いトラフィック状況では
# またはマスターとスレーブが多くのホップ離れている場合、これを「はい」にすると
# 良いアイデアです。
repl-disable-tcp-nodelay なし
 
# レプリケーションバックログのサイズを設定します。バックログは蓄積されるバッファです。
# スレーブがしばらく切断されたときにスレーブデータを保存するので、スレーブが
# 再度接続したい場合、完全な再同期は必要ないことが多いですが、部分的な再同期は必要です。
# 再同期は十分です。スレーブが同期中に逃したデータの一部を渡すだけです。
# 切断されました。
#
# レプリケーションバックログが大きいほど、スレーブが
# 切断され、後で部分的な再同期を実行できるようになります。
#
# バックログは、少なくとも 1 つのスレーブが接続された場合にのみ割り当てられます。
#
# repl-バックログサイズ 1mb
 
# マスターがスレーブをしばらく接続しなくなった後、バックログ
# 解放される秒数を設定します。次のオプションは
# 最後のスレーブが切断された時点から経過する必要がある。
# 解放するバックログ バッファ。
#
# 値が 0 の場合、バックログは解放されません。
#
# レプリケーションバックログTTL 3600
 
# スレーブの優先度は、Redis によって INFO 出力で公開される整数です。
# Redis Sentinelによって、昇格するスレーブを選択するために使用されます。
# マスターが正しく動作しなくなった場合、マスター。
#
# 優先度番号が低いスレーブは昇格に適していると考えられるため、
# 例えば、優先度10、100、25のスレーブが3台ある場合、Sentinelは
# 優先度が最も低い 10 のものを選択します。
#
# ただし、特別な優先度0はスレーブが実行できないことを示します。
# マスターの役割なので、優先度0のスレーブは選択されません
# プロモーション用の Redis Sentinel。
#
# デフォルトでは優先度は 100 です。
スレーブ優先度 100
 
# マスターが書き込みの受け入れを停止する可能性があるのは、
# N 個のスレーブが接続されており、遅延は M 秒以下です。
#
# N 個のスレーブは「オンライン」状態である必要があります。
#
# 指定された値以下である必要がある秒単位の遅延は、次のように計算されます。
# スレーブから受信した最後の ping。通常は 1 秒ごとに送信されます。
#
# このオプションはN個のレプリカが書き込みを受け入れることを保証するものではありませんが、
# スレーブが足りない場合に書き込み損失が発生する可能性を制限します
# は指定された秒数まで利用可能です。
#
# たとえば、ラグが 10 秒以下のスレーブを少なくとも 3 つ必要とするには、次のようにします。
#
# 書き込み可能なスレーブの最小数 3
# 最小スレーブ最大ラグ 10
#
# いずれか一方を 0 に設定すると、機能が無効になります。
#
# デフォルトでは、min-slaves-to-writeは0（機能は無効）に設定されており、
# min-slaves-max-lag は 10 に設定されています。
 
# Redisマスターは接続されたサーバーのアドレスとポートを一覧表示できます
# スレーブをさまざまな方法で管理します。たとえば、「INFO replication」セクション
# この情報を提供しており、他のツールの中でも、
# スレーブインスタンスを検出するために Redis Sentinel を使用します。
# この情報が入手できるもう1つの場所は、
# マスターの「ROLE」コマンド。
#
# スレーブによって通常報告されるリストされたIPとアドレスが取得されます
# 次のようにします:
#
# IP: ピアアドレスをチェックすることでアドレスが自動的に検出されます
スレーブがマスターと接続するために使用するソケットの番号。
#
# ポート: レプリケーション中にスレーブによって通信されるポート
# ハンドシェイク、通常はスレーブが使用するポートです
# 接続のリスト。
#
# ただし、ポート転送やネットワークアドレス変換 (NAT) が
# 使用した場合、スレーブは実際には別のIPとポート経由でアクセスできる可能性があります
# ペア。スレーブは、次の2つのオプションを使用して、
# マスターに特定のIPとポートのセットを報告し、INFOと
# そして ROLE はそれらの値を報告します。
#
# 両方のオプションを使用する必要はありません。
# ポートまたは IP アドレス。
#
# スレーブアナウンスIP 5.5.5.5
# スレーブアナウンスポート 1234
 
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ 安全 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃
 
# 他の処理を実行する前にクライアントにAUTH <PASSWORD>の発行を要求する
# コマンド。これは、信頼できない環境で役立つかもしれません
# redis-server を実行しているホストへのアクセス権を持つ他のユーザー。
#
# これは下位互換性のためコメントアウトしたままにしておくべきであり、ほとんどの
# 認証を必要としない人 (たとえば、独自のサーバーを実行している人)。
#
# 警告: Redisは非常に高速なので、外部のユーザーは最大
# 良いマシンに対して1秒あたり15万のパスワード。つまり、
# 非常に強力なパスワードを使用してください。そうしないと、簡単に破られてしまいます。
#
# requirepass foobared
 
# コマンドの名前変更。
#
# 共有ディレクトリ内の危険なコマンドの名前を変更することができます
# 環境。例えば、CONFIGコマンドは、
# 推測しにくいので、社内ツールでも利用可能
# ただし、一般クライアントでは利用できません。
#
＃ 例：
#
# 名前変更コマンド CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
#
# コマンド名を次のように変更することで、コマンドを完全に終了させることもできます。
# 空の文字列:
#
# 名前変更コマンド CONFIG ""
#
# ログインするコマンドの名前を変更すると、
# AOF ファイルまたはスレーブへの送信により問題が発生する可能性があります。
 
####################################### 制限 #########################################
 
# 同時に接続できるクライアントの最大数を設定します。デフォルトでは
# この制限は10000クライアントに設定されていますが、Redisサーバーが
# プロセスファイルの制限を、指定された制限を許可するように設定できます
# 許可されるクライアントの最大数は現在のファイル制限に設定されます
# マイナス 32 (Redis は内部使用のためにいくつかのファイル記述子を予約しているため)。
#
# 制限に達すると、Redisは送信するすべての新しい接続を閉じます
# エラー「クライアントの最大数に達しました」。
#
# 最大クライアント数 10000
 
# 指定されたバイト数を超えるメモリを使用しないでください。
# メモリ制限に達すると、Redisはキーを削除しようとします
# 選択された削除ポリシーに従って実行されます (maxmemory-policy を参照)。
#
# Redisがポリシーに従ってキーを削除できない場合、またはポリシーが
# 'noeviction'に設定すると、Redisはコマンドに対してエラーを返答し始めます
# SET、LPUSHなど、より多くのメモリを使用するものがあり、
# GET などの読み取り専用コマンドに応答します。
#
# このオプションは通常、RedisをLRUキャッシュとして使用する場合や、
# インスタンスのハードメモリ制限（「noeviction」ポリシーを使用）。
#
# 警告: maxmemory がオンのインスタンスにスレーブが接続されている場合、
# スレーブに供給するために必要な出力バッファのサイズが減算されます
# 使用メモリ数から、ネットワークの問題や再同期が
# キーが削除されるループをトリガーせず、出力が
# スレーブのバッファが、削除をトリガーするキーの DEL でいっぱいです
データベースが完全に空になるまで、さらにキーを追加します。
#
# 要するに...スレーブが接続されている場合は、より低い値を設定することを推奨します
# スレーブ用にシステムに空きRAMが確保されるようにmaxmemoryを制限します
# 出力バッファ（ただし、ポリシーが 'noeviction' の場合は必要ありません）。
#
# 最大メモリ <バイト>
 
# MAXMEMORYポリシー: Redisがmaxmemory時に削除するものを選択する方法
# に到達しました。次の 5 つの動作から選択できます。
#
# volatile-lru -> LRUアルゴリズムを使用して有効期限が設定されたキーを削除します
# allkeys-lru -> LRUアルゴリズムに従って任意のキーを削除します
# volatile-random -> 有効期限が設定されたランダムキーを削除します
# allkeys-random -> ランダムキー（任意のキー）を削除します
# volatile-ttl -> 有効期限が最も近いキーを削除します (マイナー TTL)
# noeviction -> 期限切れにならず、書き込み操作時にエラーを返すだけ
#
# 注意: 上記のポリシーのいずれの場合も、Redisは書き込み時にエラーを返します。
# 削除するのに適したキーがない場合に、操作を実行します。
#
# 執筆時点でのこれらのコマンドは次のとおりです: set setnx setex append
# 増分減分rpush lpush rpushx lpushx linsert lset rpoplpush sadd
# sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
# zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
# getset mset msetnx exec sort
#
# デフォルトは次のとおりです:
#
# 最大メモリポリシー noeviction
 
# LRUと最小TTLアルゴリズムは正確なアルゴリズムではなく近似値です
# アルゴリズム（メモリを節約するため）を調整して速度を調整したり、
# 精度。デフォルトではRedisは5つのキーをチェックし、最も正確だったものを選択します。
# 最近あまり使われていないので、次の方法でサンプルサイズを変更できます
# 構成ディレクティブ。
#
# デフォルトの5で十分な結果が得られます。10で非常に近い値になります
# 真の LRU ですが、CPU のコストが少し高くなります。3 は非常に高速ですが、あまり正確ではありません。
#
# 最大メモリサンプル数 5
 
############################### 追加のみモード #################################
 
# デフォルトではRedisはデータセットをディスクに非同期でダンプします。このモードは
# 多くのアプリケーションでは十分ですが、Redisプロセスまたは
# 停電により数分間の書き込みが失われる場合があります（
# 設定されたセーブポイント)。
#
# 追加専用ファイルは、
# 耐久性が大幅に向上します。たとえば、デフォルトのデータfsyncポリシーを使用すると
# (設定ファイルで後述) Redisは1秒間の書き込みで損失する可能性があります。
# サーバーの停電や、何かが起こった場合の1回の書き込みなどの劇的なイベント
# Redisプロセス自体に問題が発生するが、オペレーティングシステムは
# まだ正常に動作しています。
#
# AOF と RDB の永続性は問題なく同時に有効にできます。
# 起動時にAOFが有効になっている場合、RedisはAOFをロードします。これはファイルです
# より優れた耐久性を保証します。
#
# 詳細については、http://redis.io/topics/persistence を参照してください。
 
追加のみいいえ
 
# 追加専用ファイルの名前 (デフォルト: "appendonly.aof")
 
追加ファイル名「appendonly.aof」
 
# fsync() 呼び出しは、オペレーティングシステムに実際にディスクにデータを書き込むように指示します
# 出力バッファにさらにデータが入るのを待つ代わりに、一部のOSでは実際にフラッシュされます。
# ディスク上のデータの場合、他の OS はそれをできるだけ早く実行しようとします。
#
# Redis は 3 つの異なるモードをサポートしています。
#
# いいえ: fsync は行わず、OS が必要に応じてデータをフラッシュできるようにします。より高速です。
# 常に: 追加専用ログへの書き込みのたびに fsync を実行します。低速ですが、最も安全です。
# everysec: 1 秒ごとに 1 回だけ fsync を実行します。妥協案です。
#
# デフォルトは「everysec」です。これは通常、
# スピードとデータの安全性。これを緩和できるかどうかはあなた次第です
# 「no」に設定すると、オペレーティングシステムは出力バッファをフラッシュします。
# より良いパフォーマンスのために、それが望むもの（ただし、
# スナップショットのデフォルトの永続モードを考慮すると、多少のデータ損失が発生します)
# または逆に、「always」を使うと非常に遅くなりますが、
# 毎秒。
#
# 詳細については、次の記事を参照してください。
# http://antirez.com/post/redis-persistence-demystified.html
#
# 不明な場合は、「everysec」を使用してください。
 
# 常にappendfsync
毎秒追加同期
# appendfsync なし
 
# AOF fsyncポリシーがalwaysまたはeverysecに設定され、バックグラウンド
# 保存プロセス（バックグラウンド保存またはAOFログのバックグラウンド書き換え）は
# Linuxの構成によっては、ディスクに対して大量のI/Oを実行する
# Redisはfsync()呼び出しで長時間ブロックすることがあります。これに対する修正はありません。
# 現時点では、別のスレッドでfsyncを実行してもブロックされるため、
# 同期write(2)呼び出し。
#
# この問題を軽減するために、次のオプションを使用できます
# これにより、メインプロセスでfsync()が呼び出されるのを防ぐことができます。
# BGSAVE または BGREWRITEAOF が進行中です。
#
# つまり、別の子が保存している間、Re​​disの耐久性は
# 「appendfsync none」と同じです。実際的には、これは
# 最悪のシナリオでは、最大30秒のログが失われる可能性があります（
# デフォルトの Linux 設定)。
#
# 遅延の問題がある場合はこれを「はい」にしてください。それ以外の場合はそのままにしてください
# 「いいえ」は耐久性の観点から最も安全な選択です。
 
書き換え時にfsyncを追加しない
 
# 追加専用ファイルの自動書き換え。
# Redisは暗黙的にログファイルを自動的に書き換えることができます
# BGREWRITEAOF AOF ログ サイズが指定されたパーセンテージだけ増加したとき。
#
# 仕組みは次の通りです: RedisはAOFファイルのサイズを記憶し、
# 最新の書き換え（再起動後に書き換えが行われていない場合は、
# 起動時のAOFが使用されます。
#
# この基本サイズは現在のサイズと比較されます。現在のサイズが
# 指定されたパーセンテージより大きい場合、書き換えがトリガーされます。また、
# 書き換えるAOFファイルの最小サイズを指定する必要があります。
# パーセンテージの増加があってもAOFファイルの書き換えを回避するのに役立ちます
# に到達しましたが、まだかなり小さいです。
#
# 自動AOFを無効にするには、パーセンテージをゼロに指定します
# 書き換え機能。
 
自動 Aof 書き換え率 100
自動 aof 書き換え最小サイズ 64 MB
 
# Redis の実行中に AOF ファイルが末尾で切り捨てられることがあります。
# 起動プロセスで、AOF データがメモリに再度ロードされます。
# これはRedisが稼働しているシステムで発生する可能性があります
# クラッシュします。特にext4ファイルシステムが
# data=ordered オプション（ただし、Redis 自体が
# クラッシュまたは中止しますが、オペレーティング システムは正常に動作します。
#
# Redisは、これが発生するとエラーで終了するか、
# 可能な限りデータを取得し（現在のデフォルト）、AOFファイルが見つかった場合は開始します
# 末尾が切り捨てられます。次のオプションはこの動作を制御します。
#
# aof-load-truncatedがyesに設定されている場合、切り詰められたAOFファイルがロードされ、
# Redis サーバーは、ユーザーにイベントを通知するためにログの出力を開始します。
# それ以外の場合、オプションがnoに設定されている場合、サーバーはエラーで中止します
# 起動を拒否します。オプションがnoに設定されている場合、ユーザーは
# 再起動する前に「redis-check-aof」ユーティリティを使用してAOFファイルを修正します
# サーバー。
#
# AOFファイルが途中で破損していることが判明した場合、
# サーバーはエラーで終了します。このオプションは、
# RedisはAOFファイルからさらにデータを読み取ろうとしますが、バイト数が足りません
# が見つかります。
aof-load-truncated はい
 
################################## LUA スクリプト ##################################
 
# Lua スクリプトの最大実行時間（ミリ秒単位）。
#
# 最大実行時間に達した場合、Redisはスクリプトが
# 最大許容時間経過後もまだ実行中であり、
# エラーのあるクエリに応答します。
#
# 長時間実行されるスクリプトが最大実行時間を超えると、
# SCRIPT KILLおよびSHUTDOWN NOSAVEコマンドが利用可能です。最初のコマンドは
# 書き込みコマンドをまだ呼び出していないスクリプトを停止するために使用されます。2番目の
# 書き込みコマンドが失敗した場合にサーバーをシャットダウンする唯一の方法です
# スクリプトによってすでに発行されているが、ユーザーは自然な結果を待ちたくない
# スクリプトの終了。
#
# 警告なしで無制限に実行するには、0 または負の値に設定します。
lua 時間制限 5000
 
################################## REDIS クラスター ###################################
#
# ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# 警告 実験的: Redis Clusterは安定したコードであると考えられていますが、
# 「成熟」とマークするには、一定の割合を待つ必要があります
本番環境に展開するユーザー数。
# ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#
# 通常のRedisインスタンスはRedis Clusterの一部にはなれません。
# クラスタノードとして起動できます。Redisインスタンスをクラスタノードとして起動するには、
# クラスター ノードでは、次のコメントを解除してクラスター サポートを有効にします。
#
# クラスタが有効 はい
 
# 各クラスタノードにはクラスタ構成ファイルがあります。このファイルは
# 手動で編集することを目的としています。Redis ノードによって作成および更新されます。
# Redis Cluster ノードごとに異なるクラスター構成ファイルが必要です。
# 同じシステムで実行されているインスタンスに
# クラスター構成ファイル名が重複しています。
#
# クラスター設定ファイル nodes-6379.conf
 
# クラスタノードタイムアウトは、ノードが到達不能になる必要があるミリ秒数です
# 失敗状態とみなされます。
# その他のほとんどの内部時間制限は、ノードのタイムアウトの倍数です。
#
# クラスターノードタイムアウト 15000
 
# 障害が発生したマスターのスレーブは、データが
# 古すぎるようです。
#
# 奴隷が実際に正確な測定を行う簡単な方法はありません
# 「データの古さ」を確認するため、次の 2 つのチェックが実行されます。
#
# 1) フェイルオーバー可能なスレーブが複数ある場合、それらはメッセージを交換する
# 最も優れた奴隷に有利になるようにするため
# レプリケーション オフセット (マスターからの処理されたデータが増えました)。
# スレーブはオフセットでランクを取得し、開始に適用します
フェイルオーバーの回数に応じて、ランクに比例した遅延が発生します。
#
# 2) 各スレーブは、最後のやり取りの時刻を計算します
# マスター。これは最後に受信したpingまたはコマンドになります（マスターの場合）。
# がまだ「接続」状態にあるかどうか、または接続が確立されてから経過した時間。
# マスターとの切断（レプリケーション リンクが現在ダウンしている場合）。
# 最後のやり取りが古すぎる場合、スレーブはフェイルオーバーを試みません
# まったく。
#
# ポイント「2」はユーザーが調整できます。具体的には、スレーブは実行しません
# マスターとの最後のやり取り以降、時間が
# 経過時間が次より大きい:
#
# (ノードタイムアウト * スレーブ有効係数) + repl-ping-スレーブ期間
#
# 例えば、ノードタイムアウトが30秒でスレーブ有効係数が
# は10で、デフォルトのrepl-ping-slave-periodが10秒であると仮定すると、
# スレーブはマスターと通信できなかった場合、フェイルオーバーを試行しません
# 310秒以上。
#
# スレーブの有効性係数が大きいと、データが古すぎるスレーブがフェイルオーバーされる可能性があります
# マスターとして機能しますが、値が小さすぎるとクラスターが
# そもそも奴隷を選出しない。
#
# 最大限の可用性を得るために、スレーブ有効係数を設定することが可能です
# 値を0に設定すると、スレーブは常にフェイルオーバーを試みます
# マスターと最後にやり取りした時間に関係なく、マスターに戻ります。
# (ただし、常に遅延を適用しようとします。
# オフセットランク)。
#
# ゼロは、すべてのパーティションが修復されたときに保証できる唯一の値です
# クラスターは常に継続できます。
#
# クラスタースレーブ有効係数 10
 
# クラスタスレーブは孤立したマスターに移行することができます。
# 動作中のスレーブがないまま残されたクラスタ。これによりクラスタの能力が向上します
# 障害に耐性を持たせるため、そうしないと孤立したマスターをフェイルオーバーできない
# 動作中のスレーブがない場合の失敗の場合。
#
# スレーブは、少なくとも1つのスレーブが残っている場合にのみ、孤立したマスターに移行します。
# 元の主人のために働く他の奴隷の数。この数は
# は「移行バリア」です。移行バリアが1の場合、スレーブは
# マスターに対して少なくとも 1 つの他の動作中のスレーブがある場合にのみ移行されます
# など。通常は、各スレーブに必要なスレーブの数を反映します。
# クラスター内のマスター。
#
# デフォルトは1です（スレーブはマスターが少なくとも
# 1 つのスレーブ)。移行を無効にするには、非常に大きな値に設定するだけです。
# 0という値も設定できますが、デバッグにのみ有効であり、危険です
# 生産中。
#
# クラスター移行バリア 1
 
# デフォルトでは、Redis Clusterノードは、
# 少なくともハッシュ スロットがカバーされていません (利用可能なノードがそれを提供していません)。
# この方法では、クラスタが部分的にダウンしている場合（たとえば、ハッシュスロットの範囲が
# カバーされなくなると、最終的にはすべてのクラスターが使用できなくなります。
# すべてのスロットが再びカバーされるとすぐに、自動的に使用可能に戻ります。
#
# しかし、時には稼働中のクラスターのサブセットが必要な場合があります。
# キー空間のまだ残っている部分に対するクエリを引き続き受け付ける
# カバーされます。そうするには、cluster-require-full-coverageを設定するだけです
# オプションを no に設定します。
#
# クラスターのフルカバレッジが必要 yes
 
# クラスタを設定するには、必ずドキュメントを読んでください
# http://redis.io Web サイトで入手可能。
 
####################################### スローログ #####################################
 
# Redisスローログは、指定された時間を超えたクエリを記録するシステムです。
# 実行時間。実行時間にはI/O操作は含まれません。
# クライアントとの会話、返信の送信など
# ただし、実際にコマンドを実行するのに必要な時間だけです（これが唯一の
# スレッドがブロックされ、サービスを提供できないコマンド実行の段階
# その間に他のリクエストも受け付けます。
#
# スローログは2つのパラメータで設定できます。1つはRedisに
# 実行時間が何マイクロ秒を超えると、
# ログに記録するコマンドと、もう1つのパラメータは
# 遅いログ。新しいコマンドがログに記録されると、最も古いコマンドがログから削除されます。
# ログに記録されたコマンドのキュー。
 
# 次の時間はマイクロ秒で表されます。1000000は
# 1秒に設定できます。負の数値を指定するとスローログが無効になりますが、
# 値がゼロの場合、すべてのコマンドのログ記録が強制されます。
slowlog-log-slower-than-10000 ログが 10000 より遅い
 
# この長さに制限はありません。ただし、メモリを消費することに注意してください。
# SLOWLOG RESET を使用すると、スロー ログによって使用されたメモリを再利用できます。
スローログ最大長 128
 
################################## レイテンシ モニター ##################################
 
# Redisのレイテンシ監視サブシステムはさまざまな操作をサンプリングします
# 実行時に、可能性のあるソースに関連するデータを収集するために
# Redis インスタンスのレイテンシ。
#
# LATENCYコマンドを介してこの情報はユーザーに利用可能であり、
# グラフを印刷し、レポートを取得します。
#
# システムは、指定された時間内に実行された操作のみを記録します。
# 指定されたミリ秒数よりも大きい
# レイテンシ監視しきい値設定ディレクティブ。値が設定されている場合は
# をゼロにすると、レイテンシ モニターはオフになります。
#
# デフォルトでは、レイテンシ監視はほとんど必要ないので無効になっています
# レイテンシの問題がなく、データ収集にパフォーマンス上の問題がない場合
# 影響は非常に小さいですが、大きな負荷がかかると測定できます。レイテンシ
# 監視は実行時にコマンドを使用して簡単に有効にできます
# 必要に応じて「CONFIG SETlatency-monitor-threshold <milliseconds>」を設定します。
レイテンシモニターしきい値 0
 
################################ イベント通知 #################################
 
# Redis は、キー空間で発生するイベントについて Pub/Sub クライアントに通知できます。
# この機能については、http://redis.io/topics/notifications で説明されています。
#
# たとえば、キースペースイベント通知が有効になっていて、クライアントが
# データベース0に格納されているキー「foo」に対してDEL操作を実行します。
# メッセージは Pub/Sub 経由で公開されます:
#
# PUBLISH __keyspace@0__:foo del
# PUBLISH __keyevent@0__:del foo
#
# Redisが通知するイベントをセットから選択することができます
クラスの数。各クラスは 1 文字で識別されます。
#
# K キースペース イベント。__keyspace@<db>__ プレフィックスで公開されます。
# E Keyevent イベント。__keyevent@<db>__ プレフィックスで公開されます。
# g DEL、EXPIRE、RENAME などの汎用コマンド (タイプに依存せず)
# $ 文字列コマンド
# コマンドの一覧
# s コマンドの設定
# h ハッシュコマンド
# z ソートセットコマンド
# x 期限切れイベント（キーの有効期限が切れるたびに生成されるイベント）
# e 削除されたイベント（maxmemory のキーが削除されたときに生成されるイベント）
# g$lshzxe のエイリアス。「AKE」文字列はすべてのイベントを意味します。
#
# 「notify-keyspace-events」は引数として文字列を受け取り、
# 0文字以上の文字。空文字列は通知が
# は無効です。
#
# 例: リストと汎用イベントを有効にするには、
# イベント名、使用方法:
#
# キースペースイベント通知 Elg
#
# 例 2: チャンネルにサブスクライブしている期限切れのキーのストリームを取得する
# 名前 __keyevent@0__:expired 使用:
#
# キースペースイベント通知例
#
# デフォルトでは、ほとんどのユーザーは通知を必要としないため、すべての通知が無効になっています。
# この機能とこの機能にはオーバーヘッドがあります。
# K または E の少なくとも 1 つを指定しないと、イベントは配信されません。
キースペースイベントを通知する ""
 
#################################### 高度な構成 ####################################
 
# ハッシュは、メモリ効率の良いデータ構造を使用してエンコードされます。
# エントリ数が少なく、最大のエントリが指定された数を超えない
# しきい値。これらのしきい値は、次のディレクティブを使用して設定できます。
ハッシュ最大 ziplist エントリ 512
ハッシュ最大 ziplist 値 64
 
# リストも、多くのスペースを節約するために特別な方法でエンコードされます。
# 内部リストノードごとに許可されるエントリの数を指定できます
# 固定の最大サイズまたは要素の最大数として。
# 最大サイズを固定する場合は、-5 から -1 を使用します。これは次の意味です。
# -5: 最大サイズ: 64 Kb <-- 通常のワークロードには推奨されません
# -4: 最大サイズ: 32 Kb <-- 非推奨
# -3: 最大サイズ: 16 Kb <-- おそらく推奨されません
# -2: 最大サイズ: 8 Kb <-- 良好
# -1: 最大サイズ: 4 Kb <-- 良好
# 正の数は、その数だけ要素を格納することを意味します
# リストノードあたり。
# 最もパフォーマンスの高いオプションは通常 -2 (8 Kb サイズ) または -1 (4 Kb サイズ) です。
# ただし、使用ケースが特殊な場合は、必要に応じて設定を調整してください。
リストの最大 ziplist サイズ -2
 
# リストも圧縮される可能性があります。
# 圧縮深度は、各側のクイックリスト ziplist ノードの数です。
# 圧縮から*除外*するリスト。リストの先頭と末尾
# は高速なプッシュ/ポップ操作のために常に圧縮されません。設定は次のとおりです:
# 0: すべてのリスト圧縮を無効にする
# 1: 深さ1は「リストに1つのノードが追加されるまで圧縮を開始しない」という意味です。
# 頭からでも尾からでも行く"
# つまり、[head]->node->node->...->node->[tail]
# [head]、[tail] は常に圧縮されません。内部ノードは圧縮されます。
# 2: [head]->[next]->node->node->...->node->[prev]->[tail]
ここでの# 2は、headまたはhead->nextまたはtail->prevまたはtailを圧縮しないことを意味します。
# ただし、それらの間のすべてのノードを圧縮します。
# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]
# など
リスト圧縮深度 0
 
# セットが特別なエンコーディングを持つのは、セットが構成されている場合のみです。
範囲内の基数10の整数である文字列の数
64 ビット符号付き整数の数。
# 次の設定は、
# この特別なメモリ節約エンコーディングを使用するために設定します。
最大整数セットエントリ数 512
 
# ハッシュやリストと同様に、ソートされたセットも特別にエンコードされています。
# スペースを節約するために、このエンコードは長さと
ソートされたセットの要素数が次の制限を下回っています:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
 
# HyperLogLogスパース表現のバイト制限。制限には、
# 16バイトのヘッダー。HyperLogLogがスパース表現を使用する場合、
# この制限を超えると、密な表現に変換されます。
#
# 16000より大きい値は全く役に立たない。その時点で
# 高密度表現の方がメモリ効率が高くなります。
#
# メリットを得るための推奨値は約3000です
# PFADDをあまり遅くせずにスペース効率の良いエンコード、
# これはスパースエンコーディングではO(N)です。この値は
# CPUは問題ではないが、スペースが問題で、データセットが
# カーディナリティが 0 - 15000 の範囲にある多数の HyperLogLog で構成されます。
hll-スパース最大バイト数 3000
 
# アクティブリハッシュはCPU時間の100ミリ秒ごとに1ミリ秒を消費します。
# メインのRedisハッシュテーブル（トップレベルのハッシュテーブルをマッピングするもの）を再ハッシュするのを助けるために
# キーから値へ）。Redis が使用するハッシュ テーブルの実装 (dict.c を参照)
# 遅延再ハッシュを実行します。ハッシュテーブルで実行する操作が増えるほど
# 再ハッシュの場合、より多くの再ハッシュ「ステップ」が実行されるため、
# サーバーがアイドル状態の場合、再ハッシュは完了せず、さらにメモリが使用されます
# ハッシュテーブルによって。
#
# デフォルトでは、このミリ秒を毎秒10回使用して
# メイン辞書を積極的に再ハッシュし、可能な場合はメモリを解放します。
#
# 不明な場合:
# レイテンシ要件が厳しく、
# Redisが時々応答することは、あなたの環境では良いことではありません
# 2 ミリ秒の遅延でクエリを実行します。
#
# それほど厳しい要件がない場合は「activerehashing yes」を使用してください。
# 可能であればできるだけ早くメモリを解放したい。
アクティブリハッシュ はい
 
# クライアント出力バッファ制限はクライアントの切断を強制するために使用できます
# 何らかの理由でサーバーから十分な速度でデータを読み取れない（
# 一般的な理由は、Pub/Subクライアントが、
# 出版社が制作することも可能です。
#
# 制限は、3 つの異なるクライアント クラスごとに別々に設定できます。
#
# 通常 -> MONITOR クライアントを含む通常のクライアント
# スレーブ -> スレーブクライアント
# pubsub -> 少なくとも 1 つの pubsub チャネルまたはパターンにサブスクライブしているクライアント
#
# すべての client-output-buffer-limit ディレクティブの構文は次のとおりです。
#
# client-output-buffer-limit <クラス> <ハード制限> <ソフト制限> <ソフト秒数>
#
# ハードリミットに達すると、クライアントは直ちに切断されます。
# ソフト制限に達し、指定された回数だけ達したままになる
# 秒（連続）。
# 例えば、ハード制限が32メガバイトでソフト制限が
# 16メガバイト/10秒の場合、クライアントは直ちに切断されます
# 出力バッファのサイズが32メガバイトに達した場合、
# クライアントが16メガバイトに達し、継続的に超過すると切断されます
# 10 秒間の制限。
#
# デフォルトでは、通常のクライアントはデータを受信しないため制限されません
# 尋ねることなく（プッシュ方式で）、リクエストの直後にのみ、
# 非同期クライアントは、データがより速く要求されるシナリオを作成する可能性があります
# 読み取れる量より多い。
#
# 代わりに、pubsubおよびslaveクライアントにはデフォルトの制限があります。
# サブスクライバーとスレーブはプッシュ形式でデータを受信します。
#
# ハード制限とソフト制限の両方をゼロに設定することで無効にできます。
クライアント出力バッファ制限 正常 0 0 0
クライアント出力バッファ制限 スレーブ 256MB 64MB 60
クライアント出力バッファ制限 pubsub 32mb 8mb 60
 
# Redisは内部関数を呼び出して、多くのバックグラウンドタスクを実行します。
# タイムアウト時にクライアントの接続を閉じ、期限切れのキーを消去します
# 決して要求されない、など。
#
# すべてのタスクが同じ頻度で実行されるわけではありませんが、Redisは
# 指定された「hz」値に従って実行するタスク。
#
# デフォルトでは「hz」は10に設定されています。値を上げると、より多くのCPUが消費されます。
# Redisはアイドル状態ですが、同時にRedisの応答性が向上します。
# 同時に期限切れになるキーが多数あり、タイムアウトが発生する場合があります
# より正確に処理されます。
#
# 範囲は1から500ですが、100を超える値は通常
# 良いアイデアです。ほとんどのユーザーはデフォルトの10を使用し、これを最大まで上げてください。
# 100 は、非常に低いレイテンシが要求される環境でのみ使用します。
10ヘルツ
 
# 子プロセスがAOFファイルを書き換える場合、次のオプションが有効になっていると
# ファイルは32MBのデータが生成されるごとにfsyncされます。これは便利です
# ファイルをディスクに段階的にコミットし、
# 大きなレイテンシの急増。
aof-rewrite-incremental-fsync はい

docker exec -it redis-cli を実行している Redis サービスのコンテナ ID