NoSQL-Redis の永続性

1. Redis の高可用性:

1。概要：

(1) Web サーバーにおいて、高可用性とはサーバーに正常にアクセスできる時間を指し、通常のサービスをどれだけ提供できるか (99.9%、99.99%、99.999% など) を目安とします。

(2) Redis の文脈での高可用性の意味はより広いと思われ、通常のサービス（マスター/スレーブ分離、迅速な災害復旧技術など）の提供の確保に加え、拡張性も考慮する必要がある損失のないデータ容量とデータのセキュリティ。

(3) Redis において高可用性を実現する技術としては、主に永続化、マスタースレーブレプリケーション、セントリー、クラスタークラスターがあり、それぞれの機能と解決する課題について説明します。

① 永続化: 永続化は最も単純な高可用性手法です (高可用性手法として分類されない場合もあります) その主な機能はデータのバックアップ、つまり、データが何らかの原因で失われないようにハードディスクにデータを保存することです。プロセス終了。

② マスター/スレーブレプリケーション: マスター/スレーブレプリケーションは高可用性 Redis の基礎であり、Sentinel とクラスターは高可用性を実現するためにマスター/スレーブレプリケーションに基づいています。マスター/スレーブレプリケーションでは、主にデータのマルチマシンバックアップ、読み取り操作の負荷分散、および単純な障害回復が実装されます。欠点: 障害回復は自動化できません。書き込み操作の負荷分散はできません。ストレージ容量は 1 台のマシンによって制限されます。

③ Sentinel: マスター/スレーブレプリケーションに基づいて、Sentinel は自動障害回復を実現します。欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。

④ クラスタークラスター: Redis は、クラスターを通じて、書き込み操作の負荷分散ができない、ストレージ容量が 1 台のマシンに制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。

2 番目に、Redis の永続性:

1. 永続化機能:

Redis はインメモリデータベースであり、データはメモリ上に保存されますが、サーバーの電源障害などの理由で Redis プロセスが異常終了した後、データが永久に失われることを避けるために、定期的にデータをメモリ上に保存する必要があります。 Redis をメモリから何らかの形式 (データまたはコマンド) でハードディスクに保存します。次回 Redis を再起動するときに、永続ファイルを使用してデータを回復します。さらに、永続ファイルは、災害時バックアップの目的でリモートの場所にコピーできます。

2. Redis は永続化のために 2 つの方法を提供します。

(1) RDB 永続性: 原則として、メモリ内の Reid のデータベースレコードを定期的にディスクに保存します。
(2) AOF 永続化 (ファイル追加のみ): MySQL の binlog と同様に、Reid の操作ログをファイルに追加で書き込むのが原則です。

AOF 永続化のリアルタイムパフォーマンスが優れているため、つまり、プロセスが予期せず終了した場合に失われるデータが少ないため、現在 AOF が主流の永続化方法ですが、RDB 永続化も依然としてその地位を占めています。

3. RDB の永続性:

1. 定義:

RDB 永続化とは、メモリ上の現在のプロセスのデータのスナップショットを指定された時間間隔でハードディスクに保存することを指し (そのため、スナップショット永続化とも呼ばれます)、バイナリ圧縮で保存され、保存されたファイルのサフィックスは rdb です。 ; Redis が再起動すると、スナップショットファイルを読み取ってデータを復元できます。

2. トリガー条件:

RDB 永続化のトリガーは、手動トリガーと自動トリガーに分けられます。

(1) 手動トリガー:
save コマンドと bgsave コマンドの両方で RDB ファイルを生成できます。
save コマンドは、RDB ファイルが作成されるまで Redis サーバープロセスをブロックします。Redis サーバーのブロック中、サーバーはコマンドリクエストを処理できません。
bgsave コマンドは、RDB ファイルの作成を担当する子プロセスを作成し、親プロセス (つまり、Redis メインプロセス) がリクエストの処理を続行します。

