分散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 と現在の構成エポックで応答します。