Redis の高可用性と永続性

1. Redis の高可用性

1.コンセプト

  Web サーバーにおける高可用性とは、サーバーに正常にアクセスできる時間を指し、通常のサービスをどれだけ長く提供できるか (99.9%、99.99%、99.999% など) を測定します。ただし、Redis の文脈での高可用性の意味はもっと広いと思われ、通常のサービス (マスター/スレーブ分離、迅速な災害復旧技術など) の提供の確保に加えて、高可用性の拡張も考慮する必要があります。損失のないデータ容量とデータセキュリティ。

2. 高可用性テクノロジーとその機能

  Redis では、高可用性を実現するテクノロジーには主に、永続性、マスター/スレーブ レプリケーション、センチネル、クラスターが含まれます。

2.1 持久化

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

2.2 マスター/スレーブレプリケーション

  マスター/スレーブ レプリケーションは高可用性 Redis の基礎であり、センチネルとクラスターは高可用性を実現するためにマスター/スレーブ レプリケーションに基づいています。マスター/スレーブ レプリケーションでは、主にデータのマルチマシン バックアップ、読み取り操作の負荷分散、および単純な障害回復が実装されます。

  欠点: 障害回復は自動化できません。書き込み操作の負荷分散はできません。ストレージ容量は 1 台のマシンによって制限されます。

2.3 センチネル

  Sentinel は、マスター/スレーブ レプリケーションに基づいて、自動障害回復を実装します。

  欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。

2.4 クラスター

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

2. Redis の永続化

1. 永続化機能

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

2. Redisの永続化方法

	RDB 永続化 (Redis データベース)	AOF持久化（append only file）
原理	メモリ内の Reids データベース レコードを定期的にディスクに保存します。仮想マシンがスナップショットを取得する方法と似ています。	Reidsの操作ログを追記モードでファイルに書き込みます。MySQL のバイナリログに似ています。
パフォーマンス

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

3. RDB の永続化

1。概要

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

2. 発動条件

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

2.1 手動トリガー

save コマンドと bgsave コマンドの両方で RDB ファイルを生成できます。

save コマンドは、RDB ファイルが作成されるまで Redis サーバー プロセスをブロックします。Redis サーバーのブロック中、サーバーはコマンド リクエストを処理できません。

bgsave コマンドは、RDB ファイルの作成を担当する子プロセスを作成し、親プロセス (つまり、Redis メイン プロセス) がリクエストの処理を続行します。

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

2.2 自動トリガー

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

#通过配置设置触发
save m n

#自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。
vim /usr/local/redis/conf/redis.conf

#-----443行--以下三个save条件满足任意一个时，都会引起bgsave的调用
# save 3600 1 300 100 60 10000
save 900 1 ：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时， 如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化， 则执行bgsave

#-----242行--是否开启RDB文件压缩

rdbcompression yes

2.3 その他の自動送信メカニズム

save mn に加えて、bqsave をトリガーする状況が他にもいくつかあります。次に例を示します。

• マスター/スレーブ レプリケーション シナリオでは、スレーブ ノードがフル コピー操作を実行すると、マスター ノードは bgsave コマンドを実行し、rdb ファイルをスレーブ ノードに送信します。
• shutdownコマンドを実行すると、自動的にRDB永続化が実行されます。

3. 実行プロセス

(1) Redis の親プロセスがまず、現在実行中saveかbgsave/bgrewriteaofの子プロセスかを判断し、実行中の場合は bgsave コマンドが直接戻ります。bgsave/bogrewriteaofの子プロセスは、主にパフォーマンス上の考慮事項に基づいて、同時に実行できません。2 つの同時子プロセスが同時に大量のディスク書き込み操作を実行するため、重大なパフォーマンス上の問題が発生する可能性があります。

(2) 親プロセスが fork 操作を実行して子プロセスを作成すると、親プロセスはブロックされ、Redis はクライアントからのコマンドを実行できなくなります。

(3) 親プロセスがフォークした後、bgsaveコマンドは「Background saving started」情報を返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります。

(4) 子プロセスは RDB ファイルを作成し、親プロセスのメモリ スナップショットに基づいて一時スナップショット ファイルを生成し、完了後に元のファイルをアトミックに置き換えます。

(5) 子プロセスは親プロセスに完了を示すシグナルを送信し、親プロセスは統計を更新します。

4. 起動時のロード