bgsaveコマンドの実行中はfork子プロセスのみがサーバーをブロックしますが、saveコマンドの場合はプロセス全体がサーバーをブロックするため、基本的にsaveは放棄されており、オンラインではsaveの使用を避ける必要があります。環境。

(2) 自動トリガー:
RDB 永続化を自動的にトリガーする場合、Redis は永続化のために保存する代わりに bgsave を選択します。

save mnを自動トリガーする最も一般的なケース
は、設定ファイルに save mn を渡して、m 秒以内に n 回の変更が発生したときに bgsave がトリガーされるように指定することです。

vim /etc/redis/6379.conf
--219行--以下三个save条件满足任意一个时，都会引起bgsave的调用
save 900 1 ：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave
--254行--指定RDB文件名
dbfilename dump.rdb
--264行--指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379
--242行--是否开启RDB文件压缩
rdbcompression yes

(3) その他の自動トリガーメカニズム:
save mn に加えて、bgsave をトリガーする状況は他にもあります。
① マスター/スレーブレプリケーションシナリオでは、スレーブノードがフルコピー操作を実行すると、マスターノードは bgsave コマンドを実行し、スレーブノードに送信されたrdbファイルを保存します。
② shutdownコマンドを実行すると、自動的にrdb永続化が実行されます。

3. 実行プロセス:

(1) まず、Redis の親プロセスが現在 save を実行しているか、bgsave/bgrewriteaof の子プロセスであるかを判断し、実行中の場合は bgsave コマンドをそのまま返します。bgsave/bgrewriteaof の子プロセスは、主にパフォーマンス上の考慮事項に基づいて同時に実行できません。2 つの同時子プロセスが同時に大量のディスク書き込み操作を実行するため、重大なパフォーマンス上の問題が発生する可能性があります。
(2) 親プロセスがフォーク操作を実行して子プロセスを作成します。このプロセス中、親プロセスはブロックされ、Redis はクライアントからのコマンドを実行できません。 (3) 親プロセスがフォークした後、bgsave コマンドは「
バックグラウンド保存を開始しました」というメッセージが表示され、ブロックされなくなります。親プロセスは他のコマンドに応答できます。
(4) 子プロセスは、RDB ファイルを作成し、親プロセスのメモリスナップショットに基づいて一時スナップショットファイルを生成し、元のファイルをアトミックに置き換えます。完了後
(5) 子プロセスは親プロセスに完了を示すシグナルを送信し、親プロセスはプロセスの統計を更新します。

ここに画像の説明を挿入

4. 起動時にロードします。

(1) RDB ファイルのロードはサーバ起動時に自動的に実行され、特別なコマンドは必要ありません。ただし、AOF の優先度が高いため、AOF がオンになっている場合は、Redis が最初にロードされます。

(2) AOF ファイルはデータの復元に使用されます。AOF が閉じられている場合にのみ、Redis サーバーの起動時に RDB ファイルが検出され、自動的にロードされます。RDB ファイルのロード中、ロードが完了するまでサーバーはブロックされます。

(3) Redis は RDB ファイルをロードする際に RDB ファイルを検証しますが、ファイルが破損している場合はログにエラーが出力され、Redis が起動できなくなります。

5. RDB の長所と短所:

(1) デメリット:
① データの整合性が aof ほど良くない
② rdb はスナップショットに似ている (完璧)
③ バックアップを実行するとプロセスがブロックされる
(2) メリット:
① 永続的な速度ブロック (データの保存結果のため)に書き込むとき * ．RDB 永続ファイルはサイズを減らすために圧縮されます。
② クラスター内では、Redis マスター/スレーブレプリケーション、マスターサーバーからの同期、デフォルトでは RDB ファイルが最初に使用され、リカバリ操作、すべての同期パフォーマンスが高い

4. AOF の永続性:

RDB 永続性はプロセスデータをファイルに書き込むことですが、AOF 永続性は Redis によって実行された各書き込みおよび削除コマンドを別のログファイルに記録し、クエリ操作は記録されません。Redis が再起動すると、AOF ファイルコマンドを再度実行します。データを復元します。AOF は RDB と比較してリアルタイム性が優れているため、永続化ソリューションの主流となっています。

