目次
AOF
RDBストレージのデメリット
- 大量の保存データ、低効率
- スナップショットのアイデアに基づくと、各読み取りと書き込みはすべてデータであり、データの量が膨大な場合、効率は非常に低くなります
- 大量のデータの下での低IOパフォーマンス
- フォーク、追加のメモリ消費に基づいて子プロセスを作成します
- ダウンタイムによるデータ損失のリスク
ソリューション
- すべてのデータを書き込むのではなく、データの一部のみを記録します
- データが変更されたかどうかを区別する難しさを軽減し、記録されたデータを記録操作プロセスに変更します
- データ損失のリスクを排除するために、すべての操作が記録されます
AOFコンセプト
- AOF（ファイルのみを追加）の永続性
- 各書き込みコマンドを独立したログに記録し、データを回復する目的を達成するために、再起動時にAOFファイルのコマンドを再実行します。
- RDBと比較すると、レコードデータをレコードデータ生成に変更するプロセスとして簡単に説明できます。
- AOFの主な機能は、データ永続性のリアルタイムパフォーマンスを解決することです。これは、現在、Redis永続性の主流の方法です。
AOF書き込みデータプロセス
AOF書き込みデータの3つの戦略（appendfsync）
常に（毎回）
- 各書き込み操作はAOFファイルに同期され、データエラーはゼロでパフォーマンスは低くなります。
毎秒（毎秒）
- バッファ内の命令を毎秒AOFファイルに同期し、高いデータ精度と高いパフォーマンスを実現します
- 突然のシステムダウンタイムの場合、1秒以内にデータが失われる
いいえ（システム制御）
- オペレーティングシステムはAOFファイルへの各同期のサイクルを制御し、プロセス全体は制御できません
AOF機能がオンになっている
- AOF永続化機能を開くかどうか、デフォルトは開いていません
- AOF書き込みデータ戦略
AOF関連の構成
- AOF永続ファイル名。デフォルトのファイル名はappendonly.aofではありません。appendonly-portnumber.aofを構成することをお勧めします。
- AOF永続ファイルの保存パスはRDB永続ファイルと一致しています。
例
AOFによるデータの書き込みで発生した問題
- 以下のコマンドを連続して実行した場合の対処方法
AOFの書き換え
- コマンドがAOFに書き込まれ続けると、ファイルはどんどん大きくなります。この問題を解決するために、Redisはファイルサイズを圧縮するAOF書き換えメカニズムを導入しました。AOFファイルのRedisでのデータの再書き込みは、AOFファイルを同期するための新しいコマンドを書き込むプロセスへのプロセスです。
- 最終結果が記録命令に対応するデータに変換される場合、コマンドは単に同じデータ実行ノードの複数の部分になります。
AOF書き換え機能
- ディスク使用量を減らし、ディスク使用率を改善します
- 永続性の効率を改善し、永続性の書き込み時間を短縮し、IOパフォーマンスを改善します
- データ回復時間を短縮し、データ回復効率を向上させる
AOF書き換えルール
- プロセスでタイムアウトしたデータは、ファイルに書き込まれなくなりました
- 無効な命令を無視し、インプロセスデータを使用して書き換え時に直接生成するため、新しいAOFファイルは最終的なデータ書き込みコマンドのみを保持します。
- 如delkey1、hdel key2、srem key3、set key4 111、set key4 222等
- 同じデータに対する複数の書き込みコマンドを1つのコマンドに結合します
- たとえば、lpush list1 a、lpush list1 b、lpush list1 cは、lpush list1abcに変換できます。
- リスト、セット、ハッシュ、zset、およびその他のタイプの過剰なデータ量によって引き起こされるクライアントバッファーのオーバーフローを防ぐために、各命令は最大64個の要素を書き込むことができます。
AOFリライト方式
auto-aof-rewrite-min-size
sizeauto-aof-rewrite-percentageパーセンテージ
例
- 構成ファイル
- 書き換え操作
- ビュー・ログ
AOF手動書き換え-bgrewriteaof命令のしくみ
AOF自動書き換え方式
- トリガー条件の設定を自動的に上書きします
auto-aof-rewrite-min-size size auto-aof-rewrite-percentage percent
- トリガー比較パラメーターを自動的に書き換えます（特定の情報を取得するには、コマンドinfo Persistenceを実行します）
aof_current_size aof_base_size
- 自動書き換えトリガー条件
例
- 情報を入力して情報を表示する
AOFワークフロー
- 注：自分でメインプロセスを開始するには、書き換えを実行します
- パラメータappendfsyncによって制御されるAOFバッファ同期ファイル戦略
- システム呼び出しの書き込みとfsyncの説明：
- 書き込み操作により、遅延書き込みメカニズムがトリガーされます。Linuxは、ハードディスクIOパフォーマンスを向上させるために、カーネルにページバッファーを提供します。
- 書き込み操作は、システムバッファへの書き込み直後に戻ります。
- 同期ハードディスク操作は、次のようなシステムスケジューリングメカニズムによって異なります。バッファページスペースがいっぱいであるか、特定の期間に達している。ファイルを同期する前に、この時点でシステムに障害が発生してダウンすると、バッファー内のデータが失われます。
- 単一ファイル操作（AOFファイルなど）の場合、fsyncは強制的なハードディスク同期を実行します。Fsyncは、ハードディスクがハードディスクに書き込まれて戻るまでブロックし、データの永続性を確保します。
- write、fsync、およびLinxに加えて、syncおよびfdatasync操作も提供します。
RDBとAOFの違い
RDBとAOFの選択
- データに非常に敏感なので、デフォルトのAOF永続化スキームを使用することをお勧めします
- AOF永続化戦略では、毎秒、fsyncを毎秒1回使用します。この戦略redisは、引き続き良好な処理パフォーマンスを維持できます。問題が発生した場合、最大で0〜1秒以内のデータが失われる可能性があります。
- 注：AOFファイルのストレージ容量が大きいため、回復速度は遅くなります
- データ提示段階の有効性、RDB永続化スキームを使用することをお勧めします
- データは、ステージでの損失がなく（ステージは開発者または運用および保守担当者によって手動で保守されます）、リカバリ速度が速いことを十分に保証できます。ステージポイントのデータリカバリでは通常、RDBソリューションが使用されます
- 注：コンパクトなデータ永続性を実現するためにRDBを使用すると、Redisが非常に低くなります。慎重に要約してください。
- 包括的な比較
- RDBとAOFのどちらを選択するかは実際にはトレードオフであり、それぞれに長所と短所があります。
- 数分以内にデータの損失に耐えることができず、ビジネスデータに非常に敏感な場合は、AOFを選択してください
- 数分以内のデータ損失に耐え、大規模なデータセットの回復速度を追求できる場合は、RDBを選択してください
- 災害復旧のためのRDB
- 二重保険戦略、RDBとAOFを同時に開く、再起動後、RedisはAOFを使用してデータを回復し、失われるデータの量を減らすことを優先します
- [注]：Dark Horse Redisチュートリアルを参照してください：https：//www.bilibili.com/video/BV1AE411j7Wq？ t = 5