目次
3.4.1書き換えプロセスの分析（書き換え操作全体は絶対に安全です）：
Redisの永続性
1.なぜ持続するのか
Redisはインメモリデータベースであり、データはダウンタイム後に消えます。アクセスがDBにヒットし、キャッシュアバランシェ（多数のキー）が発生します
。Redisの再起動後、データをすばやく復元できます。永続性メカニズムを提供するために、
Redisの永続性は、データを保存するのではなく、データをすばやく復元することです。
Redisには、RDBとAOFの2つの永続化方法があります。
注：Redisの永続性は、データの整合性を保証するものではありません。
RedisをDBとして使用する場合、DBデータは完全である必要があるため
、システムの起動時に完全なデータソース（ファイル、mysql）が存在し、この完全なデータソースからのデータがRedisに読み込まれます。
データの量小さくて簡単ではない変更など：辞書ライブラリ（xml、テーブル）
infoコマンドを使用して永続性に関する情報を表示できます
＃永続
ローディング：0
rdb_changes_since_last_save：1
rdb_bgsave_in_progress：0
rdb_last_save_time：1589363051
rdb_last_bgsave_status：OK
rdb_last_bgsave_time_sec：-1
rdb_current_bgsave_time_sec：-1
rdb_last_cow_size：0
aof_enabled：1
aof_rewrite_in_progress：0
aof_rewrite_scheduled：0
aof_last_rewrite_time_sec：-1
aof_current_rewrite_time_sec：-1
aof_last_bgrewrite_status：OK
aof_last_write_status： ok
aof_last_cow_size：0
aof_current_size：58
aof_base_size：0
aof_pending_rewrite：0
aof_buffer_length：0
aof_rewrite_buffer_length：0
aof_pending_bio_fsync：0
aof_delayed_fsync：0
2 RDB
RDB（Redis DataBase）はredisのデフォルトのストレージ方式であり、RDB方式はスナップショットを介して完了します。
現時点でのデータ
はプロセスに注意を払っていません
2.1スナップショットをトリガーする方法
1.カスタム構成のスナップショットルールに準拠します
。2。saveまたはbgsaveコマンドを
実行します。3。fluxhallコマンドを実行します。4
。マスター/スレーブコピー操作を実行します（初回）。
構成パラメーターは定期的に実行されます
redis.confで構成します。save<seconds> <changes>データが変更された秒数
save "" # 不使用RDB存储 不能主从
save 900 1 # 表示15分钟（900秒钟）内至少1个键被更改则进行快照。
save 300 10 # 表示5分钟（300秒）内至少10个键被更改则进行快照。
save 60 10000 # 表示1分钟内至少10000个键被更改则进行快照。漏斗の設計はパフォーマンスを提供します
コマンド明示的トリガー
クライアントでbgsaveコマンドを入力します。
127.0.0.1:6379> bgsave
Background saving started
2.2 RDB実行プロセス（原則）
1. Redisの親プロセスは、最初に現在保存を実行しているか、bgsave / bgrewriteaof（ファイル書き換えコマンド）の子プロセスを実行しているかを判断します。実行中の場合、bgsaveコマンドは直接戻ります。
2.親プロセスはfork（OS関数を呼び出してメインプロセスをコピーする）操作を実行して子プロセスを作成します。このコピープロセス中、親プロセスはブロックされ、Redisはクライアントからコマンドを実行できません。
3.親プロセスがフォークした後、bgsaveコマンドは「バックグラウンド保存が開始されました」というメッセージを返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります。
4.子プロセスは、RDBファイルを作成し、親プロセスのメモリスナップショットに基づいて一時スナップショットファイルを生成し、完了後に元のファイルをアトミックに置き換えます。（RDBは常に完全です）
5.子プロセスは、完了を示すシグナルを親プロセスに送信し、親プロセスは統計を更新します。
6.親プロセスが子プロセスをフォークした後、作業を続行します。
2.3RDBファイル構造
1.ヘッダーの5バイトは「REDIS」文字列
2として固定され、4バイトの「RDB」バージョン番号（Redisバージョン番号ではない）は現在9であり、入力後は0009です。3
。の補助フィールドキー値の形式
4.データベース番号を保存します
。5。辞書のサイズ
6.期限切れのキー
7.メインデータはキー値の形式で保存されます
8.終了マーク
9.チェックサムはファイルが破損または変更されていないかどうかを確認するためのものです。
winhexでdump.rdbファイルを開いて表示できます。
2.4RDBの長所と短所
利点
RDBは、小さなスペースを占めるバイナリ圧縮ファイルであり、（スレーブへの）送信に便利です。
メインプロセスは子プロセスをフォークします。Redisのパフォーマンスを最大化できます。メインプロセスは大きすぎて、Redisの量を増やすことはできません。データが大きすぎることはできず、コピー中にメインプロセスがブロックされます
短所
データの整合性は保証されておらず、最後のスナップショット以降に変更されたすべてのデータが失われます
3 AOF
AOF（ファイルのみを追加）は、Redisのもう1つの永続化方法です。Redisはデフォルトではオンになっていません。AOF永続性を有効にした後
Redisは、データベースのステータスを記録する目的を達成するために、データベースに書き込まれたすべてのコマンド（およびそのパラメーター）（RESP）をAOFファイルに記録します。
このように、Redisを再起動すると、これらのコマンドが順番に再生されている限り、元の状態に復元されます。
AOFはプロセスを記録し、RDBは結果のみを考慮します
3.1AOF永続性の実装
redis.confを構成する
# 可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。
dir ./
# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改
appendfilename appendonly.aof
3.2AOFの原則
AOFファイルにはredisコマンドが格納されています。コマンドをAOFファイルに同期するプロセス全体は、次の3つの段階に分けることができます。
コマンドの伝播： Redisは、実行されたコマンド、コマンドパラメーター、およびコマンドパラメーターの数をAOFプログラムに送信します。
キャッシュの追加： AOFプログラムは、受信したコマンドデータに従ってコマンドをネットワーク通信プロトコルの形式に変換し、プロトコルの内容をサーバーのAOFキャッシュに追加します。
ファイルの書き込みと保存： AOFキャッシュ内のコンテンツはAOFファイルの最後に書き込まれます。設定されたAOF保存条件が満たされると、fsync関数またはfdatasync関数が呼び出され、書き込まれたコンテンツが実際にディスクに保存されます。
3.2.1コマンドの伝播
Redisクライアントがコマンドを実行する必要がある場合、ネットワーク接続を介してプロトコルテキストをRedisサーバーに送信します。サーバーはクライアントの要求を受信すると、プロトコルテキストの内容に応じて適切なコマンド関数を選択し、各パラメーターを文字列テキストからRedis文字列オブジェクト（StringObject）に変換します。コマンド機能が正常に実行されると、コマンドパラメータがAOFプログラムに伝播されます。
3.2.2キャッシュ追加
コマンドがAOFプログラムに伝播された後、プログラムは、コマンドとそのパラメーターに従って、コマンドを文字列オブジェクトから元のプロトコルテキストに変換します。プロトコルテキストが生成された後、redis.h / redisServer構造体のaof_bufの最後に追加されます。
redisServer構造体はRedisサーバーの状態を維持し、aof_bufフィールドはAOFファイルへの書き込みを待機しているすべてのプロトコルテキスト（RESP）を保持します。
3.2.3ファイルの書き込みと保存
サーバールーチンタスク関数が実行されるか、イベントハンドラーが実行されるたびに、aof.c / flushAppendOnlyFile関数が呼び出されます。この関数は、次の2つのタスクを実行します。
書き込み：条件に従って、aof_bufのバッファーをAOFファイルに書き込みます。 。
保存：条件に応じて、fsyncまたはfdatasyncのOS関数を呼び出して、AOFファイルをディスクに保存します。
3.3AOF保存モード
Redisは現在、次の3つのAOF保存モードをサポートしています。
AOF_FSYNC_NO：保存しないでください。
AOF_FSYNC_EVERYSEC：1秒に1回保存します。（デフォルト）
AOF_FSYNC_ALWAYS：コマンドが実行されるたびに保存します。（非推奨）
次の3つのサブセクションでは、これら3つの保存モードについてそれぞれ説明します。
保存しない
このモードでは、flushAppendOnlyFile関数が呼び出されるたびにWRITEが実行されますが、SAVEはスキップされます。
SAVEは、次のいずれかの状況でのみ実行されます。
Redisはシャットダウンされます
AOF機能がオフになっている
システムの書き込みキャッシュが更新されます（キャッシュがいっぱいであるか、通常の保存操作が実行されている可能性があります）
これらの3つの場合のSAVE操作により、メインのRedisプロセスがブロックされます。
1秒ごとに保存（推奨）
このモードでは、SAVE操作はバックグラウンドの子スレッド（フォーク）によって呼び出されるため、原則として1秒ごとに実行され、メインサーバーのプロセスブロックは発生しません。
コマンドを実行するたびに保存する
このモードでは、すべてのコマンドを実行した後、WRITEとSAVEが実行されます。
さらに、SAVEはRedisメインプロセスによって実行されるため、メインプロセスはSAVEの実行中にブロックされ、コマンド要求を受け入れることができません。
AOF保存モードがパフォーマンスとセキュリティに与える影響
3つのAOF保存モードの場合、メインサーバープロセスのブロックは次のとおりです。
3.4 AOF書き換え、トリガーモード、ハイブリッド永続性
AOF記録データの変化過程はますます大きくなっており、「スリム」に書き直す必要があります
Redisは、AOFボリュームが大きくなりすぎると、バックグラウンド（Forkサブプロセス）でAOFを自動的に書き換えることができます。書き換えられた新しいAOFファイルには、現在のデータセットを復元するために必要な最小限のコマンドセットが含まれています。いわゆる「書き換え」は、実際にはあいまいな用語です。実際、AOF書き換えは、元のAOFファイルの書き込みや読み取りを必要とせず、データベース内のキーの現在の値を対象としています。
例えば次のようである：
セットS1 11
セットS1 22 ------->セット33 s1は
セットS1 33
最適化なし：
set s1 11
set s1 22
set s1 33
最適化後：
s133を設定します
lpush list1 1 2 3
lpush list1 4 5 6 --------> list1 1 2 3 4 5 6
最適化後、
リストをプッシュ1 1 2 3 4 5 6
Redisは、AOF書き換えによってサーバーが要求を処理できなくなることを望まないため、RedisはAOF書き換えプログラムを（バックグラウンド）サブプロセスに配置して実行することにしました。この処理の最大の利点は次のとおりです。
1.子プロセスのAOF書き換え中、メインプロセスはコマンド要求の処理を続行できます。
2.子プロセスにはメインプロセスのデータのコピーがあり、スレッドの代わりに子プロセスを使用して、ロックを回避しながらデータのセキュリティを確保します。
ただし、サブプロセスを使用する場合は解決する必要のある問題があります。サブプロセスはAOFの書き換えを実行しているため、メインプロセスは引き続きコマンドの処理を続行する必要があり、新しいコマンドによって既存のデータが変更され、現在のデータベースデータが作成される場合があります。書き換えられたAOFファイルのデータに一貫性がありません。
この問題を解決するために、RedisはAOFリライトキャッシュを追加しました。このキャッシュは、子プロセスがフォークされた後に有効になります。新しい書き込みコマンドを受信した後、メインのRedisプロセスは書き込みコマンドのプロトコルコンテンツを既存のInに追加します。 AOFファイルに加えて、このキャッシュにも追加されます。
3.4.1書き換えプロセスの分析（書き換え操作全体は絶対に安全です）：
新しいAOFファイルを作成する過程で、Redisは既存のAOFファイルにコマンドを追加し続けます。書き換えプロセス中にシャットダウンが発生した場合でも、既存のAOFファイルは失われません。新しいAOFファイルが作成されると、Redisは古いAOFファイルから新しいAOFファイルに切り替えて、新しいAOFファイルの追加を開始します。
子プロセスがAOF書き換えを実行している場合、メインプロセスは次の3つのタスクを実行する必要があります。
コマンド要求を処理します。
既存のAOFファイルに書き込みコマンドを追加します。
書き込みコマンドをAOF書き換えキャッシュに追加します。
このようにして、次のことを保証できます。
既存のAOF機能は引き続き実行され、AOFの書き換え中にダウンタイムが発生しても、データが失われることはありません。データベースを変更するすべてのコマンドは、AOF書き換えキャッシュに記録されます。子プロセスがAOFの書き換えを完了すると、親プロセスに完了シグナルを送信します。完了シグナルを受信した後、親プロセスはシグナル処理関数を呼び出し、次のタスクを完了します。
1.AOF書き換えキャッシュのすべての内容を新しいAOFファイルに書き込みます。
2.新しいAOFファイルの名前を変更して、元のAOFファイルを上書きします。
Redisデータベースの+ AOF書き換えプロセスのコマンド------->新しいAOFファイル---->古いファイルを上書きする
手順1を実行すると、既存のAOFファイル、新しいAOFファイル、およびデータベースのステータスは完全に一致します。
ステップ2が完了すると、プログラムは新しいAOFファイルと古いAOFファイルの交代を完了します。
この信号処理機能が実行された後、メインプロセスは通常どおりコマンド要求を受け入れ続けることができます。AOFバックグラウンド書き換えプロセス全体では、最後の書き込みキャッシュと名前変更操作のみがメインプロセスをブロックします。それ以外の場合、AOFバックグラウンド書き換えはメインプロセスをブロックしないため、AOFのパフォーマンスへの書き換えが最小限に抑えられます。
上記は、AOFバックグラウンド書き換え、つまりBGREWRITEAOFコマンド（AOF書き換え）の動作原理です。
3.4.2トリガーモード
1.redis.confでトリガー構成を構成します
# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
auto-aof-rewrite-min-size 64mb2.bgrewriteaofコマンドを実行します
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
3.4.3ハイブリッド永続性
RDBとAOFにはそれぞれ長所と短所があります。Redis4.0はRDBとAOFのハイブリッド永続性をサポートし始めました。混合永続性がオンになっている場合、rdbのコンテンツは、aofの書き換え中にaofファイルの先頭に直接書き込まれます。
RDBヘッド+ AOFボディ----> appendonly.aof
ハイブリッド永続性をオンにする
aof-use-rdb-preamble yes 
AOFファイルがRDBファイルのヘッダーであり、AOF形式のコンテンツであることがわかります。ロード時に、AOFファイルがREDIS文字列で始まるかどうかを最初に識別します。そうである場合は、RDB形式でロードします。 RDBをロードし、引き続きAOF形式を押します。残りをロードします。
3.4.4AOFファイルのロードとデータ復元
AOFファイルにはデータベースの状態を再構築するために必要なすべての書き込みコマンドが含まれているため、サーバーはAOFファイルに保存されている書き込みコマンドを読み込んで再実行するだけで、サーバーがシャットダウンする前にデータベースの状態を復元できます。RedisはAOFを読み取ります。ファイルを作成し、データベースを復元します。ステータスの詳細な手順は次のとおりです。
1.ネットワーク接続なしで偽のクライアントを作成する：Redisコマンドはクライアントコンテキストでのみ実行でき、AOFファイルのロード時に使用されるコマンドはネットワーク接続ではなくAOFファイルから直接取得されるため、サーバーはAOFファイルに保存されている書き込みコマンドを実行するためのネットワーク接続のない疑似クライアントコマンドを実行する疑似クライアントの効果は、ネットワーク接続のあるクライアントの効果とまったく同じです。
2.AOFファイルから書き込みコマンドを分析して読み取ります
3.疑似クライアントを使用して読み取りコマンドを実行します
4. AOFファイル内のすべての書き込みコマンドが処理されるまで、手順2と3を実行し続けます。
上記の手順を完了すると、AOFファイルに保存されているデータベースの状態が完全に復元されます。プロセス全体を次の図に示します。
4RDBとAOFの比較
1. RDBは、バイナリ圧縮ストレージ、AOFストレージ操作コマンド、テキストストレージ（ハイブリッド）を使用して、特定の時点でデータのスナップショットを保存します
。2。RDBのパフォーマンスが高く、AOFのパフォーマンスが低い
3. RDBは、その後、構成トリガー状態を失います。最後のスナップショット変更されたすべてのデータについて、AOFが1秒に1回保存するように設定されている場合、データは最大2秒失われ
ます。4。Redisはマスターサーバーモードで実行され、RDBは期限切れのキーと値のペアデータを保存しません。Redisスレーブサーバーモードで実行される場合、RDBは期限切れのデータキーと値のペアを保存し、マスターサーバーがスレーブサーバーと同期するときに、期限切れのキーと値のペアをクリアします。
AOFがファイルに書き込まれると、期限切れのキーにdelコマンドが追加されます。AOFの書き換えが実行されると、期限切れのキーとdelコマンドは無視されます。
5アプリケーションシナリオ
インメモリデータベースのrdb + aofデータは簡単に失われません
。元のデータソース：起動するたびに元のデータソースから初期化されるため、永続性（少量のデータ）を開く必要はありません。
キャッシュサーバーRDB一般的に高性能です
データが復元されるときに、
rdb + aofがある場合、RDBによってファイルが失われるため、aofが復元され、AOFの相対データが完全である必要があります。
rdbのみ、rdbを復元
プルフック構成戦略
高いパフォーマンスを追求する：redisのダウンタイムなしでデータソースから復元する
辞書ライブラリ：追放せず、永続性なしでデータの整合性を確保する
DBとして使用すると、メイン
および従属データボリュームが小さくなく、キャッシュパフォーマンスが高くなります
。RDBRedisデータボリュームストレージを開くと、パフォーマンスが急激に低下し、
フォーク時間が長すぎてメインプロセスをブロックできません。 、
AOFのみを開く