1. AOF をオンにします。

Redis サーバーはデフォルトで RDB を有効にし、AOF を無効にします。AOF を有効にするには、構成ファイルで構成する必要があります。

vim /etc/redis/6379.conf
--700行--修改，开启AOF
appendonly yes
--704行--指定AOF文件名称
appendfilename "appendonly.aof"
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
/etc/init.d/redis_6379 restart

2. 実行プロセス:

Redis の各書き込みコマンドを記録する必要があるため、AOF をトリガーする必要はありませんが、以下に AOF の実行プロセスを説明します。

(1) コマンドの追加 (追加):
① Redis は、ファイルに直接書き込むのではなく、最初に書き込みコマンドをバッファーに追加します。これは主に、書き込みコマンドがあるたびにハードディスクに直接書き込むことを避けるためであり、ハードディスク IO がRedis 負荷のボトルネック。
② コマンド追加の形式は、Redis コマンドリクエストのプロトコル形式であり、プレーンテキスト形式であるため、互換性が高く、可読性が高く、処理が容易で、操作が簡単で、二次的なオーバーヘッドが回避されるという利点があります。

③ AOF ファイルでは、Redis によって追加されたデータベースを指定する select コマンド (select 0 を選択してデータベース 0 を選択するなど) を除いて、その他はすべてクライアントから送信される write コマンドです。

(2)ファイル書き込み (write) とファイル同期 (sync):
Redis は、オペレーティングシステムの write 関数と fsync 関数を使用して、AOF バッファー領域に対してさまざまなファイル同期戦略を提供します。
ファイルの書き込み効率を向上させるために、最新のオペレーティングシステムでは、ユーザーがファイルにデータを書き込むために write 関数を呼び出すと、オペレーティングシステムは通常、バッファがいっぱいであるかメモリバッファを超える場合にのみ、データをメモリバッファに一時的に保存します。指定された制限時間が経過すると、オペレーティングシステムは実際にデータを保存します。バッファ内のデータはハードディスクに書き込まれます。この種の操作は効率を向上させますが、セキュリティ上の問題も引き起こします。コンピュータがシャットダウンすると、メモリバッファ内のデータが失われるため、システムには、オペレーティングシステムを強制的に実行できる fsync や fdatasync などの同期機能も用意されています。データのセキュリティを確保するために、データはハードディスクに書き込まれます。

AOF キャッシュ領域の同期ファイル戦略には、次の 3 つの同期方法があります。

vim /etc/redis/6379.conf
--729--
●appendfsync always： 命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。

●appendfsync no： 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。

●appendfsync everysec： 命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

(3) ファイルの書き換え（リライト）

① ファイル書き換えとは、AOF ファイルを定期的に書き換えて、AOF ファイルのサイズを削減することを指します。AOF の再書き込みは、Redis プロセス内のデータを書き込みコマンドに変換し、新しい AOF ファイルに同期することであり、古い AOF ファイルに対して読み取りまたは書き込み操作を実行しないことに注意してください。

② ファイルの書き換えに関するもう 1 つの注意点は、AOF 永続性の場合、ファイルの書き換えが強く推奨されていますが、必須ではありません。ファイルの書き換えがなくても、データは永続化され、Redis Import で随時開始できます。そのため、実際には、自動的にファイルの書き換えはオフになり、スケジュールされたタスクによって毎日特定の時刻に実行されるようにスケジュールされます。

③ ファイル書き換えにより AOF ファイルが圧縮される理由は次のとおりです。

期限切れのデータはファイルに書き込まれなくなります
無効なコマンドがファイルに書き込まれなくなりました。たとえば、一部のデータが繰り返し設定される (set mykey v1、set mykey v2)、一部のデータが削除される (set myset v1、del myset) などです。
複数のコマンドを 1 つに結合できます。たとえば、sadd myset v1、sadd myset v2、sadd myset v3 は、sadd myset v1 v2 v3 に結合できます。
上記の内容から、書き換え後はAOFで実行するコマンドが削減されるため、ファイル書き換えによりファイルの占有容量が削減されるだけでなく、復旧速度も高速化できることがわかります。

