Redis の永続性

RDBスナップショット（スナップショット）

デフォルトでは、Redis はメモリ内データベースのスナップショットを dump.rdb という名前のバイナリファイルに保存します。
「N 秒以内にデータセットに少なくとも M 個の変更がある」という条件が満たされた場合に、データセットを自動的に保存するように Redis を設定できます。
たとえば、次の設定では、「60 秒以内に少なくとも 1000 個のキーが変更された」という条件を満たした場合に、Redis がデータセットを自動的に保存します。

# save 60 1000 //RDB を閉じるには、すべての保存戦略をコメントアウトします。

コマンドを手動で実行して RDB スナップショットを生成することもできます。Redis クライアントを入力し、コマンド save または bgsave を実行して、dump.rdb ファイルを生成します。各コマンドを実行すると、すべての Redis メモリが新しい rdb ファイルにスナップショットされ、元の rdb スナップショットファイルが上書きされます. .

bgsave のコピーオンライト (COW) メカニズム
Redis は、オペレーティングシステムによって提供されるコピーオンライトテクノロジ (COW) を使用して、書き込みコマンドを通常どおり処理しながらスナップショットを生成します。簡単に言えば、bgsave サブプロセスはメインスレッドの fork によって生成され、メインスレッドのすべてのメモリデータを共有できます。bgsave サブプロセスが実行されると、メインスレッドのメモリデータの読み取りが開始され、RDB ファイルに書き込まれます。このとき、メインスレッドがこれらのデータの読み取り操作も実行する場合、メインスレッドと bgsave サブプロセスは相互に影響を及ぼしません。ただし、メインスレッドがデータの一部を変更したい場合は、データの一部がコピーされてデータのコピーが生成されます。次に、bgsave サブプロセスはこのコピーデータを RDB ファイルに書き込みます。このプロセス中も、メインスレッドは元のデータを直接変更できます。
save と bgsave の比較:

注文	保存	bgs保存
IOタイプ	同期する	非同期
他の Redis コマンドをブロックするかどうか	はい	いいえ (fork 関数を実行するために子プロセスが生成されるときに、短いブロックが発生します)
複雑さ	の上）	の上）
アドバンテージ	追加のメモリを消費しません	クライアントコマンドをブロックしません
欠点がある	クライアントコマンドをブロックする	子プロセスをフォークしてメモリを消費する必要がある

rdb ファイルの自動生成を構成するバックグラウンドでは、bgsave メソッドが使用されます。

AOF（追記専用ファイル）

スナップショット機能は耐久性があまり高くありません。何らかの理由で Redis に障害が発生すると、サーバーは最近書き込まれ、まだスナップショットに保存されていないデータを失います。
バージョン 1.1 以降、Redis は完全に永続的な永続化メソッドである AOF 永続化を追加し、変更された各命令をファイル appendonly.aof に記録します (最初に OS キャッシュに書き込まれ、定期的にディスクに fsync が書き込まれます)
。コマンド「set tacy 666」を実行すると、次のデータが aof ファイルに記録されます

*3
$3
set
$5
tacy
$3
666

これは各プロトコル形式のデータです。

アスタリスクの後の数字は、コマンドに含まれるパラメーターの数を表します。
$ 記号の後の数字は、このパラメーターの文字数を表します。

有効期限を指定して set コマンドを実行する場合、aof ファイルに記録されるのは、実行された元のコマンドではなく、キーの有効期限のタイムスタンプであることに注意してください。たとえば、「 set lucy 888 ex 1000 」が実行され
た場合、 aofファイル内の対応するレコードは次のとおりです

*3
$3
set
$6
lucy
$3
888
*3
$9
PEXPIREAT
$6
lucy
$13
1604249786301

設定ファイルを変更することでAOF機能をオンにできます。

# appendonly yes

今後、Redis がデータセットを変更するコマンド (SET など) を実行するたびに、そのコマンドは AOF ファイルの末尾に追加されます。
この場合、Redis が再起動されると、プログラムは AOF ファイル内のコマンドを再実行することでデータセットを再構築できます。

Redis がデータをディスクに fsync する頻度を構成できます。
次の 3 つのオプションがあります。

appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。
appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

推奨される (デフォルトの) 対策は、1 秒に 1 回 fsync することです。この fsync 戦略により、速度とセキュリティのバランスをとることができます。
AOF 書き換え
AOF ファイル内に無駄な命令が多すぎる可能性があるため、AOF はメモリ内の最新データに基づいて定期的に aof ファイルを生成します。たとえば、
次のコマンドが実行されます。
ここに画像の説明を挿入します

書き換え後のAOFファイルは、

*3
$3
SET
$2
readcount
$1
5

次の 2 つの構成により、AOF 自動書き換え頻度を制御できます。

# auto-aof-rewrite-min-size 64mb   //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
# auto-aof-rewrite-percentage 100  //aof文件自上一次重写后文件大小增长了100%则再次触发重写

もちろん、AOF は手動で書き換えることもできます。redis クライアントに入り、コマンド bgrewriteaof を実行して AOF を書き換えます。AOF による
redis の書き換えは (bgsave コマンドと同様に) 子プロセスをフォークして実行するため、大きな影響はありません。 Redis の通常のコマンド処理上。
ここに画像の説明を挿入します

Redis の起動時に rdb ファイルと aof ファイルの両方が存在する場合、一般的に aof にはより完全なデータが含まれるため、データの復元には aof ファイルが優先されます。

