Redis の高可用性を実現する 2 つの実装ソリューションとは何ですか?-Redis-php.cn

高可用性 (HA) を実現するために、Redis では次の 2 つの方法が使用されます:

マスター/スレーブレプリケーションデータ。
センチネルを使用してデータノードの動作を監視します。マスターノードで問題が発生すると、サービスはスレーブノードの最上位で継続されます。

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

Redis では、マスターノードとスレーブノード間のデータレプリケーションは、完全レプリケーションと部分レプリケーションに分類できます。

旧バージョンのフルコピー機能の実装

フルコピーはsnycコマンドを使用して実装します。

From サーバーは同期コマンドをメインサーバーに送信します。

sync コマンドを受信した後、マスターサーバーは bgsave コマンドを呼び出して ***rdb ファイルを生成し、このファイルをスレーブサーバーと同期します。サーバーがrdbファイルをロードすると、メインサーバーがbgsaveコマンドを実行したときと同じ状態になります。
マスターサーバーはコマンドバッファに保存された書き込みコマンドをスレーブサーバーに同期し、スレーブサーバーはこれらのコマンドを実行することで、スレーブサーバーのステータスが現在のステータスと一致するようにします。マスターサーバーのステータス。
旧バージョンのフルコピー機能の最大の問題点は、スレーブサーバーを切断して再接続すると、スレーブサーバーにデータが存在していてもフルコピーが行われていないことです。これは効率が非常に低いため、Redis の新しいバージョンではこの部分が改善されています。

新バージョンでの完全コピー機能の実装

Redis の最新バージョンでは、sync コマンドの代わりに psync コマンドが使用されます。完全な同期だけでなく、部分的な同期も可能です。

コピーオフセット

レプリケーションを実行する両方の当事者 (マスターサーバーとスレーブサーバー) は、それぞれレプリケーションオフセットを維持します:

マスターサーバーが N バイトのデータをスレーブサーバーに同期するたびに、マスターサーバー自身のレプリケーションオフセット N が変更されます。

スレーブサーバーがマスターサーバーから N バイトのデータを同期するたびに、スレーブサーバーは自身のレプリケーションオフセット N を変更します。

メインサーバーは、レプリケーションバックログバッファとして固定長の先入れ先出しキューを内部的に維持します。デフォルトのサイズは 1MB です。

マスターサーバーがコマンドの伝達を実行すると、書き込みコマンドがスレーブサーバーに同期されるだけでなく、書き込みコマンドがレプリケーションバックログバッファーにも書き込まれます。

サーバー実行 ID

各 Redis サーバーには実行 ID があります。実行 ID はサーバーの起動時に自動的に生成されます。メインサーバーは独自の実行 ID を送信します。 ID スレーブサーバーに送信され、スレーブサーバーはマスターサーバーの実行 ID を保存します。

スレーブサーバー Redis が切断され、再接続された後に同期する場合、同期の進行状況は実行 ID に基づいて判断されます。

マスターサーバーの実行 ID が保存されている場合、同期の進行状況は実行 ID に基づいて判断されます。スレーブサーバー現在のメインサーバーの実行 ID と一致する場合、今回切断されて再接続されたメインサーバーは以前に複製されたメインサーバーであるとみなされ、メインサーバーは引き続き部分同期操作を試行できます。

それ以外の場合、ID を実行している 2 つのメインサーバーが異なる場合、完全な同期プロセスは完了したとみなされます。

これまでの準備ができたら、psync コマンドプロセスの分析を開始しましょう:

スレーブサーバーが以前にマスターサーバーをレプリケートしたことがない場合、または、slaveof no one コマンドが以前に実行されたことがない場合、スレーブサーバーは psync? -1 コマンドをマスターサーバーに送信して、マスターサーバーにデータを完全に同期するよう要求します。。

それ以外の場合、スレーブサーバーが以前に一部のデータを同期している場合、スレーブサーバーは pync コマンドをマスターサーバーに送信します (runid が最後のマスター)。サーバーの実行 ID、オフセットはサーバーからの現在のレプリケーションオフセットです。
最初の 2 つのケースでメインサーバーが psync コマンドを受信した後、次の 3 つの可能性が発生します。

メインサーバーは fullresync を返します。応答は、マスターサーバーがスレーブサーバーとの完全なデータ同期を必要とすることを示します。メインサーバーの現在実行中の ID は runid で、レプリケーションのオフセットは offset です。

マスターサーバーが continue で応答した場合、マスターサーバーとスレーブサーバーが部分的なデータ同期操作を実行中であり、スレーブサーバーからの欠落したデータを同期できることを意味します。
メインサーバーが -err で応答した場合、メインサーバーのバージョンが 2.8 未満であり、psync コマンドを認識できないことを意味します。このとき、スレーブサーバーは同期を送信します。コマンドをメインサーバーに送信し、全データを完全に実行します。

Redis はセンチネルメカニズムを使用して高可用性 (HA) を実現します。その一般的な動作原理は次のとおりです:

Redis は、一連のセンチネルノードを使用して、マスター/スレーブ Redis サービスの可用性を監視します。

