redisのインストールと基本的な使用については、本人のブログを参照してください.
redisインストールと基礎入門
Redisデータベースの学習と実践-Redisの一般的なコマンドと高度な応用

1 redis持続化(persistence)

1.1 Redisは、さまざまなレベルの持続性を提供

RDB永続化は、指定された時間間隔でデータセットのポイント・イン・タイム・スナップショットを生成することができる.

AOFは、サーバが実行するすべての書き込みコマンドを永続化し、サーバの起動時にこれらのコマンドを再実行することによってデータセットを復元する.AOFファイルのコマンドはすべてRedisプロトコル形式で保存され、新しいコマンドはファイルの末尾に追加されます.Redisはまた、AOFファイルをバックグラウンドで書き換えることができ、AOFファイルのボリュームがデータセット状態を保存するのに必要な実際のサイズを超えないようにすることができる.

Redisはまた、AOF永続化とRDB永続化を同時に使用することもできる.この場合、Redisが再起動されると、AOFファイルが保存するデータセットは通常RDBファイルが保存するデータセットよりも完全であるため、AOFファイルを優先的に使用してデータセットを復元します.
永続化機能をオフにして、サーバの実行時にのみデータが存在するようにすることもできます.

1.2 RDBモード

1.2.1配置方式

RDBレプリケーションモードはスナップショットモードとも呼ばれ、指定された時間間隔でデータスナップショットが保存される.

save  

seconds時間間隔でchanges回数の変化が発生すると、スナップショット保存がトリガーされます.複数のルールを構成できます.
Redisのプロファイルでスナップショットを構成するルールに加えて、手動で直接スナップショットをトリガーすることもできます.SAVEまたはBGSAVEコマンドを直接呼び出します.

1.2.2動作原理

Redisがdumpを保存する必要がある場合.rdbファイルの場合、サーバは次の操作を行います.

Redisはfork()を呼び出し、親プロセスと子プロセスを同時に持つ.

サブプロセスは、データセットを一時RDBファイルに書き込む.

サブプロセスが新しいRDBファイルの書き込みを完了すると、Redisは新しいRDBファイルで元のRDBファイルを置き換え、古いRDBファイルを削除する.

この動作により、Redisは書き込み時コピー(copy-on-write)メカニズムから利益を得ることができる.

1.2.3メリットとデメリット

メリット:

RDBは、ある時点におけるRedisのデータセットを保存する非常にコンパクトなファイルである.このファイルはバックアップに適しています.たとえば、最近の24時間以内にRDBファイルを1時間に1回バックアップし、毎月の毎日に1つのRDBファイルをバックアップすることができます.これにより、問題が発生しても、いつでもデータセットを異なるバージョンに復元することができます.

RDBは、ディザスタリカバリ(disaster recovery)に非常に適しています.ファイルが1つしかなく、コンテンツが非常にコンパクトで、(暗号化後に)他のデータセンターに転送できます.

RDBはRedisの性能を最大化することができる:親プロセスはRDBファイルを保存する時に唯一しなければならないのはforkがサブプロセスを出して、それからこのサブプロセスは次のすべての保存作業を処理して、親プロセスはいかなるディスクI/O操作を実行する必要はありません.

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

欠点:

rdbモードは、指定された時間に何度か変化するデータを永続化し、データが永続化されていない場合にダウンタイムし、現在の期間内のデータが失われる可能性がある

.

rdb回forkサブプロセスが行われるたびに、データ量が大きい場合forkは時間がかかり、CPUが緊張している場合にカートンが発生しやすい.

1.3 AOF（AppendOnly File）モード

サーバが突然電源を切ったり、ハングアップしたり、kill -9を呼び出してredisを殺すように命令したりした場合、rdbを使用する方法は永続化されず、このときの最新の操作は永続化されていません.従ってredisは、append−only fileという別の永続化方式を提供する.

1.3.1 AOF配置方式

AOFを起動するには、プロファイルに設定する必要があります.

appendonly yes

構成時、redisはAOFファイルに命令を1つも生成せずに追加され、サーバが再起動すると、redisはこのファイルから命令を再実行してメモリにデータを返信します.

aof書き換え

以上より,実行命令が保存されるたびにaofファイルが大きくなることが容易に分かった.例えば、incrementは100回で100個の命令がありますが、実際にはデータを返信するときにsetの命令を呼び出して最後のデータに返信すればいいのです.だからredisにも書き換えメカニズムが内蔵されています.クライアントに対するサーバを中断せずにバックグラウンドでaofファイルを書き換える.reids 2.2の前に.BGREWRIETAOF命令を呼び出す必要があります.redis 2.4以降は、この命令が自動的にトリガーされます.

同期周波数構成（how durable）

どのくらいの頻度でデータを同期(fsync)してファイルに1回のポリシーに3つあります.

fsync always新しい命令のたびに、各命令はaofに加算されます.この方法は非常に遅いですが、非常に安全です.

fsync everysecは1秒ごとに同期します.この方法は速度が速く,最悪の場合1 s以内のデータ

を損失する.

never noは同期せず、オペレーティングシステムに渡して処理します.とても速いですが、安全ではありません.

redisのデフォルトと推奨方法は、毎秒同期方式です.
構成:

# appendfsync always
appendfsync everysec
# appendfsync no

AOFファイル破損の処理方法

AOFファイルが破損した場合、redisはAOFからデータを復元できなくなり、次の手順で処理できます.

現在のAOFファイル

をバックアップ

redis-check-aofツールを使用して元のAOFファイルを修復し、コマンドredis-check-aof --fix

を実行します.

選択的diff -uを使用して、2つのファイルの異なる

を検出する.

修正されたファイルでサービス

を再起動する.

1.3.2 AOF動作原理（rewrite）

redis forksサブプロセス

サブプロセスは、AOFを一時ファイル

に書き込むことを開始する.

親プロセスは、すべての新しい変更を計算し、メモリバッファに配置します(古いAOFファイルにも書き込みますので、書き換えに失敗し、安全です).

最後.redisは古いファイルを自動的に新しいファイルに置き換えます.新しいファイルへのデータの追加を開始する

1.3.3 AOFメリットとデメリット

AOFの利点:

データのセキュリティは、同期メカニズムから見てより高い.Always方式は満タンですが、各命令は格納されています.

aofは追加ファイルで、問題が発生した場合はredis-check-aofツールを使用して

を修復できます.

ファイルが大きすぎる場合は書き換え方式を使用します.ファイルが存在する限り、データは

に復元できます.

ファイルの内容はredisのプロトコルで格納され、解読が容易である.偶発的にエクスポートと解析を容易にすることができます.

AOF欠点:

データ量が大きすぎる場合、redisのaof体積はrdbファイルより

大きくなります.

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

を提供することができる.

1.4データ災害対応

データデータ(rdbファイル)のバックアップを頻繁に行う必要がある

corn job方式を用いて、rdbファイルをフォルダ

にバックアップする

バックアップ時間にタイムラベルを付け、findを使用して早期のバックアップを見つけて

を削除します.

定期的にバックアップを現在の物理マシン以外のマシンに1部バックアップします.