分散Redisディープアドベンチャー-Sentinel

1 つのマスターと 1 つのスレーブ、または 1 つのマスターと複数のスレーブの構造では、マスター サーバーに障害が発生すると、クラスター全体が使用できなくなり、単一ポイントの問題が解決されないことを想像してください。 Redis は Sentinel を使用してこの問題を解決し、クラスターの高可用性を確保します。

[[271307]]

クラスターの高可用性を確保する方法

クラスターの高可用性を確保するには、次の機能が必要です。

• サーバーの状態を監視し、メインサーバーが利用できないときにすぐに知ることができます。
• マスターサーバーが利用できない場合は、元のマスターサーバーを置き換えるために最も適切なスレーブサーバーを選択します。
• 同時に同じデータを保存するマスターサーバーは1つだけです

上記の機能を実現するには、監視サーバーを使用してRedisを監視するのが最も直感的な方法です。

サーバーのステータス。

監視サーバーとマスタースレーブサーバーの間でハートビート接続が維持されます。マスター サーバーからのハートビートが一定時間受信されない場合、マスター サーバーはオフラインとしてマークされ、その後、スレーブ サーバーにオンラインになってマスター サーバーになるように通知されます。

元のマスター サーバーがオンラインになると、監視サーバーはそれをスレーブ サーバーに変換します。

上記のプロセスは、クラスターの高可用性の問題を解決しているように見えますが、何かが間違っているようです。監視サーバーに問題がある場合はどうなるでしょうか?マスター サーバーが使用できない場合に引き継ぐスレーブ監視サーバーを追加できます。

しかし、問題は誰が「監視サーバー」を監視するのかということです。それはこれからの世代にも永遠に続くでしょう。 。

疑問を脇に置いて、Redis Sentinelクラスタの実装を見てみましょう。

センチネル

前のセクションの考え方と同様に、Redis は追加の Sentinel サーバーを追加してデータ サーバーを監視します。 Sentinel はすべてのマスター サーバーとスレーブ サーバーとの接続を維持し、サーバーの状態を監視し、サーバーにコマンドを発行します。

Sentinel 自体は、特殊な状態の Redis サーバーです。コマンドを開始します:

redis-server /xxx/sentinel.conf --sentinel、sentinel モードでの起動プロセスは通常の redis サーバーの起動プロセスとは異なります。たとえば、RDB ファイルや AOF ファイルは読み込まれず、ビジネス データ自体は保存されません。

プライマリサーバーとの接続を確立する

Sentinel が起動すると、構成ファイルで指定されたすべてのマスター サーバーとの 2 つの接続が確立されます。1 つはコマンド接続で、もう 1 つはサブスクリプション接続です。

コマンド接続は、サーバーにコマンドを送信するために使用されます。

サブスクリプション接続は、サーバーの _sentinel_:hello チャネルをサブスクライブしてその他の Sentinel 情報を取得するために使用されます。これについては、以下で詳しく説明します。

プライマリサーバー情報を取得する

Sentinel は、一定の頻度でマスター サーバーに Info コマンドを送信し、サーバー ID などのマスター サーバー自身の情報や、IP やポートなどの対応するスレーブ サーバーの情報を取得します。 Sentinel は、info コマンドによって返された情報に基づいて保存されているサーバー情報を更新し、スレーブ サーバーとの接続を確立します。

サーバーから情報を取得する

マスター サーバーとのやり取りと同様に、Sentinel は、スレーブ サーバー ID、スレーブ サーバーとマスター サーバー間の接続状態、スレーブ サーバーの優先度、スレーブ サーバーのレプリケーション オフセットなど、スレーブ サーバー情報を一定の頻度で Info コマンドを通じて取得します。

サーバーにメッセージを登録して公開する

クラスターの高可用性を確保する方法に関するセクションでは、「監視サーバーの高可用性を確保するにはどうすればよいか」という疑問が残ります。ここで簡単な答えを出すことができます。監視サーバー クラスター (つまり、Sentinel クラスター) を使用するのです。これをどのように実現するか、また監視サーバーの一貫性をどのように確保するかについては、現時点では議論されていません。高可用性を確保するには、複数の Sentinel を使用する必要があることを覚えておく必要があります。センチネルは他のセンチネルをどのように認識するのでしょうか?

前述したように、Sentinel がサーバーとの接続を確立すると、2 つの接続が確立されます。そのうちの 1 つはサブスクリプション接続です。 Sentinel は、サブスクリプション接続を介して _sentinel_:hello チャネルに定期的にメッセージを送信します (Redis のパブリッシュおよびサブスクライブ機能に精通していない場合は、これについて学習してください)。これには次のものが含まれます。

• IP アドレス、ポート番号、構成エポック (下記参照) など、Sentinel 自体に関する情報。
• Sentinel によって監視されるマスター サーバーに関する情報 (IP、ポート、構成エポック (下記参照) など)。

同時に、Sentinel は _sentinel_:hello チャネルのメッセージもサブスクライブします。つまり、Sentinel はこのチャネルにメッセージを公開し、このチャネルからのメッセージをサブスクライブします。