RDBファイルのロードはサーバ起動時に自動的に実行され、特別なコマンドは必要ありません。ただし、AOF の優先度が高いため、AOF が有効になっている場合、Redis は AOF ファイルのロードを優先してデータを復元します。AOF が閉じられている場合にのみ、Redis サーバーの起動時に RDB ファイルが検出され、自動的にロードされます。RDB ファイルのロード中、ロードが完了するまでサーバーはブロックされます。

Redis は RDB ファイルをロードするときに RDB ファイルを検証しますが、ファイルが破損している場合はログにエラーが出力され、Redis は起動できません。

[外部リンク画像の転送に失敗しました。ソース サイトには盗難防止リンク メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-eISyZQgT-1688040423867) (C:\Users\86138\AppData\Roaming\Typora) \typora-user-images\ image-20230629104205320.png)]

4. AOF の永続性

1。概要

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

AOF は RDB と比較してリアルタイム性が優れているため、永続化ソリューションの主流となっています。

2.AOFをオンにする

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

vim /usr/local/redis/conf/redis.conf

#————1380行————修改，开启AOF
appendonly yes
#————1407行————指定AOE文件名称
appendfilename "appendonly.aof"
#————1505行————是否忽略最后一条可能存在问题的指令
aof-load-truncated yes

systemctl restart redis-server.service

3. 実行プロセス

Redis の各書き込みコマンドを記録する必要があるため、A0F をトリガーする必要はありません。AOF の実行プロセスは次のとおりです。

• コマンド追加 (append): Redis 書き込みコマンドをバッファー aof_ buf に追加します。

• ファイル書き込み (write) とファイル同期 (sync): さまざまな同期戦略に従って、aof_buf の内容をハード ディスクに同期します。

• ファイルの書き換え (リライト): 圧縮の目的を達成するために、AOF ファイルを定期的に書き換えます。

3.1 命令追加（append）

Redis は、ファイルに直接書き込むのではなく、最初に書き込みコマンドをバッファーに追加します。これは主に、毎回コマンドを直接ハードディスクに書き込むことを回避するためであり、ハードディスク IO が Redis 負荷のボトルネックになるのを防ぎます。

コマンド append の形式は、Redis コマンドリクエストのプロトコル形式であり、プレーンテキスト形式であり、互換性が高く、可読性が高く、処理が容易で、操作が簡単で、二次的なオーバーヘッドが回避されるという利点があります。A0F ファイルでは、データベースを指定する (たとえば、select 0データベース 0 を選択する) ために使用される select コマンド (Redis によって追加される) を除き、その他はすべてクライアントによって送信される書き込みコマンドです。

3.2 ファイル書き込み（write）とファイル同期（sync）

Redis は、AOF キャッシュ領域に対してさまざまな同期ファイル戦略を提供しており、これらの戦略には、以下に説明するように、オペレーティング システムの機能がwrite含まれます。fsync

ファイルの書き込み効率を向上させるために、最新のオペレーティング システムでは、ユーザーがファイルにデータを書き込むために書き込み関数を呼び出すと、通常、オペレーティング システムはデータをメモリ バッファに一時的に保存します。バッファがいっぱいになるか、指定された After を超えると、制限時間が経過すると、バッファ内のデータが実際にハードディスクに書き込まれます。fsyncこの種の操作により効率は向上しますが、セキュリティ上の問題も発生します。コンピュータが停止すると、メモリ バッファ内のデータが失われますfdatasync。データのセキュリティを確保するには、ハードディスクに書き込みます。

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

• appendfsync always: 常にトリガーします
• appendfsync no: 持続性なし
• appendfsync everysec: 毎秒トリガー

vim /usr/local/redis/conf/redis.conf

#---1439---
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.3 ファイルの書き換え（リライト）

時間が経つにつれて、Redis サーバーはより多くの書き込みコマンドを実行し、AOF ファイルはますます大きくなります。AOF ファイルが大きすぎると、サーバーの通常の動作に影響を与えるだけでなく、データの回復に時間がかかりすぎる原因になります。 。

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

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

ファイル書き換えによりAOFファイルが圧縮される理由

• 期限切れのデータはファイルに書き込まれなくなります。
• 無効なコマンドがファイルに書き込まれなくなりました。たとえば、一部のデータが繰り返し設定される ( set mykey v1、set mykey v2)、一部のデータが削除される ( sadd myset v1、del myset) などです。
• 複数のコマンドを 1 つに結合できます。たとえばsadd myset v1、sadd myset v2、 、sadd myset vt3 を 1 つに結合できます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 2 つのオプションが同時に満たされた場合にのみauto-aof-rewrite-percentage、AOF 書き換え、つまりbgrewriteaof操作が自動的にトリガーされます。

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