④ ファイル書き換えのトリガーは手動トリガーと自動トリガーに分かれます。

手動トリガー: bgrewriteaof コマンドを直接呼び出します。このコマンドの実行は bgsave に似ています。両方の fork サブプロセスが特定の作業を実行し、両方とも fork 時にのみブロックされます。
自動トリガー: auto-aof-rewrite-min-size オプションと auto-aof-rewrite-percentage オプションを設定すると、BGREWRITEAOF が自動的に実行されます。auto-aof-rewrite-min-size と auto-aof-rewrite-percentage の 2 つのオプションが同時に満たされた場合にのみ、AOF 書き換え、つまり bgrewriteaof 操作が自動的にトリガーされます。

vim /etc/redis/6379.conf
--729--
●auto-aof-rewrite-percentage 100	：当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
●auto-aof-rewrite-min-size 64mb ：当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF	


关于文件重写的流程，有两点需要特别注意：(1)重写由父进程fork子进程进行；(2)重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

⑤ ファイル書き換えの処理は以下のとおりです
(1) Redis の親プロセスは、まず bgsave/bgrewriteaof を実行している子プロセスが存在するかどうかを判断し、存在する場合は bgrewriteaof コマンドをそのままリターンし、bgsave コマンドがある場合は待機します。 bgsave の実行は、実行する前に完了する必要があります。
(2) 親プロセスが fork 操作を実行して子プロセスを作成し、このプロセス中に親プロセスがブロックされます。
(3.1) 親プロセスがフォークした後、bgrewriteaof コマンドは「バックグラウンド追加のみのファイル書き換えが開始されました」というメッセージを返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります。Redis のすべての書き込みコマンドは引き続き AOF バッファーに書き込まれ、appendfsync 戦略に従ってハードディスクに同期され、元の AOF メカニズムの正確性が保証されます。
(3.2) フォーク操作ではコピーオンライト技術が使用されるため、子プロセスはフォーク操作中にのみメモリデータを共有できます。親プロセスはまだコマンドに応答しているため、Redis は AOF 書き換えバッファー (aof_rewrite_buf) を使用してデータのこの部分を保存し、新しい AOF ファイルの生成中にデータのこの部分が失われるのを防ぎます。つまり、bgrewriteaof の実行中に、Redis 書き込みコマンドが 2 つのバッファー aof_buf と aof_rewrite_buf に同時に追加されます。
(4) 子プロセスは、メモリスナップショットに従って、コマンドマージルールに従って新しい AOF ファイルに書き込みます。
(5.1) 子プロセスが新しい AOF ファイルを書き込んだ後、親プロセスにシグナルを送信し、親プロセスは統計情報を更新します。統計情報は情報永続化を通じて表示できます。
(5.2) 親プロセスは、AOF 書き換えバッファ内のデータを新しい AOF ファイルに書き込み、新しい AOF ファイルに保存されたデータベースの状態がサーバーの現在の状態と一致することを保証します。
(5.3) 古いファイルを新しい AOF ファイルに置き換えて、AOF の書き換えを完了します。

ここに画像の説明を挿入

3. 起動時にロードします。

(1) AOF がオンになっている場合、Redis は起動時に最初に AOF ファイルをロードしてデータを復元しますが、AOF がオフの場合にのみ、RDB ファイルをロードしてデータを復元します。

(2) AOFが有効でAOFファイルが存在しない場合、RDBファイルが存在してもロードされません。

(3) Redis は AOF ファイルをロードするときに AOF ファイルを検証しますが、ファイルが破損している場合はログにエラーが出力され、Redis が起動できません。ただし、AOF ファイルの末尾が不完全な場合（突然のマシンのダウンタイムなどにより、ファイルの末尾が不完全になる可能性があります）、aof-load-truncated パラメータが有効になっている場合、ログに警告が出力されます。 , Redis は AOF ファイルの末尾を無視し、起動は成功します。aof-load-truncated パラメータはデフォルトで有効になっています。

