Redis で高可用性と永続性を構成する方法

1. Redis 高可用性

1. Redis 高可用性の概要

Web サーバーでは、高可用性とはサーバーが稼働している時間を指します。正常にアクセスできる状態であり、正常なサービス（99.9％、99.99％、99.999％など）を提供できる時間を測定基準とします。 [関連する推奨事項: Redis ビデオ チュートリアル]

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

2. Redis の高可用性戦略

Redis では、高可用性を実現するためのテクノロジーには、主に永続化、マスター/スレーブ分離、センチネル、クラスターが含まれます。

#高可用性戦略説明永続性マスター スレーブ レプリケーションSentinelクラスター

2. Redis の永続化

1. Redis の永続化機能

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

2. Redis 永続化の 2 つの方法

• RDB 永続化
  原理は、メモリ内の Redis のデータベース レコードを定期的にディスクに保存することです。

• AOF 永続性 (ファイルの追加のみ)
  原則は、MySQL のバイナリログと同様に、Redis 操作ログを追加方式でファイルに書き込むことです。
  AOF 永続性はリアルタイム パフォーマンスが優れているため、つまり、プロセスが予期せず終了した場合に失われるデータが少ないため、現在 AOF が主流の永続化方法ですが、RDB 永続性も依然としてその地位を占めています。

3. RDB 永続性

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

3.1 トリガー条件

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

3.1.1 手動トリガー

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

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

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

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

3.1.2 自動トリガー

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

#3.2 設定方法

• 設定ファイルの変更による設定: save m n

• Automatically最も一般的なトリガーは、構成ファイルで save m n を渡すことです。これは、m 秒以内に n 個の変更が発生したときに bgsave がトリガーされるように指定します。

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

3.3 その他の自動トリガー メカニズム

save m n に加えて、bgsave:

# をトリガーする他の状況がいくつかあります。 ## マスター/スレーブ レプリケーション シナリオでは、スレーブ ノードがフル コピー操作を実行すると、マスター ノードは bgsave コマンドを実行し、rdb ファイルをスレーブ ノードに送信します。
shutdownコマンドを実行すると、自動的にrdb永続化が行われます。
3.4 実行プロセス

Redis 親プロセスは、まず、現在 save または bgsave を実行しているかどうかを判断します。 /bgrewriteaof の子プロセスが実行中の場合、bgsave コマンドは直接戻ります。 bgsave/bgrewriteaof のサブプロセスは、主にパフォーマンス上の考慮事項により同時に実行できません。2 つの同時サブプロセスが同時に大量のディスク書き込み操作を実行するため、重大なパフォーマンス上の問題が発生する可能性があります。
子プロセスの作成時に、親プロセスがフォーク操作を実行したため、親プロセスがブロックされ、この間、Redis はクライアントからのコマンドを実行できませんでした。

• #親プロセスがフォークすると、bgsave コマンドは「バックグラウンド保存が開始されました」というメッセージを返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります

• 子プロセスは RDB ファイルを作成し、親プロセスのメモリ スナップショットに基づいて一時スナップショット ファイルを生成します。完了後、元のファイルはアトミックに置き換えられます。子プロセスは親プロセスに完了を示すシグナルを送信し、親プロセスは統計情報を更新します。

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

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

4. AOF 永続性

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

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

4.1 开启 AOF

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置

[root@localhost ~]# vim /etc/redis/6379.conf ##700行，修改，开启AOFappendonly yes##704行，指定AOF文件名称appendfilename "appendonly.aof"##796行，是否忽略最后一条可能存在问题的指令aof-load-truncated yes[root@localhost ~]# /etc/init.d/redis_6379 restartStopping ...
Redis stopped
Starting Redis server...

4.2 执行流程

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。

AOF的执行流程包括：

• 命令追加（append）：将Redis的写命令追加到缓冲区aof_buf；

• 根据不同的同步策略，把aof_buf中的内容写入硬盘，并实现文件同步

• 文件重写（rewrite）：定期重写AOF文件，达到压缩的目的。

4.2.1 命令追加（append）

Redis先将命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO称为Redis负载的瓶颈。

命令追加的格式是Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单、避免二次开销等优点。在AOF文件中，除了用于指定数据库的select命令（如select 0为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。

4.2.2 文件写入（write）和文件同步（sync）

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write和fsync函数，说明如下：
为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

4.2.3 三种同步方式

AOF缓存区的同步文件策略存在三种同步方式，通过对/etc/redis/6379.conf的729行的修改进行配置。

4.2.3.1 appendfsync always

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

4.2.3.2 appendfsync no

命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负载，通常同步周期为30秒。文件同步时间不可预测，并且缓冲区中的数据会堆积很多，导致数据安全性无法保障。

4.2.3.3 appendfsync everysec（推荐）

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

4.2.4 文件重写（rewrite）

随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。
文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作。
关于文件重写需要注意的另一点是：对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些现实中，会关闭自动的文件重写，然后定时任务在每天的某一时刻定时执行。

