一.概念の紹介

redisは、RDB(Redis DataBase)とAOF(Apend Only File)の2つの永続化方式を提供する.

RDB方式

RDB方式は、ある時点のデータをディスクに永続化するスナップショット式の永続化方法である.

redisは、データの永続化中に、最後に永続化されたファイルをこの一時ファイルに置き換える前に、一時ファイルにデータを書き込みます.この機能により、スナップショットファイルは常に完全に使用可能であるため、いつでもバックアップできます.

RDB方式の場合、redisは単独で永続化するためにサブプロセスを作成し、メインプロセスはIO操作を行わないため、redisの極めて高い性能を確保する.

大規模データのリカバリが必要であり、データリカバリの完全性に非常に敏感でない場合、RDB方式はAOF方式よりも効率的である.

AOF方式

AOF方式は,実行した書き込み命令を記録し,データ復元時に叢前から後の順にもう一度命令を実行する.

AOFコマンドは、書き込み毎の操作をファイルの末尾までredisプロトコルで追加保存する.Redisはまた、AOFファイルをバックグラウンドで書き換えることができ、AOFファイルの体積が過大にならないようにすることができる.デフォルトのAOF永続化ポリシーは、1秒に1回fsync(fsyncはキャッシュ内の書き込み命令をディスクに記録することを意味する)です.この場合、redisは依然として良好な処理性能を維持することができ、redisが故障しても、最近の1秒のデータしか失われません.

ログを追加する場合、ディスク領域がいっぱい、inodeがいっぱい、または電源が切れているなどの状況に遭遇してログの書き込みが不完全になっても構いません.redisはredis-check-aofツールを提供し、ログの修復に使用できます.

は追加方式を採用しているため、何も処理しないとAOFファイルがますます大きくなるため、AOFファイルのサイズが設定したしきい値を超えると、AOFファイルのコンテンツ圧縮を開始し、データを復元できる最小命令セットのみを保持するAOFファイル書き換え機構を提供している.例を挙げると、INCRコマンドを100回呼び出すと、AOFファイルに100個のコマンドが格納されますが、これは明らかに非効率で、この100個のコマンドをSETコマンドに統合することができます.これが書き換えメカニズムの原理です.

AOF書き換えを行う場合も、一時ファイルを先に書き、すべて完了してから置き換えるプロセスを採用しているため、電源オフ、ディスクオーバーなどの問題はAOFファイルの可用性に影響しません.

二.二つの方式の長所と短所

1.RDB方式

の利点:

RDBは単一のコンパクトファイルで、ある時点のデータセットを保存し、データセットのバックアップに非常に適しています.例えば、過去24時間のデータを1時間ごとに保存し、毎日過去30日間のデータを保存することができます.これにより、問題が発生しても、必要に応じて異なるバージョンのデータセットに復元することができます.

RDBはコンパクトな単一ファイルで、転送が便利で、災害復旧に適している.

RDBはRDBファイルを保存する際に親プロセスが唯一しなければならないのはforkが1つのサブプロセスを出すことであり、次の仕事はすべてサブプロセスによって行われ、親プロセスは他のIO操作を行う必要がないため、RDB持続化方式はredisの性能を最大化することができる.

は、AOFよりも大きなデータセットを復元する際にRDB方式の方が速い.

欠点:

Redisは予期せぬダウンタイムで、構成されたsave時点に応じて数分間のデータが失われる可能性があります.RDB方式では、データセット全体を保存する必要があり、比較的煩雑な作業であり、通常は5分以上で完全な保存を行う必要があります.

RDBは、データセットをハードディスクに保存するために常にforkサブプロセスを必要とするが、データセットが比較的大きい場合、forkのプロセスは非常に時間がかかり、Redisがクライアントの要求に応答できない可能性がある.データセットが巨大でCPUのパフォーマンスがあまりよくない場合、この状況はより長く続きます.

2.AOF方式

の利点

AOFを使用すると、Redisデータがより耐久性が向上します.異なるfsyncポリシーを使用できます.fsyncなし、fsync毎秒、fsync、書くたびにfsyncを使用できます.デフォルトの毎秒fsyncポリシーを使用すると、Redisのパフォーマンスは依然として良好です(fsyncはバックグラウンドスレッドで処理され、メインスレッドはクライアント要求を処理するように努力します).障害が発生すると、最大1秒のデータが失われます.

AOFファイルは、追加のみを行うログファイルなのでseekに書き込む必要はありません.何らかの理由で(ディスク容量がいっぱいになったり、書き込み中にダウンタイムなど)書き込みコマンドが完全に実行されていない場合でも、redis-check-aofツールを使用してこれらの問題を修正することができます.

Redisは、AOFファイルのボリュームが大きすぎると、自動的にバックグラウンドでAOFを書き換えることができる.書き換えられた新しいAOFファイルには、現在のデータセットを復元するために必要な最小コマンドセットが含まれている.Redisは新しいAOFファイルを作成する過程で、既存のAOFファイルにコマンドを追加し続けるため、書き換え中にダウンタイムが発生しても、既存のAOFファイルは失われません.新しいAOFファイルの作成が完了すると、Redisは古いAOFファイルから新しいAOFファイルに切り替え、新しいAOFファイルの追加操作を開始します.

AOFファイルはデータベースに対して実行されたすべての書き込み操作を秩序正しく保存しており、これらの書き込み操作はRedisプロトコルの形式で保存されているため、AOFファイルの内容は非常に読みやすく、ファイルの分析も容易である.AOFファイルをエクスポートするのも簡単です.たとえば、FLUSHALLコマンドをうっかり実行しても、AOFファイルが書き換えられていない限り、サーバを停止し、AOFファイルの最後のFLUSHALLコマンドを削除し、Redisを再起動すれば、データセットをFLUSHALL実行前の状態に戻すことができます.

欠点

同じデータセットの場合、AOFファイルのボリュームは、通常、RDBファイルのボリュームよりも大きい.

AOFの速度は、使用されるfsyncポリシーに従ってRDBよりも遅くなる可能性がある.一般的に、毎秒fsyncの性能は依然として非常に高く、fsyncを閉じることで、高負荷でもAOFの速度をRDBと同じように速くすることができる.しかし、大きな書き込みロードを処理する場合、RDBは、より保証された最大遅延時間を提供することができる.

三.構成方法

1.RDB構成方式

デフォルトでは、スナップショットrdbの永続化方式であり、メモリ内のデータをスナップショットでバイナリファイルに書き込む、デフォルトのファイル名はdumpである.rdb redis.conf構成:

save 900 1 
save 300 10
save 60 10000

以上がデフォルトの構成です.900秒以内に、1つ以上のkeyが変更された場合、スナップショットの保存が開始されます.300秒以内に、10個以上のkeyが変更された場合、スナップショット保存が開始される.1分以内に1万個のkeyが変更された場合、スナップショット保存が開始されます.
この方式では、データの永続化を完全に保証することはできません.タイミング保存なので、redisサービスdownが落ちると、データの一部が失われ、データ量が多く、書き込み操作が多い場合、大量のディスクIO操作が発生し、性能に影響します.
したがって、この2つの方法が同時にオンになっている場合、データをリカバリする場合は、rdb永続化方式でデータベースをリカバリするべきではありません.

2.AOF配置方式

aofを使用して永続化し、各書き込みコマンドはwrite関数でappendonlyに追加する.aof中構成:aof永続化を開始する方法appendonly yes参考資料:https://redis.io/topics/persistence