redisの永続化方式RDB,AOFとその2つの違い

一:なぜデータを永続化するのか
プロジェクトではredisをキャッシュとして使用し、複数のビジネス間でデータの共有を容易にするために、redisのデータはメモリに格納されているため、永続化が構成されていなければ、redisが再起動するとデータがすべて失われ、redisの永続化機能をオンにしてデータをディスクに保存し、redisが再起動するとディスクからデータを復元することができる.redisは、RDBの永続化(メモリ内のRedisのデータベース記録タイミングdumpをディスク上のRDBに永続化する原理)と、AOFの永続化(redisの操作ログを追加的にファイルに書き込む原理)の2つの方法で永続化を行う.
二:RDBとAOFの違い
RDB永続化とは、メモリ内のデータセットスナップショットを所定の時間間隔でディスクに書き込むことであり、実際の操作プロセスはforkのサブプロセスであり、まずデータセットを一時ファイルに書き込み、書き込みに成功した後、前のファイルを置き換え、バイナリ圧縮で格納する.
 
AOFは、サーバが処理した書き込み、削除操作をログ形式で記録することを永続化し、クエリー操作は記録されず、テキスト形式で記録され、ファイルを開いて詳細な操作記録を見ることができる.
三:RDBとAOFの長所と短所
RDBの利点:
1:RDBは、ある時点におけるRedisのデータセットを保存する非常にコンパクトなファイルである.このファイルはバックアップに適しています.たとえば、最近の24時間以内にRDBファイルを1時間に1回バックアップし、毎月の毎日に1つのRDBファイルをバックアップすることができます.これにより、問題が発生しても、いつでもデータセットを異なるバージョンに復元することができます.
2:RDBはディザスタリカバリ(disaster recovery)に非常に適しています.ファイルは1つしかなく、コンテンツは非常にコンパクトで、(暗号化後)他のデータセンターやアマゾンS 3に転送することができます.
3:RDBはRedisの性能を最大化することができます:親プロセスはRDBファイルを保存する時に唯一しなければならないのはforkが1つのサブプロセスを出して、それからこのサブプロセスは次のすべての保存作業を処理して、親プロセスはいかなるディスクI/O操作を実行する必要はありません.
4:RDBは、大きなデータセットを復元する際の速度がAOFよりも速い.
RDBの欠点:
1:サーバ障害時にデータを失うことをできるだけ避ける必要がある場合は、RDBはあなたに適していません.Redisでは、異なるセーブポイントを設定してRDBファイルを保存する頻度を制御できますが、RDBファイルはデータセット全体の状態を保存する必要があるため、簡単な操作ではありません.そのため、少なくとも5分でRDBファイルを保存することができます.この場合、障害が発生して停止すると、数分間のデータが失われる可能性があります.
2:RDBを保存するたびに、Redisはfork()個のサブプロセスを出し、サブプロセスによって実際の永続化作業を行う.データセットが膨大な場合、fork()は非常に時間がかかり、サーバがミリ秒以内にクライアントの処理を停止する可能性があります.データセットが非常に大きく、CPU時間が非常に緊張している場合、この停止時間は丸1秒にも及ぶ可能性があります.AOF書き換えもfork()を行う必要があるが、AOF書き換えの実行間隔がどれだけ長くてもデータの耐久性には何ら損失はない.
AOFのメリット:
1:AOF永続化を使用するとRedisは非常に耐久性があります(much more durable):fsyncなし、毎秒fsync、または書き込みコマンドを実行するたびにfsyncなどの異なるfsyncポリシーを設定できます.AOFのデフォルトポリシーは毎秒fsyncであり、この構成ではRedisは依然として良好な性能を維持することができ、障害停止が発生しても最大1秒のデータしか失われない(fsyncはバックグラウンドスレッドで実行されるため、メインスレッドはコマンド要求を継続的に処理することができる).
2:AOFファイルは追加操作のみを行うログファイル(append only log)であるため、AOFファイルの書き込みにはseekを必要とせず、ログに何らかの理由で書き込みが完了していないコマンド(書き込み時にディスクがいっぱいになったり、書き込みが途中で停止したりするなど)が含まれていても、redis-check-aofツールはこの問題を簡単に修復することができます.
3:Redisは、AOFファイルのボリュームが大きすぎると、AOFをバックグラウンドで自動的に書き換えることができます.書き換えられた新しいAOFファイルには、現在のデータセットを復元するために必要な最小コマンドセットが含まれています.Redisは新しいAOFファイルを作成する過程で、既存のAOFファイルにコマンドを追加し続けるため、書き換え中にダウンタイムが発生しても、既存のAOFファイルは失われません.新しいAOFファイルの作成が完了すると、Redisは古いAOFファイルから新しいAOFファイルに切り替え、新しいAOFファイルの追加操作を開始します.
4:AOFファイルはデータベースに対して実行されたすべての書き込み操作を秩序正しく保存しており、これらの書き込み操作はRedisプロトコルの形式で保存されているため、AOFファイルの内容は非常に読みやすく、ファイルの分析(parse)も容易である.エクスポート(export)AOFファイルも簡単です.たとえば、FLUSHALLコマンドをうっかり実行しても、AOFファイルが書き換えられていない限り、サーバを停止し、AOFファイルの末尾にあるFLUSHALLコマンドを削除し、Redisを再起動すれば、FLUSHALL実行前の状態にデータセットを復元できます.
AOFの欠点:
1:AOFファイルのボリュームは、同じデータセットの場合、通常RDBファイルのボリュームよりも大きくなります.
2:AOFの速度は、使用されるfsyncポリシーに従ってRDBよりも遅くなる可能性がある.一般的には、毎秒fsyncの性能は依然として非常に高いが、fsyncを閉じることで、高負荷下でもAOFの速度をRDBと同じように速くすることができる.しかし、大きな書き込みロードを処理する場合、RDBは、より保証された最大遅延時間(latency)を提供することができる.
3:AOFは過去にこのようなバグが発生したことがある:個別の命令のため、AOFファイルが再ロードされると、データセットを保存時のままに復元できない.△たとえば、ブロックコマンドBRPOLPUSHは、このようなバグを引き起こしたことがある.テストキットには、ランダムで複雑なデータセットが自動的に生成され、これらのデータを再ロードすることですべてが正常であることを確認するテストが追加されています.このようなバグはAOFファイルではあまり見られないが,比較的RDBではこのようなバグはほとんど起こり得ない.
四:常用配置
RDB永続化構成
Redisはデータセットのスナップショットdumpをdumpにします.rdbファイルにあります.また、プロファイルによりRedisサーバdumpのスナップショットの頻度を変更する、6379を開くこともできる.confファイルの後、saveを検索すると、次の構成情報が表示されます.
save 900 1#900秒(15分)後、少なくとも1つのkeyが変化した場合、dumpメモリスナップショット.
save 300 10#300秒(5分)後、少なくとも10個のkeyが変化した場合、dumpメモリスナップショット.
save 60 10000#60秒(1分)後、少なくとも10000 keyが変化した場合、dumpメモリスナップショット.
AOF持続化構成
Redisのプロファイルには、次の3つの同期方法があります.
appendfsync always#データ変更が発生するたびにAOFファイルに書き込まれます.
appendfsync everysec#AOFのデフォルトポリシーである毎秒同期します.
appendfsync no#は同期していません.効率的ですが、データは永続化されません.