Redis 永続性を実装する方法

Redis は、高度なキーと値のデータベースです。 memcached に似ていますが、データを永続化でき、幅広いデータ型をサポートします。文字列、リンク リスト、セット、ソート セットがあります。サーバー側でのセットの和集合、共通集合、補数（差分）の計算をサポートし、さまざまなソート機能もサポートします。

Redis は、RDB と AOF という 2 つの永続化メカニズムをサポートしています。永続化により、プロセスの異常終了やダウンタイムによるデータ損失を回避でき、次回の再起動前に使用できます。永続化ファイルは有効です。データ復旧。

RDB 永続性

RDB 永続性は、圧縮されたバイナリ ファイルのスナップショットを作成することによって、特定の時点での完全なデータを保存する永続化方法です。 RDB 永続化は、Redis のデフォルトの永続化方法です。 RDB 永続化のトリガーには、手動トリガーと自動トリガーが含まれます。

手動で

save をトリガーします。コマンド ラインで保存コマンドを実行します。スナップショットを保存するために rdb ファイルが同期的に作成されます。これにより、サーバーのメイン プロセスがブロックされます。使用しないでください。本番環境の bgsave コマンド内 bgsave コマンドを実行すると、子プロセスをフォークして rdb ファイルが非同期に作成され、スナップショットが保存されます。フォーク中のブロックを除き、子プロセスが rdb ファイルを作成すると、メイン プロセスは続行できますリクエストを処理するには

自動トリガー

redis.conf で save m n が定期的にトリガーされるように設定します。たとえば、save 900 1 は、900 秒以内に少なくとも 1 つの更新がある場合、master-スレーブ レプリケーションがトリガーされます。スレーブ ノードがフル レプリケーション操作を実行すると、マスター ノードは自動的に bgsave を実行して RDB. ファイルを生成し、スレーブ ノードに送信してデバッグ リロード コマンドを実行します。Redis をリロードすると、シャットダウンが実行され、AOF 永続化が行われます。 redis.conf の RDB 永続性設定

# 只要满足下列条件之一，则会执行bgsave命令save 900 1 # 在900s内存在至少一次写操作save 300 10
save 60 10000# 禁用RBD持久化，可在最后加 save ""# 当备份进程出错时主进程是否停止写入操作stop-writes-on-bgsave-error yes# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵rdbcompression no

AOF 永続性

AOF (Append-Only-File) 永続性は、データベースのステータスを変更するすべての命令を記録し、AOF ファイルに追加します。追加の形式で。これを書き換える 1 つの方法は次のとおりです。 サーバーが再起動されると、AOF ファイルに記録されているコマンドを使用して、以前にシャットダウンされたときのデータベースの状態を復元できます。

redis.conf の AOF 永続性構成は次のとおりです

# 默认关闭AOF，若要开启将no改为yesappendonly no# append文件的名字appendfilename "appendonly.aof"# 每隔一秒将缓存区内容写入文件 默认开启的写入方式appendfsync everysec# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。auto-aof-rewrite-percentage 100# 当AOF文件大小大于该配置项时自动开启重写auto-aof-rewrite-min-size 64mb

AOF 永続性の実装には 3 つのステップが含まれます:

コマンドの追加: AOF バッファー ファイルにコマンドを追加します。 to write 入力: バッファーの内容が AOF ファイルに書き込まれます。 ファイル保存: AOF ファイルがディスクに保存されます。最後の 2 つのステップの頻度は、appendfsync によって構成されます。appendfsync のオプションには、

always が含まれますセキュリティ 最高、失われるのは最大でも 1 つのコマンドのデータだけですが、パフォーマンスも最低です (頻繁なディスク IO) 毎秒、1 秒に 1 回保存、推奨、セキュリティとパフォーマンスの妥協点、最大 1 秒間はデータ損失なし、オペレーティング システムによる実行 (通常は 30 秒に 1 回)、セキュリティは最低、パフォーマンスは最高 オペレーティング システムが最後に AOF で SAVE 操作をトリガーした後のデータファイルが失われます。AOF は、save コマンドによって保持されます。時間が経つにつれて、AOF ファイルはますます大きくなります。Redis は、AOF ファイルを書き換えることで、AOF ファイルの増加の問題を解決します (これにより、ファイルのディスク占有量が減り、データの速度が向上します)

