目次
どのメモリ データのスナップショットを作成する必要がありますか?
RDB ファイルの生成によりメインスレッドがブロックされますか?
Redis の RDB によって引き起こされるデータ損失の問題
メインスレッド、子プロセス、バックグラウンドスレッドの関係と違いは何ですか?
Redis 永続化プロセスに他の潜在的なブロック リスクはありますか?
AOF がマスター ライブラリとスレーブ ライブラリ間のレプリケーションに使用されないのはなぜですか?
ロックの有効期限を評価するのが難しい場合はどうすればよいですか?
分散ロックはウォッチドッグ コードを追加することで実装されます。
持久化
Redis はインメモリ データベースですが、Redis は RDB と AOF という 2 つの永続化メカニズムをサポートしています。ディスクにデータを書き込むことで、プロセスの終了によるデータ損失を効果的に回避できます。これは、次回の再起動時に以前に永続化されたファイルを使用することで実現できます。 。
RDB
RDB 永続化は、現在のプロセス データのスナップショットを生成し、ハードディスクに保存するプロセスです。いわゆるメモリ スナップショットは、特定の瞬間におけるメモリ内のデータの状態記録を指します。これは写真と同じで、友達の写真を撮ると、その瞬間の友達の姿が写真に完全に記録されます。RDBはRedis Databaseの略称です。
どのメモリ データのスナップショットを作成する必要がありますか?
Redis データはすべてメモリ内にあり、すべてのデータの信頼性を確保するために、完全なスナップショットが実行されます。つまり、メモリ内のすべてのデータがディスクに記録されます。ただし、RDB ファイルが大きくなるほど、ディスクへのデータの書き込み時間のオーバーヘッドも大きくなります。
RDB ファイルの生成によりメインスレッドがブロックされますか?
Redis には、RDB ファイルを生成するための 2 つの手動コマンド、save と bgsave が用意されています。
save: メインスレッドで実行するとブロッキングが発生します。比較的大きなメモリを備えたインスタンスなどでは、長期的なブロッキングが発生するため、オンライン環境には推奨されません。bgsave: メイン スレッドのブロックを回避して、RDB ファイルの書き込み専用のサブプロセスを作成します。これは、Redis RDB ファイル生成のデフォルト構成でもあります。
コマンド実践デモ
コマンドの実行による手動トリガーに加えて、Redis 内には次のシナリオのように RDB を自動的にトリガーする永続化メカニズムもあります。
1) 「save mn」などの保存関連の設定を使用します。データセットが m 秒以内に n 回変更されると、bgsave が自動的にトリガーされることを示します。
2) スレーブノードがフルコピー操作を実行すると、マスターノードは自動的に bgsave を実行して RDB ファイルを生成し、スレーブノードに送信します。
3) debug reload コマンドを実行して Redis をリロードすると、保存操作も自動的にトリガーされます。
4) デフォルトでは、shutdown コマンド実行時に、AOF 永続化機能が有効になっていない場合、bgsave が自動的に実行されます。
RDB 永続性をオフにするには、コースで説明されている Redis バージョン (6.2.4) で、構成ファイル内の保存構成を「」を保存するように変更します。
bgsave実行処理
スナップショットのために書き込み操作を一時停止することは、決して容認できません。そのため、現時点では、Redis はオペレーティング システムが提供するコピー オン ライト (COW) テクノロジを使用して、スナップショットの実行中に書き込み操作を通常どおり処理します。
bgsave サブプロセスはメインスレッドの fork によって生成され、メインスレッドのすべてのメモリ データを共有できます。bgsave サブプロセスが実行されると、メインスレッドのメモリ データの読み取りが開始され、RDB ファイルに書き込まれます。
メイン スレッドがこれらのデータ (図のキーと値のペア A など) に対して読み取り操作も実行する場合、メイン スレッドと bgsave サブプロセスは相互に影響しません。ただし、メインスレッドがデータの一部 (図のキーと値のペア B など) を変更したい場合は、