Redisの起因離脱のプロセスに持続し、データの損失を回避するために、永続機構のRDBとAOF二種類をサポートします。
持続性の二種類だけではものを使用することができるが、多くの場合、両方の組み合わせの使用。
、RDBの永続性
RDB永続データ生成処理は、現在のスナップショットは、（.RDB）ハードディスク、および手動トリガ自動トリガを処理するために、ファイルを保存します。
Redisのは次の場合にデータのスナップショットになります。
A）自動スナップショットの構成ルール。
b）は、ユーザが保存またはbgsaveコマンドを実行します。
C）flushallコマンドを実行します。
D）コピーを実行する（レプリケーション）。
図1に示すように、構成ルールに従って自動スナップショット
ユーザーは条件のスナップショットをカスタマイズすることができます、条件は、スナップショットと一致しているとき、Redisのは、自動的にスナップショット操作を実行します。ああああタイトルキーのスナップショットは、2つのパラメータで構成される、ユーザー・プロファイルによってカスタマイズすることができる：時間窓MおよびN結合の変化の数 キーの数は、自動スナップショット条件で、すなわち、MがNよりも大きい時間内に変更されるたびに。
ディレクトリのサンプルのRedisのインストール設定ファイルは、プリセットの三つの条件が含まれています。
900 1を保存
300 10を保存
セーブ60 10000
各行ごとのスナップショットの状態、および複数の条件がありますが、パラメータを保存して開始し、条件の間「または」関係があります。上記の例では、複数のキーがあることを意味9001に保存が変更され又はスナップショットが15分（900秒）以内に行われる。同様に、300 10を保存すると、少なくとも10個のキーが300秒に変更されたサブああを示しスナップショット。
2、マニュアルトリガは2つのコマンドは保存していbgsave
自動スナップショットRedisのに加えて、サービスは、手動で移行を再開され、ときに我々は、手動でバックアップスナップショット操作を実行する必要があります。Redisのは、この操作を完了するために2つのコマンドを提供します。
コマンドを保存します。プロセスが完了するまで、現在のRedisを遮断する、RDBが持続し、総会に起因するメモリインスタンス比較的長い閉塞は、オンライン環境がそれを使用することは推奨されていない場合
bgsaveコマンド：子スレッドを作成するために実装フォーク操作のRedisの過程を、子スレッド完成持続性、時間を遮断することは、非常に短い（マイクロ秒）で、それは、保存最適化することで、RedisのはシャットRedisの-CLIシャットダウンサービスの実装では、開いていないAOFの永続性、自動実行bgsaveがあれば、
明らかに保存することbgsave最適化されています。
実行中のプロセスをbgsave
3、コマンド実行flushall
FlushallコマンドはRedisの自動スナップショットの条件限りかかわらず、条件は、自動スナップショットがトリガされたかどうかのデータベースを空にするプロセスが空でないことに注意することは、データベース内のすべてのデータが消去され、実行され、Redisのスナップショット操作を実行します。
スナップショットが1つの場合、第2の鍵変形10000自動スナップショットのための条件を定義したときのような導通、およびデータベースキーが実行された場合にのみときflushallコマンドは、プロセスが実際に1つのキーだけが変更された場合でも、スナップショットをトリガします。
何の自動スナップショットが条件に定義されていない場合には、高速でflushall実行されることはありません
写真を。
4、レプリケーション（複製）を行います
マスタースレーブモードが設定されている場合と、Redisのは、自動的に初期化のスナップショットをコピーします。
5、原則のスナップショット
スナップショットファイルは、Redisの現在のプロセスの作業ディレクトリに格納されdump.rdbデフォルトのファイルRedisのは、あなたがディレクトリを設定することで、スナップショットファイルの保存パスとファイル名を指定して、2つのパラメータをdbfilenameすることができます。次のようにスナップショットプロセスは、次のとおりです。
、現在のプロセス（親）のコピー（子）のフォーク機能のコピーを使用してのRedis。
B、親プロセスは、クライアントから送信されたコマンドを受信して処理を継続し、子供がデータメモリに始まった、ハード・ディスク上の一時ファイルを書き込みます。
すべてのデータが子プロセスに書かれているCは、スナップショットの操作が完了もたらし、一時ファイルのRDBで古いファイルを置き換えるために使用されます。
注意：
用書き込み（コピーオンライト）戦略、フォーク機能である瞬間、親と子が親を変更したい場合は、同じメモリのデータを共有するために起こるフォークの時にオペレーティングシステムをコピーした時間（例えば、書き込みコマンドなど）のデータの一部をオペレーティング・システムは、データは、子プロセスが影響を受けないことを保証するために、データシートをコピーするので、フォークモーメントときに、新しいメモリ・データRDBファイル保存します。
コピーライトストラテジもフォークの時点で、それはメモリの2つのコピーを生成ようだが、実際にはメモリの量を取ると倍増されないことを保証します。
ときにスナップショット・プロセスに、大きなフォークの前と後のデータの差異が生じ、より書き込み操作は、メモリが現在のデータベースのデータを保存するだけでなく、保存されていないという理由だけで、メモリ使用量は、データの実際のサイズよりもはるかに多くであることを確認するかどうかメモリデータフォーク時間。メモリ使用量の推定値は、メモリ使用量のオーバーランで、その結果、この問題を見落とすことは容易でした。
Redisのは、スナップショットの終わりは新しいに古いファイルを置き換えます後にのみ、RDBファイルを見つける変更されません上記のスナップショットを実行するプロセスは、それは我々が定期的なバックアップのRDBを作ることができ、いつでもRDBファイルが完了した手ですRedisのデータベースのバックアップファイルは実現しています。RDBファイルは、バイナリ形式（rdbccompressionパラメータはCPU使用率を節約するために圧縮を無効にするように構成することができる）に圧縮されるので、空間伝送をより助長メモリ内のデータのサイズよりもしばしば小さいです。
RDBのRedisの開始後、それはデータがハードディスクからメモリにロードされ、スナップショットファイルを読み込み、サイズと異なる構造およびサーバーのパフォーマンスの数は、この時間は、通常、文字列型キーレコード千万、スナップショット1ギガバイトのサイズ異なっていますメモリにロードされたファイルは、20〜30秒かかります。
持続性の方法によって達成RDB、一度Redisの異常終了は、自動スナップショット条件方法の組み合わせによって設定された許容範囲内に制御可能な損失にデータを必要と将来のすべてのデータ変更の最後のスナップショットを失うことになります。
操作RDBファイル
コマンド：コンフィグ設定ディレクトリは/ usr / local //設定RDBファイルのパス
バックアップ：bgsave //ローカル/次のUSRにdump.rdbを保存
回復：Redisのインストールディレクトリに、同じディレクトリredis.conf dump.rdb、あなたはRedisのを再起動することができます
長所：バックアップに適した1、圧縮されたバイナリファイル、災害復旧のための複製の全量
2、AOFの方法よりもはるかに高速のデータを回復するためにRDBをロード
短所：1は、リアルタイムの持続性を行うことができない、子プロセス、頻繁に操作するコストが高すぎるたびに作成
2は、バイナリファイルが保存され、古いバージョンがあり、新しいバージョンのRDBファイルの問題と互換性がありません
二、AOF持続性
RDBは、Redisのは、AOFの永続性を解決する方法を提供し、リアルタイムの持続性には適していません。
オープン：redis.conf設定：はい（デフォルトはnoのために開かれていない）appendonly
デフォルトのファイル名：appendfilename「appendonly.aof」
1、プロセス記述
- すべてはaof_bufするために追加のバッファを追加します（HSETを設定）コマンドを書きます
- AOFは、ハードディスクに同期した同期バッファを行います
- AOFファイルが上昇すると、定期的なAOFファイルの書き換え書き換えの必要性は圧縮を達成します
- Redisのサービスを再起動すると、あなたはロードAOFファイルの回復をロードすることができた場合
永続プロセスAOF：ファイルを上書きするコマンド書き込み（追記）、ファイルの同期（シンク）、（書き換え）、ロード（負荷）を再起動します
2、AOF詳細構成
appendonlyはい// AOF永続的な方法を有効にします
＃Appendfsyncは常に//各受信したライトコマンドは、ディスク、最も遅いへの即時書き込みを強制するのではなく、完全な持続性を確保するため、お勧めできません
//一度ディスクごとappendfsync everysecを書くことを強制、パフォーマンスと持続性は、妥協の勧告を行っています
＃Appendfsyncなし//完全に依存OS、最高のパフォーマンスは、持続性は、（オペレーティングシステム自体の同期）を保証するものではありませんでした
プロセスなしappendfsyncオン書き換えはい// RDBは、スナップショットをエクスポートされて、あなたは同期AOFを停止しません
最後の書き換えのサイズ、成長率、書き換えの100％と比較して、自動AOF書き換え-率100 // AOFファイルサイズ
自動AOF書き換え分サイズの64メガバイト//ファイルAOF、64Mよりも少なくともより、書き換え可能
AOFから回復する方法3、？
- はいappendonly設定します。
- dirのパラメータを置くappendonly.aofディレクトリを指定します。
- スタートRedisのは、Redisのは自動的にappendonly.aofファイルをロードします。
注意：
ハードディスクのデータの同期化：
操作が実行されるたびに、データベースの変更の内容が、コマンドはAOF AOFファイルに記録されますが、オペレーティングシステムのキャッシュメカニズムによる実際に、実際にデータがディスクに書き込まれていませんが、
オペレーティングシステムのディスクキャッシュに
。システムが異常終了につながることができれば、ハードディスクキャッシュの内容が実際にディスクに書き込まれるように、誰かの場合には、システムの同期30秒ごとに実行し、30秒のプロセスは、ディスクキャッシュのデータが失われます。この問題を解決するには、ハードドライブにコンテンツを同期するAOFファイルシステムキャッシュのイニシアチブを書き込んだ後のRedisが必要です。タイミング同期はappendfsyncパラメータでのRedisで設定することができます。
常に#appendfsync
appendfsync everysec
#appendfsyncなし
毎秒同期操作を実行し、デフォルトのルールを使用してEverysecは、
必ず各実行は同期書き込みを実行することになり示し、これは最も安全な方法は最も遅いです。何もなく、完全に行うには、オペレーティング・システム（すなわち、30秒ごと）、最速かつ最も安全なまでの、同期させるイニシアチブを意味しません。両方の性能を考慮して、安全性を確保するため、一般的に十分everysec。
第三に、順序と負荷AOFとRDBの流れRedisの再起動を復元するには：
1、AOFとRDBのファイルが存在し、優先負荷AOF
2、あなたがAOFを閉じると、RDBファイルをロード
3、負荷AOF / RDBの成功、Redisのが正常に再起動します
4、AOF / RDBエラー、Redisのは、エラーメッセージを出力し、起動に失敗します