4. ファイル書き換えのプロセス

ファイルの書き換え処理に関して、特に注意が必要な点が 2 つあります。

• 書き換えは、子プロセスをフォークする親プロセスによって実行されます。
• 書き換え中に cerdtis によって実行される書き込みコマンドは、新しい kac ファイルに追加する必要があり、oedis には aofrewite_buf キャッシュが導入されます。

具体的なプロセスは次のとおりです。

1. bgsaveRedisの親プロセスは、まず現在実行中の子プロセスが存在するかどうかを判断しbgrewriteaof 、存在するbgrewriteaof場合はそのままコマンドを返し、存在する場合は実行完了後にbgsaveコマンドを実行します。bgsave
2. 親プロセスはフォーク操作を実行して子プロセスを作成しますが、親プロセスはこのプロセス中にブロックされます。
3. • 親プロセスがフォークすると、bgrewriteaofコマンドは「Background append only file rewrite started」情報を返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります。Redis のすべての書き込みコマンドは引き続き AOF バッファーに書き込まれ、appendfsync 戦略に従ってハードディスクに同期され、元の AOF メカニズムの正確性が保証されます。
   • フォーク操作ではコピーオンライト技術が使用されるため、子プロセスはフォーク操作中にのみメモリ データを共有できます。親プロセスはまだコマンドに応答しているため、Redis は AOF 書き換えバッファ ( aof_rewrite_buf) を使用してデータのこの部分を保存し、新しい AOF ファイルの生成中にデータのこの部分が失われるのを防ぎます。つまり、bgrewriteaof実行中、Redis 書き込みコマンドは 2 つのバッファーに同時に追加されaof_ bufますaof_ rewirte_ buf。
4. 子プロセスは、メモリ スナップショットに基づくコマンド マージ ルールに従って、新しい AOF ファイルに書き込みます。
5. • 子プロセスが新しい AOF ファイルの書き込みを完了すると、親プロセスにシグナルが送信され、親プロセスは統計情報を更新します。統計情報は を介し​​て表示できますinfo persistence。
   • 親プロセスは、AOF 書き換えバッファ内のデータを新しい AOF ファイルに書き込みます。これにより、新しい AOF ファイルに保存されたデータベースの状態がサーバーの現在の状態と一致することが保証されます。
   • 古いファイルを新しい AOF ファイルに置き換えて、AOF の書き換えを完了します。

[外部リンク画像の転送に失敗しました。ソース サイトには盗難防止リンク メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-7snIQ0N8-1688040423869) (C:\Users\86138\AppData\Roaming\Typora) \typora-user-images\ image-20230629120540966.png)]

5.起動時のロード

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

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

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

aof-load-truncated このパラメータはデフォルトで有効になっています。

6. RDBとAOFのメリットとデメリット

6.1 RDB永続化のメリットとデメリット

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

短所: RDB ファイルの致命的な欠点は、データ スナップショットの永続化方法により、リアルタイムの永続化が達成できないと判断されることです。データの重要性がますます高まっている現在、大量のデータ損失はしばしば許容できないため、AOF 永続化が必要です。主流になる。さらに、RDB ファイルは特定の形式を満たす必要があり、互換性が低くなります (たとえば、古いバージョンの Redis は新しいバージョンの RDB ファイルと互換性がありません)。RDB 永続性の場合、bgsave がフォーク操作を実行するときに Redis メイン プロセスがブロックされる一方で、子プロセスによるハードディスクへのデータの書き込みも IO プレッシャーをもたらします。

6.2 AOF 永続化の長所と短所

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

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

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

5、Redisパフォーマンス管理

1. Redis のメモリ使用量を表示する

192.168.145.60:7001> info memory

2. メモリの断片化率

mem_fragmentation_ratio：内存碎片率。mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory_rss：是Redis向操作系统申请的内存。
used_memory：是Redis中的数据占用的内存。
used_memory_peak：redis内存使用的峰值。

2.1 メモリの断片化はどのようにして起こるのでしょうか?

Redis には、メモリ使用効率を向上させるためにアプリケーションとメモリの解放を管理する独自の内部メモリ マネージャーがあります。

