Redis における高可用性と永続性の詳細な説明

この記事では、Redis の高可用性と永続性について説明し、永続化機能と Redis の 2 つのメソッド (RDB と AOF) について説明します。

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 コマンドは、RDB ファイルの作成を担当する子プロセスを fork() しますが、親プロセス (つまり、Redis メイン プロセス) はリクエストの処理を続行します。
• bgsave コマンドの実行中、fork 子プロセスのみがサーバーをブロックしますが、save コマンドに関しては、プロセス全体がサーバーをブロックします。そのため、save は基本的に放棄され、オンライン環境では保存を削除する必要があります。

3.1.2 自動トリガー

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

3.2 設定方法

• 設定ファイルの変更による設定: save m n
• 自動トリガーの最も一般的な状況は、設定ファイルに保存することです。 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 の親プロセスは、まず、現在保存を実行しているのか、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 の実行プロセスには次のものが含まれます:

• Command append (append): Redis write コマンドをバッファー aof_buf に追加します;
• ファイル書き込み (write) とファイル同期 (sync): さまざまな同期戦略に従って aof_buf を追加します内容は次のとおりです。ハードディスクに同期;
• ファイル書き換え (リライト): 圧縮の目的を達成するために、AOF ファイルを定期的に書き換えます。

4.2.1 コマンドの追加 (追加)

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

コマンドによって追加される形式は、Redis コマンドによって要求されたプロトコル形式であり、プレーン テキスト形式であり、優れた互換性、強力な可読性、容易な処理、簡単な操作、および二次的なオーバーヘッドの回避という利点があります。 。 AOFファイルでは、Redisが追加したデータベースを指定するselectコマンド（データベース番号0を選択する場合はselect 0など）を除き、その他はクライアントから送信されるwriteコマンドです。

4.2.2 ファイル書き込み (write) とファイル同期 (sync)

Redis は、オペレーティング システムの write および fsync 関数を含む、さまざまな AOF バッファ同期ファイル戦略を提供します。説明は次のとおりです。
ファイル書き込みの効率を向上させるために、最新のオペレーティング システムでは、ユーザーがファイルにデータを書き込むために書き込み関数を呼び出すと、通常、オペレーティング システムはデータをメモリ バッファに一時的に保存します。バッファー内のデータが実際にハードディスクに書き込まれるのは、バッファーがいっぱいになるか、指定された制限時間を超えた場合のみです。このような操作により効率は向上しますが、セキュリティ上の問題も発生します。コンピュータがシャットダウンすると、メモリ バッファ内のデータが失われるため、システムは、オペレーティング システムに強制的に同期機能を提供する fsync や fdatasync などの同期機能も提供します。バッファ内のデータを直ちに転送します。データのセキュリティを確保するために、データはハードディスクに書き込まれます。

4.2.3 3 つの同期方法

AOF キャッシュ領域の同期ファイル戦略には 3 つの同期方法があり、/etc/redis/6379.conf の 729 行目を変更することで構成されます。 。

4.2.3.1 appendfsync always

コマンドが aof_buf に書き込まれた直後、AOF ファイルと同期するためにシステムの fsync 操作が呼び出され、fsync が完了するとスレッドが戻ります。この場合、すべての書き込みコマンドを AOF ファイルに同期する必要があり、ハードディスク IO がパフォーマンスのボトルネックになります。Redis は約数百 TPS 書き込みしかサポートできず、たとえソリッド ステート ドライブ ( SSD) が使用されると、1 秒あたり数万のコマンドしか処理できず、SSD の寿命が大幅に短くなります。

4.2.3.2 appendfsync no

コマンドが aof_buf に書き込まれた後、システム書き込み操作が呼び出され、AOF ファイルの fsync 同期は実行されません。同期はオペレーティング システムによってロードされます。同期期間は通常 30 秒です。この場合、ファイルの同期時間が制御できなくなり、バッファに大量のデータが蓄積され、データのセキュリティが保証されなくなります。

4.2.3.3 appendfsync eachsec (推奨)

コマンドが aof_buf に書き込まれた後、システム書き込み操作が呼び出されます。書き込みが完了すると、スレッドは fsync 同期ファイル操作を返します。専用スレッドによって 1 秒に 1 回呼び出されます。 Everysec は、パフォーマンスとデータ セキュリティのバランスをとる、前述の 2 つの戦略の間の妥協案であり、Redis のデフォルト構成であり、推奨される構成です。

4.2.4 ファイルの書き換え (リライト)

時間の経過とともに、Redis サーバーはますます多くの書き込みコマンドを実行し、AOF ファイルはますます大きくなります。ファイルが大きいと、サーバーの通常の動作に影響を与えるだけでなく、データの回復に時間がかかりすぎる可能性があります。
ファイルの書き換えとは、AOF ファイルのサイズを減らすために AOF ファイルを定期的に書き換えることを指します。 AOF 再書き込みでは、Redis プロセス内のデータが書き込みコマンドに変換され、新しい AOF ファイルに同期されます。古い AOF ファイルに対して読み取りまたは書き込み操作は実行されないことに注意してください。
ファイルの書き換えに関するもう 1 つの注意点は、AOF 永続性の場合、ファイルの書き換えが強く推奨されていますが、必須ではありません。ファイルの書き換えがなくても、データは永続化され、Redis の起動時にインポートされて保存されます。現実には、ファイルの自動書き換えがオフになり、スケジュールされたタスクが毎日特定の時間に実行されます。

4.2.4.1 圧縮機能がある理由

ファイルの書き換えによって 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 は書き換え後に実行するコマンドが少ないため、ファイル書き換えによりファイルの占有領域が削減されるだけでなく、回復速度も向上することがわかります。

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 の 771 行目と 772 行目にあります。

• auto-aof-rewrite-パーセント 100
  現在の AOF ファイル サイズ (aof_current_size) が、最後のログが書き換えられたときの AOF ファイル サイズ (aof_base_size) の 2 倍である場合、bgrewriteaof 操作が発生します。
• auto-aof-rewrite-min-size 64mb
  Redis 起動時のファイル サイズが小さいために頻繁に bgrewriteaof が実行されるのを避けるため、現在の AOF ファイルに対して bgrewriteaof コマンドを実行するための最小値
##4.2.4.3 ファイル書き換えプロセス

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

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 つの点があります。

書き換えは、子プロセスをフォークする親プロセスによって実行されます。 process

書き換え中に Redis によって実行される書き込みコマンドは、新しい AOF ファイルに追加する必要があるため、Redis では例として aof_rewrite_buf キャッシュを導入します
• 4.3 起動時の読み込み

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

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

一般的には、AOF の自動書き換え機能をオフにし、書き換え操作中にスケジュールされたタスクを設定し、業務量が少ない早朝に実行することを推奨します。これにより、影響を軽減できます。メインプロセスのパフォーマンスと IO の読み取りおよび書き込み圧力に関する AOF。

プログラミング関連の知識について詳しくは、プログラミング入門をご覧ください。 ！

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

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