Redis の永続化の原則を調べる-Redis-php.cn

Redis の永続化の原則を調べる

angryTom

リリース： 2020-02-22 16:25:16

転載

2514 人が閲覧しました

Redis の永続化の原則を調べる

Redis の永続化原理の詳細な調査

Redis はインメモリデータベースです。データの永続性を確保するために、Redis は RDB と AOF の 2 つの永続化メソッドを提供します。

Redis はインメモリデータベースです。データの永続性を確保するために、 redis は、RDB と AOF という 2 つの永続化メソッドを提供します。AOF、これら 2 つの永続化メソッドの実装原理を個別に見てみましょう。

RDB (デフォルト)

RDB はスナップショットを通じて完成され、特定の条件が満たされると、redis はメモリ内のデータを自動的にディスクに永続化します。

スナップショットをトリガーするタイミング

カスタム構成されたスナップショットルールに準拠します。 (redis.conf で構成されます。詳細は後述します)
save または bgsave コマンドを実行します。
flushall コマンドを実行します。
マスター/スレーブレプリケーション操作を実行します (最初は

(無料の学習ビデオチュートリアルの推奨事項: mysql ビデオチュートリアル )

回路図

Redis の永続化の原則を調べる

#スナップショットプロセス、つまりファイルの生成プロセス中、元の rdb ファイルはスナップショットが生成されるまで変更されず、古いファイルは新しいファイルに直接置き換えられます。 rdb ファイルすべての瞬間が完了します。
RDB ファイルを定期的にバックアップすることで、Redis データをバックアップできます。RDB は、占有容量が小さく、送信に適した圧縮バイナリファイルです。

スナップショット設定ルール save {何秒} {データの変更量}

例: save 100 1: 100 秒以内に、少なくとも 1 つのキーが変更されている場合はスナップショットを作成します。save 200 4: 200 秒以内秒、少なくとも 4 キーが変更されたときにスナップショットを作成します。

デメリット: RDB を永続化に使用すると、redis が突然異常終了すると、最後のスナップショット以降のデータが失われます。ただし、組み合わせに基づいて自動スナップショットを設定して、データ損失を軽減し、データ損失が許容範囲内に収まるようにすることができます。データがより重要な場合は、AOF メソッドを使用できます。

利点: RDB メソッドを使用すると、Redis のパフォーマンスを最大化できます。スナップショットプロセス中に、メインプロセスは子プロセスをフォークアウトするだけでよいことがわかります。すべての作業は子プロセスによって完了され、親プロセスはディスク I/O 操作を実行する必要はありません。ただし、データセットが大きい場合は、子プロセスをフォークするのに時間がかかり、redis が一定期間リクエストの処理を停止することになります。

AOF メソッド

デフォルトでは、redis は AOF (ファイルのみの追加) を有効にしません。 AOF の開始後、redis データを変更するコマンドを redis が受信するたびに、コマンドがハードディスク上の AOF ファイルに書き込まれます。明らかに、このプロセスにより Redis のパフォーマンスが低下しますが、ほとんどの場合は許容できます。同時に、よりパフォーマンスの高いハードディスクを使用すると、AOF のパフォーマンスを向上させることができます

AOF 構成方法

# 开启appendonly参数appendonly true# 设置AOF文件位置dir ./# 设置AOF文件名称，默认是appendonly.aofappendfilename appendonly.aof<br/>

ログイン後にコピー

原理図 Redis の永続化の原則を調べる

RESP プロトコル

スペース記号: Linux では \r\n、Windows では \n
単純な文字列は ' で始まります
エラー、'-' で始まり
整数型 ':' で始まる整数型です。
'$' で始まる大きな文字列です。

配列型 '*' で始まる配列です。

AOF 原理の説明

コマンドの伝播
キャッシュの追加

ファイルの書き込みと保存

#コマンド伝播

redisは、実行されたコマンド、コマンドパラメータ、コマンドパラメータグリッド番号などの内容をAOFプログラムに送信します。 Redis クライアントがコマンドを実行すると、接続を通じてプロトコルテキストが Redis に送信されます。Redis がプロトコルテキストを受信した後、内容に基づいて適切なコマンド関数を選択し、プロトコルテキストを Redis 文字列オブジェクトに変換します。関数が実行された後、コマンドパラメータをAOFプログラムに送信します。 ###

缓存追加

AOF程序接收到命令参数之后，会将其从字符串对象转换成协议内容，再将协议内容追加到AOF缓存中。AOF缓存是在redisServer结构的aof_buf中，新的内容会被追加到aof_buf末尾。aof_buf保持着所有未被写入到AOF文件的协议文本。

文件写入和保存

将AOF缓存内容写入到AOF文件，并保持到磁盘。当服务器的常规函数被执行，或者事件处理器被执行的时候，flushAppendOnlyFile函数将会被执行。会有以下两个过程。

WRITE:将AOF缓存中的内容写入到AOF文件
SAVE:调用fsync或者fdatasync函数，将AOF文件保存到磁盘中

AOF一共有三种保存模式

AOF_FSYNC_NO:不保存。在这种模式下，每次调用flushAppendOnlyFile函数，write会被执行，而save会被忽略。而save只有在以下三种条件下会触发，redis关闭，aof功能关闭，系统的写缓存被刷新(可能是缓存满了，或者定期执行保持操作)。这三种情况下执行save操作会引起redis主线程的阻塞。
AOF_FSYNC_EVERYSEC(默认):每秒保存一次。save每秒被执行一次，但是save由后台子线程完成，不会导致redis主线程阻塞。
AOF_FSYNC_ALWAYS:每执行一个命令保存一次。这种情况下，每执行一个命令write和save都会被执行，而且save操作由主线程完成，会导致redis的阻塞。安全性较高，性能较差，因此不推荐使用。

AOF的文件优化

Redis可以在AOF文件过大的时候，在后台(子进程)对AOF文件进行重写。重写之后的新文件，包含恢复当前数据集所需的最小命令集合。重写，并不会对AOF文件进行读取和写入，针对的是数据库中的当前键。

优化前set s1 1set s1 2set s1 3优化后set s1 3<br/>

ログイン後にコピー

AOF文件优化原理

AOF的重写是通过子进程实现的，因此，主线程是继续工作的，有可能对新的数据进行修改，有可能会导致数据库的数据和重写之后的数据不一致。redis通过增加一个AOF重写缓存来解决这个问题，当fork出子进程之后，新的命令不仅会追加到现有的AOF文件中，还会添加一份数据到这个缓存当中。

Redis の永続化の原則を調べる

重写过程分析(需要保证从写的操作是绝对安全的)

Redis创建新的AOF文件之后，会继续将命令添加到原有的AOF文件中，即使数据库突然宕机了，原有的AOF文件和文件内容也不会有损失。而当新的AOF文件创建完毕之后，会直接把旧的替换掉，往新的AOF文件中添加命令。

当子进程在进行重写时，主进程会完成下列工作

处理请求，将新的命令继续添加到AOF文件中，同时将命令添加到AOF重写缓存中。保证数据的一致行，避免出现数据丢失。
当子进程重写完毕之后会向主进程发送一个完成信号，这时主进程会把重写缓存中的内容添加到新的AOF文件中，这样新的AOF文件，数据库，旧的AOF文件的内容就完全一致了。然后对新的AOF文件改名，覆盖原有的AOF文件。

这样程序就完成了新旧AOF文件的替换工作。而当处理完成之后，主进程就会继续接受请求。整个重写过程中只有最后的缓存写入和改名替换的操作会导致主进程阻塞，其他时候不会影响redis的正常工作，把AOF重写对redis的性能影响降到最低。

优化触发条件

#当前的AOF文件超过上次重写时AOF文件大小百分几的时候进行重写，如果没有重写过，则以启动时AOF文件的大小为准auto-aof-rewrite-percentage 100#限制允许重写的最小的AOF文件，也就是文件小于这个值的时候不需要进行重写优化auto-aof-rewrite-min-size 64mb<br/>

ログイン後にコピー