4.2.4.1 具有压缩功能的原因

文件重写之所以能够压缩AOF文件，原因在于：

• 过期的数据不再写入文件。

• 无效的命令不再写入文件：如有些数据被重复设置（set mykey v1,set mykey v2）、有些数据被删除了（set myset v1,del myset）等。

• 多条命令可以合并为一个：如sadd myset v1,sadd myset v2,sadd myset v3可以合并为sadd myset v1 v2 v3。

通过上述原因可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。

4.2.4.2 文件重写的触发

文件重写分为手动触发和自动触发：

• 手動トリガー: bfrewriteaof コマンドを直接呼び出します。このコマンドの実行は、bgsave に似ています。どちらのフォーク プロセスも特定の作業を実行し、フォーク時にのみブロックされます。

• 自動トリガー: auto-aof-rewrite-min-size オプションと auto-aof-rewrite-percentage オプションを設定して、bgrewriteaof を自動的に実行します。 auto-aof-rewrite-min-size と auto-aof-rewrite-percentage の 2 つのオプションが同時に満たされた場合にのみ、AOF の書き換え、つまり bgrewriteaof 操作が自動的にトリガーされます。

#自動的にトリガーされる構成は、/etc/redis/6379.conf

• auto の 771 行目と 772 行目にあります。 -aof-rewrite-percentage 100

  現在の AOF ファイル サイズ (つまり、aof_current_size) が最後のログ書き換え時に AOF ファイル サイズ (aof_base_size) の 2 倍になった場合、bgrewriteaof 操作が発生します
  

# # auto-aof-rewrite-min-size 64mb
• ファイル サイズが小さいために頻繁に bgrewriteaof

  
  

が実行されるのを避けるため、現在の AOF ファイルに対して bgrewriteaof コマンドを実行するための最小値。 4.2.4.3 ファイルの書き換えプロセス

ファイルの書き換えプロセスは次のとおりです:

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

ファイルの書き換えプロセスに関しては、特別な注意が必要な 2 つの点があります。

書き換えは、親プロセス子プロセスの書き換え中に Redis によって実行される書き込みコマンドは、新しい AOF ファイルに追加する必要があるため、Redis では aof_rewrite_buf キャッシュを導入しています (例:
4.3 Loading at) startup
AOF がオンになっている場合、Redis は起動時に最初に AOF ファイルをロードしてデータを復元します。AOF がオフの場合にのみ、RDB ファイルがロードされてデータを復元します。 。

AOF がオンで AOF ファイルが存在しない場合、RDB ファイルは存在してもロードされません。
Redis が AOF ファイルをロードすると、AOF ファイルが検証されます。ファイルが破損している場合は、ログにエラーが出力され、Redis は起動できません。ただし、AOF ファイルの終わりが不完全で (突然のマシンのダウンタイムにより、ファイルの終わりが不完全になる可能性があります)、aof_load_truncated パラメーターがオンになっている場合、警告がログに出力され、Redis は無視します。 AOF ファイルの最後に到達し、正常に開始します。 aof_load_truncated パラメータはデフォルトで有効になっています。
5. RDB と AOF の長所と短所

• RDB の永続性

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

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

RDB の永続化では、bgsave がフォーク操作を実行するときに Redis のメインプロセスがブロックされる一方で、ハードディスクにデータを書き込むサブプロセスも IO プレッシャーをもたらします。

AOF 永続性

RDB 永続性と同様に、AOF の優先順位は、第 2 レベルの永続性と良好な互換性をサポートすることです。欠点は、ファイルが大きく、回復速度が遅く、パフォーマンスに大きな影響を与えます。

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

跟RDB的bgsave類似，AOF檔的重寫也會面臨fork阻塞和子程序IO負載的問題。 AOF向硬碟中寫入資料的頻率更高，相較之下，會對Redis主流程的效能產生更大的影響。

一般來說，建議關閉AOF的自動重寫功能，並在重寫操作設定計劃任務，放在凌晨業務量低的時候進行，以降低AOF對主進程性能的影響以及IO的讀寫壓力。

永続化は最も単純な高可用性方法です (高可用性方法として分類されない場合もあります)。その主な機能はデータのバックアップ、つまり、プロセスの終了によってデータが失われないようにデータをハードディスクに保存することです。 。
マスター スレーブ レプリケーションは高可用性 Redis の基礎であり、Sentinel と Cluster はどちらもマスター スレーブ レプリケーションに基づいて高可用性を実現します。マスター/スレーブ レプリケーションでは、主にデータのマルチマシン バックアップのほか、読み取り操作の負荷分散と単純な障害回復が実装されます。欠点: 障害回復は自動化できず、書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。
Sentinel は、マスター/スレーブ レプリケーションに基づいて、自動障害回復を実装します。欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。
Redis は、クラスター化を通じて、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題を解決し、比較的完全な高パフォーマンスを実現します。可用性ソリューション。

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