4. AOF の長所と短所:

(1) デメリット
① ステートメントを常時実行すると、AOF バックアップの内容は大きくなり、RDB バックアップの内容は小さくなり、バックアップ結果、ステートメント

② AOF はより多くのパフォーマンスを消費し、より多くのディスクを占有します (mysql バックアップに相当)

(2) メリット：

① AOF は RDB よりもデータの完全性が高い

② 書き換え機能により、無効なステートメントが削除されます（目的は、AOF ファイルが占有するディスク領域を節約することです）。

5. Redis のパフォーマンス管理:

1. Redis のメモリ使用量を表示します。

info memory

2. メモリの断片化率:

(1) オペレーティングシステムによって割り当てられた used_memory_rss メモリ値を、Redis によって使用される合計メモリ値 used_memory で割ることによって計算されます。
メモリ値 used_memory_rss は、プロセスが占有する物理メモリのサイズ、つまり、オペレーティングシステムによって Redis インスタンスに割り当てられたメモリのサイズを示します。

(2) ユーザー定義データと内部オーバーヘッドに加えて、used_memory_rss インジケーターには、オペレーティングシステムによる物理メモリの非効率な割り当て/再利用 (不連続な物理メモリ割り当て) によって引き起こされるメモリ断片化のオーバーヘッドも含まれます。

(3) 例: Redis は、1G データセットを保存するために連続メモリブロックを割り当てる必要があります。物理メモリに 1G を超える連続メモリブロックがない場合、オペレーティングシステムは複数の不連続な小さなメモリブロックを使用して 1G データを割り当てて保存する必要があり、この操作によりメモリの断片化が発生します。

メモリの断片化率が 1 よりわずかに大きいのは妥当です。この値は、メモリの断片化率が比較的低いことを示しており、また、Redis がメモリを交換しないことも示しています。
メモリ断片化率が 1.5 を超える場合、Redis が実際に必要な物理メモリの 150% を消費し、そのうち 50% がメモリ断片化率であることを意味します。redis-cli ツールで shutdown save コマンドを入力して、Redis データベースに保存操作を実行させ、Redis サービスを閉じてから、サーバーを再起動する必要があります。
メモリ断片化率が 1 より低い場合は、Redis メモリ割り当てが物理メモリを超えており、オペレーティングシステムがメモリを交換していることを意味します。利用可能な物理メモリを増やすか、Redis のメモリフットプリントを減らす必要があります。

3. メモリ使用量:

Redis インスタンスのメモリ使用量が利用可能な最大メモリを超えると、オペレーティングシステムはメモリとスワップスペースの交換を開始します。
メモリのスワップを回避する方法:
- キャッシュされたデータのサイズに応じて Redis インスタンスのインストールを選択します
- 可能な限りハッシュデータ構造ストレージを使用する
- キーの有効期限を設定する

4. 内部回復キー:

メモリクリーニング戦略により、Redis の限られたメモリリソースが適切に割り当てられます。

設定された最大しきい値に達すると、主要なリサイクル戦略を選択する必要があります。デフォルトでは、リサイクル戦略は削除を禁止します。

vim /etc/redis/6379.conf
--598--
maxmemory-policy noenviction
volatile-lru：使用LRU算法从已设置过期时间的数据集合中淘汰数据(移除最近最少使用的key，针对设置了TTL的key)
volatile-ttl：从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
volatile-random：从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
allkeys-lru：使用LRU算法从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
allkeys-random：从数据集合中任意选择数据淘汰（随机移除key）
noenviction：禁止淘汰数据（不删除直到写满时报错）

6. RDB と AOF の概要:

1. RDB と AOF の基本的な理解:

(1) RDB: メモリ上のデータを定期的にディスクに保存します。