Redis の値が削除されると、メモリは直接解放されず、オペレーティング システムに返されますが、Redis の内部メモリ マネージャーに返されます。

Redis でメモリを申請するときは、まず独自のメモリ マネージャーに十分なメモリが利用可能かどうかを確認します。

Redis のこのメカニズムによりメモリ使用率は向上しますが、Redis 内に自身で使用されずに解放されないメモリが発生し、メモリの断片化が発生します。

2.2 メモリの断片化率を追跡する

メモリ断片化率を追跡することは、Redis インスタンスのリソース パフォーマンスを理解するために非常に重要です。

• メモリの断片化率は 1 ～ 1.5 であるのが通常です。この値は、メモリの断片化率が比較的低いことを示し、また、Redis がメモリを交換しないことを示します。
• メモリ断片化率が 1.5 を超える場合、Redis が実際に必要な物理メモリの 150% を消費し、そのうち 50% がメモリ断片化率であることを意味します。
• メモリ断片化率が 1 より低い場合は、Redis メモリ割り当てが物理メモリを超えており、オペレーティング システムがメモリを交換していることを意味します。利用可能な物理メモリを増やすか、Redis メモリの使用量を減らす必要があります。

2.3 高い断片化率の問題を解決する

shutdown saveRedis バージョンが 4.0 より前の場合は、redis-cli ツールでコマンドを入力して、Redis データベースに保存操作を実行させ、Redis サービスを閉じて、サーバーを再起動する必要があります。Redis サーバーが再起動すると、Redis は不要なメモリをオペレーティング システムに返し、断片化率が低下します。

Redis のバージョン 4.0 以降では、再起動せずにオンラインでメモリをデフラグできるようになりました。

config set activedefrag yes     #自动碎片清理，内存就会自动清理了。
memory purge					#手动碎片清理

3. メモリ使用量

Redis インスタンスのメモリ使用量が利用可能な最大メモリを超えると、オペレーティング システムはメモリとスワップ スペースの交換を開始します。

3.1 メモリのスワップを回避する方法

• キャッシュされたデータのサイズに応じて Redis インスタンスのインストールを選択します。
• 可能な限りハッシュ データ構造ストレージを使用します。
• キーの有効期限を設定します。

4. 内部回復キー

メモリ データの削除戦略により、Redis の限られたメモリ リソースが適切に割り当てられます。

設定された最大しきい値に達すると、主要なリサイクル戦略を選択する必要があります。デフォルトでは、リサイクル戦略は削除を禁止します。構成ファイル内の属性値
を変更します。maxmemory-policy

vim /usr/local/redis/conf/redis.conf
--1149--
maxmemory-policy noenviction

volatile-lru: LRU アルゴリズムを使用して、有効期限が設定されたデータ セットからデータを削除します (TTL が設定されたキーの場合は、最も最近使用されていないキーを削除します) volatile-ttl: 有効期限が設定されたデータ セットから選択します
。期限切れが近づいているデータ (最後に期限切れになったキーを削除)
volatile-random: 削除する有効期限が設定されたデータ セットからデータをランダムに選択します (TTL セットでキーからランダムに削除) allkeys-
lru: LRU アルゴリズムを使用して、すべてのデータセットからデータを削除します (すべてのキーについて、最も使用頻度の低いキーを削除します)
allkeys-random: データセットからのデータ削除を任意に選択します (キーをランダムに削除します)
noenviction: データの削除を禁止します (エラーが報告されるまで削除しません)満席の場合）

要約する

1. 災害復旧の概念

自然災害や機器の故障、人的操作による被害などの災害が発生した場合に、本番システムのデータの損失を最小限に抑えながら、サバイバルシステムの業務の継続的な稼働を維持することです。

2. Redisの永続化方法

RDB持久化：定时把redis内存中的数据进行快照和压缩保存
		  RDB保存的文件占用空间小，网络传输快，恢复速度比AoF快，但兼容性较差
          RDB持久化期间，在fork子进程时会阻塞父进程，由于是定时持久化，实时性不如AOF
AOF持久化： 以追加的方式将redis写操作的命令记录到文件中，实时性比RDB好
          支持秒级持久化，兼容性较好，缺点持久化文件占用空间较大，恢复速度较慢，对IO性能消耗较大AOF文件重写期间，在fork子进程时会阻塞父进程，且对IO性能消耗更大

3. RDBとAOFの違い

RDB：是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，
     先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
 
AOF：是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，
     可以打开文件看到详细的操作记录。