Redis Advanced - Redis の永続化 - コードワールド

元のテキストのアドレスが更新され、読書効果が向上しました。

Redis Advanced - Redis Persistence | CoderMast プログラミングマストhttps://www.codermast.com/database/redis/redis-advance-persistence.html

シングルポイント Redis の問題

データ損失の問題: Redis はインメモリストレージであるため、サービスを再起動するとデータが失われる可能性があります。Redis データ永続性を実装することで解決しました。
同時実行の問題: シングルノード Redis の同時実行機能は優れていますが、618 などの高同時実行シナリオを満たすことはできません。マスター/スレーブクラスターを構築して、読み取りと書き込みの分離を実現します。
障害回復の問題: Redis がダウンするとサービスが利用できなくなるため、自動障害回復方法が必要になります。Redis Sentinel を利用して正常性の検出と自動回復を行います。
ストレージ容量の問題: Redis はメモリに基づいており、単一ポイントに保存できるデータ量は、大量のデータの需要を満たすことが困難です。断片化されたクラスターを構築し、スロットメカニズムを使用して動的な拡張を実現します。

# RDB の永続化

RDB の正式名は Redis データベースバックアップファイル (Redis データバックアップファイル) で、Redis データスナップショットとも呼ばれます。簡単に言えば、メモリ内のすべてのデータはディスクに記録されます。Redis インスタンスに障害が発生して再起動したら、ディスクからスナップショットファイルを読み取り、データを復元します。

スナップショットファイルは RDB ファイルと呼ばれ、デフォルトでは現在の実行ディレクトリに保存されます。

saveコマンド: RDB スナップショットを作成します。これは Redis メインプロセスによって実行され、すべてのコマンドをブロックします。RDB はディスクに書き込む必要があり、IO 操作が遅くなります。
bgsaveコマンド: メインプロセスへの影響を避けるために、子プロセスを開始して RDB を実行します。

RDB は、Redis がダウンしているときに 1 回実行されます。

デフォルトでは、現在のディレクトリに dump.rdb ファイルが生成され、次回 Redis を起動するときに、デフォルトでこのファイルがロードされて Redis データが復元されます。

Redis には RDB をトリガーする内部メカニズムがあり、これは次の形式の redis.conf ファイルにあります。

<span style="color:#2c3e50"><code>save 900 1      // 900 秒内，如果至少有 1 个 key 被修改，则执行 bgsave
save 300 10     // 300 秒内，如果至少有 10 个 key 被修改，则执行 bgsave
save 60 10000   // 60 秒内，如果至少有 10000 个 key 被修改，则执行 bgsave
save ""         // 表示禁用 RDB

rdbcompression yes  // 是否压缩，建议不开启，压缩也会消耗 CPU ，磁盘空间相对廉价
dbfilename dump.rdb // RDB 文件名称
dir ./              // 文件保存的路径目录
</code></span>

bgsave の開始時に、メインプロセスが子プロセスを取得するためにフォークされ、子プロセスはメインプロセスのメモリデータを共有します。フォークが完了したら、メモリデータを読み取り、RDB ファイルに書き込みます。

フォークプロセスはブロックされており、現時点では Redis はクライアントのリクエストに応答できません。データのみをコピーするインデックスと同様に、フォークは実際のデータをコピーするのではなく、対応するページテーブルのみをコピーするため、フォークの速度は非常に高速です。

Fork はコピーオンライトテクノロジーを使用します。

メインプロセスが読み取り操作を実行すると、共有メモリにアクセスします
メインプロセスが書き込み操作を実行すると、データのコピーがコピーされて書き込み操作が実行されます。

極端な場合

子プロセスが新しいRDBファイルを書き込み、その際にメインプロセスが大量のデータを変更する場合、データをコピーする必要がありますが、メインプロセスがすべてのデータを変更する必要がある場合、元の2倍のメモリが必要となるため、Redisサービスを構成する際に実メモリのすべてをRedisに割り当てることができず、バッファ領域の一部を確保する必要があります。

