Redisの永続化メカニズム
Redisのは、二つの永続化戦略を提供します
RDB
RDBの永続化戦略：ディスクへのデータ同期タイミングメモリの規則によると、
スナップショット
指定された状況下でのRedisのは、スナップショットをトリガーします
- 自分のスナップショット規則を設定
保存<秒> <変化>
デフォルトの設定のルール
900 1を保存し 、キー数が900秒以内に変更されたときに1よりも大きい場合、それはスナップショットがあります
300 10を保存
セーブ60 10000
- 保存手動またはbgsaveを実行します
保存：同期実行メモリのデータをディスク操作には、この操作は、クライアントの要求をブロックします
bgsave：非同期スナップショット操作を実行するには、バックグラウンドで、この操作は、クライアントの要求をブロックしません
- ときに実行flushall
スナップショットのルールは、最初のルールがあることを、空でない限り、メモリ内のすべてのデータを消去します。Redisのは、スナップショットを実行します
- 実行したコピー
原則スナップショット
1：現在のプロセス（子）のコピーのフォーク機能のコピーを使用してのRedis
2：親プロセスは、クライアントから送信されたコマンドを受信して処理を継続し、子供がデータメモリに始まった、ハード・ディスク上の一時ファイルを書き込みます
3：子プロセスは、RDBに書き込まれたすべてのデータは、これまでのところ、スナップショット操作が完了し、一時ファイルと古いファイルを置き換えます。
注意：RDBは、スナップショットの終わりは新しいに古いファイルを置き換えます後にのみ、スナップショットプロセスRedisの中にファイルを変更しません、それはRDBファイルが完了している任意の時点で言うことです。これは、私たちはスケジュールされたバックアップRDBを介してファイルのデータベースのバックアップをRedisのを可能にする、RDBのファイルは圧縮されたバイナリファイルで、スペースは、送信により助長、メモリ内のデータよりもしばしば小さいです。
RDBの長所と短所
- Redisの異常終了後は、あなたが将来的にすべてのデータ変更の最後のスナップショットを失うことになる、永続性を達成するためにRDBの方法を使用します。我々は、データの損失が制御範囲で起こり得るように条件の組み合わせによって提供される自動スナップショットを受け入れることができる、特定のアプリケーションシナリオに応じて、この時間を必要とします。データが比較的重要である場合は、損失を最小限にしたい、あなたは、永続性のためのAOFの方法を使用することができます
- RDB Redisのは、パフォーマンスを最大化することができます行うには、親プロセスは、ファイルRDBの子プロセスを保存するときに、子プロセスは、その後、後続のすべての保全作業、親プロセスのための実行任意のディスクI / Oを処理するアウトフォークです操作。データセットが大きい場合、フォークは時間のかかるサーバをもたらすことができるならば、これは欠点があるが、処理クライアントは時間の期間を要求する停止します。
練習
修正redis.conf appendonlyはい、ファイル.aof対応binディレクトリに生成されたデータの再起動後に実行変更指示は、すべてのAOFファイル操作コマンドを記録します
次の2つのパラメータは、AOFファイルを最適化するために行うことができます
自動AOF書き換え-率100は、ときに、現在のAOFファイルのサイズに書き換えされますどのように多くのAOFファイルのサイズの割合に複数回を表します。AOFファイルサイズが勝つ開始するときは、以前に書き換えられていない場合
上書きファイルサイズを可能にするための最小限AOF自動AOF書き換え分サイズの64メガバイト、ファイルサイズが64メガバイト時間未満である、あなたは、最適化する必要はありません。
AOF
Redisのは、このプロセスは、明らかにRedisののパフォーマンスが低下します、ディスクファイルに追加することができますが、ほとんどの場合、この影響は許容され、より高速なハードドライブに加えて、AOFのパフォーマンスを向上させることができ、それぞれのライトコマンド実行AOF
練習
Redisのは、デフォルトの永続性AOF（ファイルのみを追加）モードはイエスappendonlyにredis.confで見つかった、appendonlyパラメータで有効にすることが可能でオンになっていません
永続AOF各ターンの後に実行されるデータRedisのコマンドで変更した後、Redisのコマンドは、あなたのハードディスク上のAOFファイルを書き込みます。同じ場所RDBの場所とファイルの保存AOFファイルは、dir引数によって設定され、デフォルトのファイル名はapendonly.aofです。Appendfilenameのappendonlyh.aofはredis.confのプロパティを変更することができます
書き換え原則AOF
RedisのAOFは自動的にAOFの書き換え背景に、あまりにも大きなファイルサイズになるかもしれとき：新しいファイルAOFコマンドを上書きした後、現在のコレクションを復元するために必要なデータの最小限のセットが含まれています。新しいRedisのAOFファイルを作成するプロセスでは、コマンドにもダウンタイム中にAOFファイルが失われることはありません、既存の書き換え、内部の既存のファイルAOFに追加していきますので、全体の操作は、絶対に安全であるリライト。新しいAOFファイルが作成されると、Redisのは、新しいファイルAOFのAOFファイルに古いから切り替えて新しいAOFファイルの追加操作を開始します。AOFファイルの内容は、（解析）解析のためにファイルに、人々を読むことは非常に簡単ですので、AOFも非常に簡単で、すべてのデータベース、形式Redisのプロトコルを保存するには、書き込み動作を実行する動作を記述整然とファイルを保存します
同期ディスクデータ
あなたは時間のデータを変更するたびにのRedis、AOFのメカニズムは、AOFファイルを記録するためのコマンドを話すことができるが、実際にはキャッシュメカニズムのオペレーティングシステムは、リアルタイムのデータをハードディスクに書き込まれませんが、ハードディスクのキャッシュに。ファイル・キャッシング・メカニズムに保存されてハードディスクを通過してその後フラッシュ
＃Appendfsyncは、常にすべての実行が同期されます書くが、これは最も安全な方法は、比較的低い効率であります
appendfsync everysec秒ごとに実行
＃Appendfsyncが何も操作を同期するためのイニシアチブを取ることはありません、オペレーティングシステムによって行われていないことが、これは最速のが、最も安全な方法です
AOF後に破損したファイルを修復する方法
プログラムは書き込みのためAOFファイルされているときのダウンタイムが（壊れた）AOFファイルエラーの原因となった場合、サーバーは、シャットダウンすることがあり、その後、データの一貫性を確保し、このファイルをロードすることを拒否しますAOFで破壊されることはありませんがRedisのを再起動します。
これが起こるとき、あなたはAOF文書のミスを修復するには、次の方法を使用することができます。
- 既存のAOFファイルのバックアップを作成します。
- 元修理に供給されるのRedis-チェックAOFプログラム、AOFファイルを使用してのRedis。
Redisのチェック、AOF --fix
Redisのサーバーの再起動、AOFファイルサーバの負荷の修復とデータ復旧を待ちます。
RDBとAOF、どのように選択します
データセキュリティ要件が非常に高い場合には一般的に、あなたは両方の永続的な機能を使用する必要があります。あなたは数分以内にデータの損失に余裕があれば、あなただけのRDBの永続性を使用することができます。AOF多くのユーザーは、永続使用していますが、この方法をお勧めしません：RDBスナップショット（スナップショット）を生成するタイミングはAOFも早い回復であるよりも、データベースのバックアップと回復速度RDBのデータセットは非常に簡単であることから。
持続性戦略の二種類を同時に使用することができ、あなたがそれらのいずれかを使用することができます。あなたがそれを使用する場合は、Redisのを再起動すると、それがデータを復元するAOFファイルの使用を優先させて頂きます
クラスタ
コピー（マスター、スレーブ）
コンフィギュレーション・プロセス
redis.confファイルの11.140と11.141を変更し、増加slaveof MASTERIP masterport
この増加は、192.168.11.138 6379は、サーバからスレーブにサーバをRedisのでしょうslaveofすることができます
クライアント・レプリケーションビューサーバのステータスに情報を入力します。
原則
- マスタへ再接続した後、マスターSYNCにコマンドを送信するか、第1のスレーブ
- SYNCは、マスタータイムを受け、それは2つのことを行います
a）は、実行bgsave（RDBスナップショットファイル）
b）のマスターは、バッファに格納されているコマンドに新しい変更を受信します
欠点は、
動的な選挙をマスターする方法はありません
道をコピーします
- RDBファイルベースのレプリケーション（最初の接続または再接続時間）
- いいえハードコピーありません
- インクリメンタルレプリケーション
PSYNCマスターはIDを実行します。オフセット
センチネルメカニズム
センチネル
- 監視マスターとスレーブが正常に動作しています
- マスターに障害が発生した場合、の一つは、マスターデータ軟膏にアップグレードされます
クラスタ（redis3.0機能後）
キーのハッシュ値は、サーバーの数を法。
ハッシュ
クラスタの原理
Redisのクラスタでは、シャーディングスロット（溝）を使用する概念は、16,384スロット、プレシャーディングの前で話すの幾分同様のアイデアの合計に分割されます。各キーが入力するためのRedisのは一つのスロットに16,384に割り当てられたハッシュキー、に従って行わ。使用されるハッシュアルゴリズムは、また、比較的単純である剰余CRC16 16384です。Redisのクラスタ（ノード）内の各ノードは、各スロットは、ノードのハンドルに対応し、すなわち、この16384スロットの一部を共有する責任があります。動的ノードのノードを追加または差し引く場合、溝は16,384に再配布する必要がある、キー溝も移動します。もちろん、このプロセスは、現在の実装では、状態が半自動、手動の介入が必要とされる中です。Redisのクラスタは、ノードに障害が発生した場合、それはスロットの失敗を担当する、ノードに対応する16,384スロットが正常に動作していることを確認するために、クラスタ全体が機能しません。クラスタの接近性を高めるために、それが正式に第nスレーブノードからぶら下がっマスタノード配置構造、すなわち、一次マスターノードからプログラムをお勧めします。プライマリノードに障害が発生した場合、この時点では、Redisのクラスタは、クラスタ全体がサービスを提供し続けるために、ノードベースの上昇でスレーブノードから選出アルゴリズムに従って選択されます。これは、マスタースレーブ構造にセンチネル監視インフラストラクチャによってサーバノードに非常に類似しているが、Redisのクラスタ自体は、フォールトトレランスのためにフェイルオーバーする能力を提供します。
概念スロット（スロット）、およびRedisのクラスタ内の16,384スロットの合計が、
キー、その後、モジュロ16384の結果に応じてCRC16アルゴリズム。3つのノードがある場合
ノード1 0 5460
ノード2 5461 10922
ノード3 10923 16383
新しいノード
ノード4 0-1364,5461-6826,10923-12287
ノードを削除します。
あなたが削除することができます前に、他のノードにデータノードを移動するファースト
市場で入手可能なクラスタソリューション
- Redisのshardding操作SharddingJedisをsharddingサポートするjedisクライアント;増加し、問題のノードを減らし、事前shardding
3つの仮想マシンのRedis。しかし、私は9つのノードを展開しました。3つのRedisのそれぞれの展開は、CPUの利用率を高めます
図9は、別の仮想マシンサーバ9に分割しました
- CODISベースredis2.8.13ブランチはCODISサーバを開発しました
- ツイッターが提供するオープンソースソリューションをtwemproxy