Redis マスターノードに障害が発生したことが判明すると、センチネルノードがリーダーとして選出されます。
Sentinel*** は、外部関係者にサービスを提供する新しいプライマリ Redis ノードとして、残りのスレーブ Redis ノードから Redis ノードを選択します。
上記では、Redis ノードを 2 つのカテゴリに分類しています:

Sentinel ノード (センチネル): ノードの動作の監視を担当します。
データノード: 通常はクライアントのリクエストを処理する Redis ノードで、マスターとスレーブに分かれています。

上記は一般的なプロセスですが、このプロセスでは次の問題を解決する必要があります:

Redis データノードを監視するにはどうすればよいですか?
Redis データノードが無効かどうかを確認するにはどうすればよいですか?
センチネル *** ノードを選択するにはどうすればよいですか?
センチネルノードが新しいプライマリ Redis ノードを選択する根拠は何ですか?

これらの質問に 1 つずつ答えてみましょう。

3 つの監視タスク

センチネルノードは、スケジュールされた 3 つの監視タスクを通じて Redis データノードのサービスの可用性を監視します。

info コマンド

10 秒ごとに、各センチネルノードはマスターおよびスレーブ Redis データノードに info コマンドを送信して、新しいトポロジ情報を取得します。

Redis トポロジ情報には次のものが含まれます:

このノードの役割: マスターまたはスレーブ。
マスターノードとスレーブノードのアドレスとポート情報。

このように、センチネルノードは info コマンドからスレーブノードの情報を自動的に取得できるため、明示的な設定を行わなくても、後から追加されたスレーブノードの情報を自動的に検知することができます。

情報を sentinel:hello チャネルに同期する

各センチネルノードは 2 秒ごとに、マスターを取得するために Redis データノードの __sentinel__:hello チャネルに同期します。他のセンチネルノードもこのチャネルに加入しているため、この操作によりマスターノードとセンチネルノードに関する情報をセンチネルノード間で実際に交換できます。

この操作では実際に 2 つのことを実行します。 * 新しいセンチネルノードの検出: 新しいセンチネルノードが参加すると、この時点で新しいセンチネルノードの情報が保存され、その後センチネルノードとの接続が確立されます。 . .次のように書き換えます。 * 後でマスターノードがオフラインであるかどうかを客観的に判断できるように、マスターノードのステータス情報を交換します。

データノードでハートビート検出を実行する

各センチネルノードは 1 秒ごとに、ハートビート検出のためにマスターデータノードとスレーブデータノードおよび他のセンチネルノードに ping コマンドを送信します。このハートビートの検出は、データノードがオフラインであるというその後の主観的な判断の基礎となります。

主観的オフラインと客観的オフライン

主観的オフライン

上記 3 つの監視タスクの 3 番目ハートビートタスクの検出 (次の場合)設定されたミリ秒後のダウン後に有効な応答が受信されない場合、データノードは「主観的にオフライン (sdown)」とみなされます。

なぜ「主観オフライン」と呼ばれるのでしょうか？分散システムでは複数のマシンが連携して動作するため、ネットワーク内でさまざまな状況が発生する可能性があります。データノードがオフラインであるとみなすには、1 つのノードだけの判断だけでは十分ではありません。これには、その後の「客観的なオフライン」プロセスが必要です。。

客観的オフライン

センチネルノードがマスターノードが主観的にオフラインであると考える場合、センチネルノードは「sentinel is-master-down-by addr」を渡す必要があります。 " コマンド他のセンチネルノードにマスターノードがオフラインかどうかを尋ねます。半数以上のセンチネルノードがオフラインであると回答した場合、マスターノードは「客観的にオフライン」であるとみなされます。

センチネルの選出***

マスターノードが客観的にオフラインになった場合、その後の選挙を完了するにはセンチネルノードをセンチネルとして選出する必要があります***新しいものマスターノードの仕事。

この選挙の一般的な考え方は次のとおりです:

各センチネルノードは、「sentinel is-master-down-by addr」を送信することでセンチネルノードになることを申請します。 " コマンドを他のセンチネルノードに送信します。sentinel***。
各センチネルノードが「sentinel is-master-down-by addr」コマンドを受信すると、*** ノードにのみ投票できます。他のノードのこのコマンドは、拒否される。
センチネルノードが承認投票の過半数を獲得した場合、そのノードはセンチネル***になります。
最初の 3 つのステップで一定期間内にセンチネル*** が選択されなかった場合、次の選挙が再び開始されます。

ご覧のとおり、*** を選出するプロセスは、raft のリーダーを選出するプロセスと非常によく似ています。

新しいマスターノードの選択

残りの Redis スレーブノードの中から、次の順序で新しいマスターノードを選択します。

「異常な」データノードをフィルタリングして除外します。たとえば、主観的にオフラインまたは切断されているスレーブノード、センチネルノードの ping コマンドに 5 秒以内に応答しなかったノード、マスターノードとの接続が失われたスレーブノードなどです。
スレーブ優先度***のスレーブノードが存在する場合はそのノードを返却し、存在しない場合は以降の処理を継続します。
コピーオフセット *** を持つスレーブノードを選択します。これは、このスレーブノード上のデータが最も完全であることを意味します。存在する場合は、存在しない場合は戻ります。後続のプロセスを続行します。
この時点では、残りのすべてのスレーブノードのステータスは同じなので、最小の runid を持つスレーブノードを選択します。