RDB 永続性の概要:

RDB モードでの bgsave のプロセス:

メインプロセスをフォークして子プロセスを取得し、メモリ空間を共有します
子プロセスはメモリデータを読み取り、新しい RDB ファイルを書き込みます
古い RDB ファイルを新しい RDB ファイルに置き換えます

RDBはいつ実行されますか? 60 1000 を節約とはどういう意味ですか?

デフォルトでは、Redis サービスが停止しているときに RDB を実行します。
save 60 10000 は、60 秒以内に少なくとも 1000 件の変更が実行された場合に RDB がトリガーされることを意味します

RDBのデメリットは？

RDB の実行間隔が長く、2 回の RDB 書き込みの間にデータが失われるリスクがある
サブプロセスのフォーク、圧縮、RDB ファイルの書き出しには時間がかかります

# AOF 永続化

AOF の正式名称は Append Only File (追加ファイル) です。Redis によって処理されるすべての書き込みコマンドは AOF ファイルに記録され、コマンドログファイルとみなすことができます。

AOF はデフォルトで無効になっています。AOF を有効にするには、redis.conf 構成ファイルを変更する必要があります。

<span style="color:#2c3e50"><code>appendonly yes  // 是否开启 AOF 功能，默认是关闭的
appendfilename "appendonly.aof" // AOF 的文件名称
</code></span>

AOF コマンド記録の頻度は、redis.conf ファイルを通じて構成することもできます。

<span style="color:#2c3e50"><code>appendfsync always      // 表示每执行一次写命令，立刻记录到 AOF 文件中 
appendfsync everysec    // 写命令执行完先放入 AOF 缓冲区，然后每隔 1 秒将缓冲区数据写入到 AOF 文件，是默认方案
appendfsync no          // 写命令执行完先放入 AOF 缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
</code></span>

構成アイテム	ブラッシングのタイミング	アドバンテージ	欠点がある
いつも	同期ブラシディスク	高い信頼性、データ損失がほとんどない	パフォーマンスへの影響
毎秒	ブラシ/秒	中程度のパフォーマンス	最大 1 秒間のデータ損失
いいえ	オペレーティングシステムの制御	最高のパフォーマンス	信頼性が低く、大量のデータが失われる可能性がある

AOF は記録コマンドであり、AOF ファイルは RDB ファイルよりもはるかに大きくなります。また、AOF は同じキーに対する複数の書き込み操作を記録しますが、意味があるのは最後の書き込み操作だけです。bgrewriteaofコマンドを実行すると、最小限のコマンドでAOFファイルを書き換えることができ、同様の効果が得られます。

Redis は、しきい値がトリガーされると、AOF ファイルを自動的に書き換えます。しきい値は redis.conf で構成することもできます。

<span style="color:#2c3e50"><code>auto-aof-rewrite-percentage 100 // AOF 文件比上次文件增长多少百分比，则触发重写
auto-aof-rewrite-min-size 64mb  // AOF 文件体积最小多大以上才触发重写
</code></span>

# RDBとAOFの比較

RDBとAOFはそれぞれ一長一短ありますが、データのセキュリティ要件が高い場合には実際の開発では組み合わせて使用されることが多いです。

持続性	データの整合性	ファイルサイズ	ダウンタイムの回復速度	データ復旧の優先順位	システムリソースの使用量	使用するシーン
RDB	メモリ全体のスナップショットを定期的に取得します。	不完全、バックアップ間で失われた	圧縮が行われるため、ファイルサイズは小さくなります	すぐ	データの整合性が AOF ほど良くないため、低い	CPU とメモリの消費量が多くて重い
AOF	実行されたすべてのコマンドをログに記録します	ブラッシング方法にもよりますが、比較的完成度が高い	コマンドを記録すると、ファイルサイズが非常に大きくなります	遅い	データの整合性が高いため高	少ない、主にディスク IO リソースですが、AOF は再書き込み時に多くの CPU リソースとメモリリソースを消費します。