子プロセスを作成するためにフォークを呼び出します

子プロセスは、現在のデータベースのステータスを読み取り、新しい AOF ファイルを「書き換え」ます (ただし、ここでは「再書き込み」と呼ばれますが、実際には古いファイルは読み取られませんが、命令はデータベースの現在のステータスに基づいて形成されます)

メイン プロセスは、AOF 再書き込みバッファと元のファイルに新しい変更を書き込み続けます。同時に AOF バッファを取得します。

メイン プロセスは子プロセスの書き換えを取得します。AOF 完了のシグナルを書き込み、信号処理関数を呼び出して AOF 書き換えバッファの内容を新しい AOF ファイルに書き込み、新しい AOF ファイルの名前を変更します。ファイルを削除し、元の AOF ファイルをアトミックに上書きし、古いファイルと新しいファイルの置換を完了します

AOF の書き換えは、手動トリガーと自動トリガーにも分かれています

手动触发： 直接调用bgrewriteaof命令
自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）的比值。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentage

##RDB と AOF

RDB と AOF にはそれぞれ長所と短所があります。

RDB の利点: AOF と比較して、RDB ファイルが比較的小さく、データの回復が高速です (理由についてはデータ回復のセクションを参照してください) RDB の欠点: サーバーがダウンすると、RBD メソッドは最後のデータを失います。 RDB の永続化 bgsave を使用して子プロセスをフォークした後のデータはメモリを消費します。 AOF の利点: AOF はファイルの追加のみを行い、サーバーのパフォーマンスへの影響が少なく、RDB より高速で、メモリ消費量が少なく、可読性が高くなります。 AOF を使用すると、生成されるファイルが比較的大きくなり、AOF で書き換えても依然として比較的大きいままであると同時に、データの回復速度も RDB に比べて遅いという 2 つのデメリットがあります。データベースリカバリ

AOF永続化機能がオンになっていない場合、サーバー起動時にRDBファイルの自動読み込み中にメインプロセスがブロックされてしまいます。 AOF 永続化機能がオンになっている場合、通常、AOF ファイルの更新頻度が RDB ファイルよりも高く、保存されたデータがより完全であるため、サーバーは AOF ファイルの使用を優先してデータベースの状態を復元します。

Redis データベース復旧の処理フローは次のとおりです。

データ復旧に関しては、次の 2 つの理由により RDB の起動時間が短くなります。ファイル、それぞれ 1 つのデータ項目に複数の操作レコードが存在する可能性がある AOF ログとは異なり、各データ項目にレコードは 1 つだけあります。したがって、各データは 1 回だけ書き込む必要があり、ファイルは比較的小さいです。

RDB 文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

但是在进行RDB持久化时，fork出来进行dump操作的子进程会占用与父进程一样的内存，采用的copy-on-write机制，对性能的影响和内存的消耗都是比较大的。比如16G内存，Redis已经使用了10G，这时save的话会再生成10G，变成20G，大于系统的16G。这时候会发生交换，要是虚拟内存不够则会崩溃，导致数据丢失。所以在用redis的时候一定对系统内存做好容量规划。

RDB、AOF混合持久化

Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份，由这两部分共同构成持久化文件。这个方案的优势在于其充分利用了RDB加载速度快、备份体积小以及AOF记录数据丢失几率尽可能低的特点。缺点是兼容性差，一旦开启了混合持久化，在4.0之前的版本都不识别该持久化文件，同时由于前部分是RDB格式，阅读性较低。

开启混合持久化

aof-use-rdb-preamble yes

数据恢复加载过程就是先按照RDB进行加载，然后把AOF命令追加写入。

持久化方案的建议 如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。建议同时采用两种持久化方式，以提高数据的安全性。如果你可以容忍在灾难发生时数据丢失几分钟，那么可以仅使用RDB。一般的设计方法是 使用主从复制机制以解决持久化时所带来的性能影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

以上がRedis 永続性を実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。