Redis 4.0 ハイブリッド永続性

Redis を再起動する場合、大量のデータが失われるため、RDB を使用してメモリ状態を復元することはほとんどありません。通常はAOFログリプレイを使用しますが、AOFログリプレイはRDBに比べてパフォーマンスが非常に遅いため、Redisインスタンスが大きい場合には起動に時間がかかります。この問題を解決するために、Redis 4.0 には新しい永続性オプションであるハイブリッド永続性が導入されました。
ハイブリッド永続性は、次の構成によって有効にできます (最初に aof を有効にする必要があります)。

# aof-use-rdb-preamble yes

ハイブリッド永続化をオンにすると、AOF 書き換え時に、単にメモリデータを RESP コマンドに変換して AOF ファイルに書き込むのではなく、書き換える直前のメモリが RDB スナップショットとして処理され、RDBスナップショットコンテンツと、メモリデータを変更するためのインクリメンタル AOF コマンドは一緒に存在し、新しい AOF ファイルに書き込まれます。新しいファイルは、最初は appendonly.aof という名前にはなりません。新しい AOF ファイルが書き換えられるまで名前は変更されず、ファイルが上書きされます。元の AOF ファイル。古い AOF ファイルと新しい AOF ファイルの置き換えが完了します。
したがって、Redis を再起動すると、最初に RDB の内容をロードしてから、増分 AOF ログを再生して、以前の AOF フルファイル再生を完全に置き換えることができるため、再起動の効率が大幅に向上します。

ハイブリッド永続 AOF ファイル構造は次のとおりです。
ここに画像の説明を挿入します

Redis データのバックアップ戦略:

crontab のスケジュールされたスケジュールスクリプトを作成して、RDB または AOF のバックアップを 1 時間ごとにディレクトリにコピーし、過去 48 時間のバックアップのみを保持します。
毎日、当日のデータのバックアップをディレクトリに保存します。先月のバックアップも保存できます。
バックアップをコピーするたびに、古すぎるバックアップを削除します。
マシンの損傷を防ぐために、現在のマシンのバックアップを毎晩他のマシンにコピーします。

Redis のマスター/スレーブアーキテクチャ

ここに画像の説明を挿入します

Redis マスター/スレーブアーキテクチャを構築し、スレーブノードを構成します。

1. redis.conf ファイルのコピーをコピーします。

2. 関連する構成を次の値に変更します。

port 6380
pidfile /var/run/redis_6380.pid  # 把pid进程号写入pidfile配置的文件
logfile "6380.log"
dir /usr/local/redis-5.0.3/data/6380  # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

3. マスター/スレーブレプリケーションを構成する

replicaof 192.168.0.60 6379   # 从本机6379的redis实例复制数据，Redis 5.0之前使用slaveof
replica-read-only yes  # 配置从节点只读

4. スレーブノードの起動

redis-server redis.conf   # redis.conf文件务必用你复制并修改了之后的redis.conf文件

5. スレーブノードを接続します

redis-cli -p 6380

6. 6379 インスタンスでデータの書き込みをテストし、6380 インスタンスが新しく変更されたデータを適時に同期できるかどうかを確認します。

7. 6381 スレーブノードを自分で設定できます

Redis のマスター/スレーブの動作原理

マスターに対してスレーブを構成すると、スレーブが初めてマスターに接続するかどうかに関係なく、PSYNC コマンドをマスターに送信してデータのコピーを要求します。
PSYNC コマンドを受信した後、マスターはバックグラウンドでデータの永続化を実行し、bgsave を通じて最新の RDB スナップショットファイルを生成します。永続化期間中、マスターはクライアントリクエストを受信し続け、データを変更する可能性のあるこれらのリクエストをキャッシュします。メモリに設定されます。永続化が完了すると、マスターはRDBファイルのデータセットをスレーブに送信し、スレーブは受信したデータを永続化してRDBを生成し、メモリにロードします。次に、マスターはメモリに以前にキャッシュされたコマンドをスレーブに送信します。
マスターとスレーブ間の接続が何らかの理由で切断された場合、スレーブは自動的にマスターに再接続できます。マスターが複数のスレーブの同時接続要求を受信した場合、接続ごとに 1 回ではなく 1 回だけ持続され、その後送信されます。この永続データを、同時に接続されている複数のスレーブに送信します。

ここに画像の説明を挿入します

データの部分コピー

マスターとスレーブが切断され、再接続されると、通常、データ全体がコピーされます。ただし、redis バージョン 2.8 以降、redis は部分的なデータレプリケーションをサポートできるコマンド PSYNC を使用して、マスターとデータを同期します。スレーブとマスターは、ネットワーク接続が切断されて再接続された後にのみ、部分的なデータレプリケーション (送信の再開) を実行できます。
マスターは、メモリ内のデータをコピーするためのキャッシュキューを作成し、最新期間のデータをキャッシュします。マスターとそのすべてのスレーブは、コピーされたデータの添字オフセットとマスターのプロセス ID を維持します。そのため、ネットワーク接続が切断されると、その後、スレーブはマスターに対して、記録されたデータインデックスから開始して未完了のレプリケーションを続行するように要求します。マスタープロセス ID が変更された場合、またはスレーブノードのデータオフセットが古すぎてマスターのキャッシュキューに存在しない場合、完全なデータコピーが実行されます。