(2) AOF：redisの実行操作ログから実行プロセスをディスクに同期します。

2. RDB と AOF 永続化のプロセス:

（１）ＲＤＢ： ①メモリ上、ディスクに書き込んで保存する方法。

② 結果データはディスクに保存されているデータオブジェクトに書き込まれます。

③ メモリがディスクに書き込まれた後、*.rdb が占有するディスク容量を減らすために圧縮されます。

(2) AOF: ① メモリ上でバッファに追加し、CPU リソースを呼び出してディスクに書き込みます。

②操作ログの実行文をバッファに追記し、CPUリソースを呼び出してディスクに書き込みます。

③ メモリ、バッファ、ディスクは書き込み後定期的に書き換えられ、一部の「無効な操作」をスキップして保存されます。

3. RDB と AOF のトリガー方法:

(1) RDB: ①手動トリガー

② 自動トリガー：分を保存します。

③特別なトリガー: 手動で閉じると、rdb は永続化されます。/etc/init.d/redis_6379 再起動

(2) AOF: ① マニュアルトリガー

② 自動トリガー: 永続化のために各ステートメントを常に同期的に実行します (強い整合性を備えたシナリオ)

いいえ、決して永続的ではありません

each Second AOE 永続化は 1 秒ごとに実行されます (推奨される、バランスのとれたシナリオ)

4. RDB と AOE の優先順位:

(1) redis はデフォルトでデータをメモリに保存するため、redis を起動または終了するとメモリ内のデータが失われます。

(2) redis が起動するたびに、永続ファイルを読み取り、データをメモリに送信して、reids データの整合性を確保します。

(3) RDB と AOF の優先順位 aof> RDB 設定ファイルの各パラメータの変更開始を指定できる 6379.conf

5. RDB と AOF の長所と短所:

(1) RDB の永続化:

① 利点: RDB ファイルはコンパクトでサイズが小さく、ネットワーク転送が速く、フルコピーに適しており、回復速度が AOF よりもはるかに速いです。もちろん、AOF と比較した RDB の最も重要な利点の 1 つは、パフォーマンスへの影響が比較的小さいことです。

② 短所: RDB ファイルの致命的な欠点は、データスナップショットの永続化方法により、リアルタイムの永続化が達成できないと判断されることです。データの重要性がますます高まっている現在、大量のデータ損失はしばしば許容できないため、AOF が使用されます。持続性が主流になります。さらに、RDB ファイルは特定の形式を満たす必要があり、互換性が低くなります (たとえば、古いバージョンの Redis は新しいバージョンの RDB ファイルと互換性がありません)。

③ RDB 永続化の場合、bgsave が fork 操作を実行するときに Redis のメインプロセスがブロックされる一方で、子プロセスによるハードディスクへのデータの書き込みも IO プレッシャーになります。

(2) AOF の永続化

① RDB の永続化に対応し、第 2 レベルの永続化に対応し、互換性が高いことが AOF のメリットですが、デメリットは、ファイルが大きく、回復速度が遅く、パフォーマンスへの影響が大きいことです。

② AOF 永続性の場合、ハードディスクへのデータの書き込み頻度が大幅に増加し (毎秒戦略の 2 番目のレベル)、IO プレッシャーが大きくなり、AOF の追加のブロッキング問題が発生する可能性もあります。

この方法では、リアルタイムの永続化は実現できないと判断され、データの重要性がますます高まっている今日では、大量のデータ損失が許容できないことが多いため、AOF 永続化が主流になっています。さらに、RDB ファイルは特定の形式を満たす必要があり、互換性が低くなります (たとえば、古いバージョンの Redis は新しいバージョンの RDB ファイルと互換性がありません)。

(2) AOF の永続化

③ AOF ファイルの書き換えは RDB の bgsave と同様で、fork 時のブロックや子プロセスの IO プレッシャーが発生します。比較的に、AOF はハードディスクにデータをより頻繁に書き込むため、Redis メインプロセスのパフォーマンスに大きな影響を与えます。