Sentinel には、同じマスター サーバーを監視する他のすべての Sentinel サーバーを格納する辞書オブジェクト sentinels があります。 Sentinel が _sentinel_:hello チャネルからメッセージを受信すると、まずそのメッセージが自分自身から送信されたものかどうかを比較します。もしそうなら、無視されます。それ以外の場合は、センチネル内のコンテンツが更新され、新しいセンチネルへの接続が確立されます。

主観的なオフライン

デフォルトでは、Sentinel は接続されているすべてのサーバー (マスター サーバー、スレーブ サーバー、Sentinel サーバー) に 1 秒ごとに PING コマンドを送信します。 down-after-milliseconds 以内に有効な応答が受信されない場合、Sentinel はサーバーを主観的にオフラインとしてマークします。これは、Sentinel がサーバーがオフラインであると認識していることを意味します。異なる Sentinel の down-after-milliseconds は異なる場合があることに注意してください。

オフラインでの目標

サーバーが本当にオフラインであることを確認するために、Sentinel がサーバーを主観的にオフラインとしてマークすると、Sentinel is-master-down-by-addr コマンドが他の Sentinel インスタンスに送信されます。コマンドを受信した Sentinel インスタンスは、マスター サーバーのステータスを応答し、Sentinel とマスター サーバーの接続ステータスを示します。

Sentinel は、送信されたすべての Sentinel is-master-down-by-addr コマンドに対する応答と、マスター サーバーをオフラインにすることに同意したユーザーの数をカウントします。数が特定のしきい値を超えると、マスター サーバーは客観的にオフラインとしてマークされます。

センチネルリーダーの選出

Sentinel がプライマリ サーバーを客観的にオフラインとしてマークすると、サーバーを監視している Sentinel は Raft アルゴリズムを介してネゴシエートし、主要な Sentinel を選出します。

まず Raft アルゴリズムの基礎を読んでから、次の内容を読むことをお勧めします。

ルール：

すべてのセンチネルはリーダーセンチネルになる可能性を秘めている

各選挙後、リーダーセンチネルが選出されたかどうかに関係なく、構成エポックは+1になります。

ある時代では、各センチネルは投票する機会があり、

他のユーザーに投票を依頼するセンチネルをソース センチネルと呼び、投票を依頼されるセンチネルをターゲット センチネルと呼びます。

マスターサーバーが客観的にオフラインとしてマークされており、他のセンチネルから投票を求められていないことを発見した各センチネルは、他のセンチネルに自分自身をヘッドとして設定するように依頼します。

ターゲット Sentinel が構成エポックで Sentinel (またはそれ自体) に投票すると、投票を必要とする後続のコマンドはすべて拒否されます。

ターゲット Sentinel は、投票を要求するコマンドに対して、選出した Sentinel の ID と現在の構成エポックで応答します。

投票を要求する応答を受信した後、ソース Sentinel は、応答の構成エポックが自身のものと同じである場合、ターゲット Sentinel によって選出されたヘッド Sentinel が自分自身であるかどうかを確認します。

センチネルがリーダーセンチネルとして設定された場合は、リーダーセンチネルと呼ばれます。

構成エポックでは 1 つのヘッドのみが選択されます (ヘッドにはサポートの半分以上が必要であるため)

指定された時間内にリーダーが選出されない場合は、しばらくしてから別の選挙が行われます（構成エポックは+1になります）

この記事の冒頭で、Redis サーバーの高可用性を確保する方法について提起した質問を覚えていますか?

答えは、複数の Sentinel サーバーを使用し、Raft コンセンサス アルゴリズムを使用してクラスターの高可用性を確保することです。 Sentinel サーバー上のノードの半分以上が正常であれば、クラスターは利用可能です。

フェイルオーバー

リーダー Sentinel はフェイルオーバーするために次の 3 つの手順を実行します。

1. オフラインマスターサーバーのスレーブサーバーの1つを新しいマスターサーバーとして選択します。

2. 他のスレーブサーバーのマスターサーバーを新しいサーバーに設定する

3. オフライン マスター サーバーの役割をスレーブ サーバーに変更し、そのマスター サーバーを新しいサーバーに設定します。サーバーがオンラインに戻ると、スレーブ サーバーとして動作し続けます。

最初のステップで新しいプライマリ サーバーを選択するためのルールは次のとおりです。

1. オフラインのスレーブサーバーをすべて除外する

2. 過去5秒間にSentinelコマンドに応答しなかったスレーブサーバーを除外する

3. 元のマスターサーバーから切断されてからdown-after-milliseconds*10以上経過したスレーブサーバーを除外する

4. サーバーから優先度順に並べ替え、優先度が最も高いものを選択します。

5. 同じ優先度のスレーブ サーバーが複数ある場合は、レプリケーション オフセットが最も大きいスレーブ サーバーが選択されます。

6. 前の手順で複数のサーバーがある場合は、IDが最も小さいサーバーを選択します。