分散型Redis深さ冒険-sentinel

分散型Redis深さ冒険-sentinel
詳細については、個人ブログを参照してください.https://github.com/farmerjohngit/myblog
本文は分布式Redis深さ冒険シリーズの第2編で,主な内容はRedisのSentine機能である.
前の記事では、Redisのプライマリ・スレーブ・サーバ間でデータがどのように同期されているかについて説明しました.考えてみてください.プライマリ・サーバが停止すると、クラスタ全体が使用できなくなり、単一の問題は解決されません.RedisはCentinelを用いてこの問題を解決し,クラスタの高可用性を保障する.
クラスタの高可用性を保証する方法
クラスタの高可用性を確保するには、次の機能が必要です.

は、サーバの状態を監視することができ、プライマリサーバが使用できない場合、

をタイムリーに発見することができる.

プライマリサーバが使用できない場合、既存のプライマリサーバ

の代わりに最適なサーバを選択する.

同じデータを格納プライマリサーバは、同じ時刻に1台の

しかない.
このような機能を実現するには、Redisを監視するために1台の監視サーバを使用することが最も直感的です.
サーバーのステータス.
image
モニタリングサーバとプライマリ・スレーブ・サーバ間でハートビート接続が維持され、一定時間を超えてプライマリ・サーバのハートビートが受信されない場合、プライマリ・サーバはオフラインとマークされ、サーバからプライマリ・サーバにオンラインになることを通知します.
image
元のプライマリ・サーバがオンラインになると、モニタ・サーバはサーバから変換されます.
image
上記の手順では、クラスタの高可用性の問題が解決されたようですが、監視サーバに問題が発生した場合はどうすればいいのでしょうか.プライマリ・サーバが使用できない場合に、セカンダリ・モニタ・サーバを追加できます.
image
しかし、問題は誰が「監視サーバー」を監視するのか.子も孫も尽きることがない.
まず疑問を置いて、まずRedis Sentineクラスタの実現を見てみましょう.
Sentinel
前節の考えと同様に、Redisは追加のSentineサーバを追加してデータサーバを監視し、Sentineはすべてのプライマリサーバとセカンダリサーバと接続を保存し、サーバのステータスを傍受し、サーバにコマンドを送信します.
image
Sentinel自体は特殊な状態のRedisサーバであり、起動コマンド:redis-server /xxx/sentinel.conf --sentinel、sentinelモードでの起動プロセスは通常のredis serverとは異なり、例えばRDBファイルやAOFファイルはロードされず、ビジネスデータも格納されない.
プライマリ・サーバへの接続
Centinelが起動すると、プロファイルに指定されているすべてのプライマリ・サーバに2つの接続が確立されます.1つはコマンド接続、1つはサブスクリプション接続です.
コマンド接続は、サーバにコマンドを送信するために使用されます.
サブスクリプション接続は、サーバをサブスクリプションするための_sentinel_:helloチャンネルであり、他のSentinal情報を取得するために使用され、以下で詳細に説明する.
プライマリ・サーバ情報の取得
Sentinalは、サーバidなどのプライマリサーバ自身の情報や、ipおよびportを含む対応するセカンダリサーバ情報を含むInfoコマンド取得情報を、一定の周波数でプライマリサーバに送信する.Sentinalはinfoコマンドから返された情報に基づいて自分が保存したサーバ情報を更新し、サーバから接続します.
サーバからの情報の取得
プライマリ・サーバとのインタラクションと同様に、Sentinalは、サーバIDから、サーバとプライマリ・サーバとの接続状態から、サーバの優先度から、サーバからのレプリケーション・オフセットなど、一定の頻度でサーバからの情報を取得します.
サーバへのメッセージの購読とパブリッシュ
クラスタの高可用性をどのように保障するかというセクションでは、監視サーバの高可用性をどのように保証するかという疑問が残されています.ここでは、まず、サーバクラスタ(つまりSentinalクラスタ)を監視する簡単な答えを出すことができます.どのように実現するか、どのように監視サーバの一貫性を保証するかはともかく、私たちはいくつかのSentine lで高可用性を保障する必要があることを覚えていれば、1つのSentine lはどのように他のSentine lを感知しているのだろうか.
前述したように、Sentinelはサーバとの接続を確立すると、サブスクリプション接続の1つである2つの接続を確立します.Centinelは定期的に購読接続を通じてInfoチャンネルにメッセージを送信します(Redisが購読機能を発表することをよく知らない学生は理解することができます).

Sentine自身の情報、例えばipアドレス、ポート番号、構成紀元(以下参照)などの

Sentinelが監視するプライマリサーバの情報は、ip、ポート、構成紀元(以下参照)などの

を含む.
また、Centinelは_sentinel_:helloチャンネルのメッセージ、すなわちCentinelがそのチャンネルにメッセージを発行し、そのチャンネルからメッセージを購読する.
image
Sentinelには、同じプライマリ・サーバを監視する他のすべてのSentinelサーバが保存されている辞書オブジェクト_sentinel_:helloがあり、sentinelsチャンネルからのメッセージを受信すると、メッセージを送信したのは自分ではないかと比較され、無視されると、_sentinel_:helloのコンテンツが更新され、新しいSentinelへの接続が確立されます.
主観的なラインオフ
Sentinalのデフォルトでは、接続が確立されたすべてのサーバ(プライマリサーバ、サーバ、Sentinalサーバ)に1秒に1回の頻度でsentinelsコマンドが送信されます.PING内で有効な返信が受信されない場合、Sentinalはそのサーバを主観的なオフラインとしてマークします.代表このSentinalは、このサーバがオフラインになったと考えています.なお、異なるSentielのdown-after-millisecondsは異なっていてもよい.
客観的ラインオフ
サーバが実際にオフラインになっていることを確認するために、Sentinelがあるサーバを主観的なオフラインとマークすると、down-after-millisecondsコマンドが他のSentinelインスタンスに送信され、このコマンドを受信したSentinelインスタンスはプライマリサーバの状態に戻り、プライマリ・サービスへの接続状況を表します.
Sentinalは、発行されたすべてのSentinel is-master-down-by-addrコマンドの返信を統計し、プライマリ・サーバのオフライン数を統計します.この数がしきい値を超えた場合、プライマリ・サーバは客観的なオフラインとしてマークされます.
選挙のリーダーシップ
Centinelがプライマリ・サーバを客観的なダウンラインとしてマークすると、そのサーバを監視する各CentinelはSentinel is-master-down-by-addrアルゴリズムによって交渉し、リーダーのCentinelを選出する.Raftアルゴリズムの基礎知識を見てから、以下を見ることをお勧めします.
ルール:

すべてのSentinelがリーダーになる可能性があるSentinelの資格

選挙のたびに、リーダーシップSentineが選出されるかどうかにかかわらず、配置紀元は+1

になる.

ある紀元の中で、すべてのSentine lはすべて投票の機会があります

他の人に自分の選挙を要求するSentinelをソースSentinelと呼び、投票を要求されたSentinelをターゲットSentinel

と呼ぶ

プライマリ・サーバが客観的なダウンラインとしてマークされ、他のSentinelに投票を要求されていないSentinelは、他のSentinelにヘッダ

に設定するように要求する.

ターゲットSentineは1つの構成紀元の中で、いったんあるSentine(それ自身かもしれない)に投票した後、後で受け取った投票を要求する命令に対して、

を拒否します.

ターゲットSentineは、投票を要求する命令に対して、自分の選挙のSentineのidおよび現在の構成紀元

に返信する.

ソースSentineは、投票を要求する返信を受信した後、返信の構成紀元が自分と同じであれば、ターゲットSentine選挙のヘッダSentineが自分の

であるかどうかを再検出する.

あるSentinelが半数以上のSentinelによってヘッダSentinelに設定されている場合、これをヘッダSentinel

と呼ぶ.

構成紀元は1つのヘッダのみを選択する(1つのヘッダは半数以上のサポートが必要であるため)

.

所与の時間内に、まだ選挙の先頭に立っていない場合は、しばらくして再選挙(構成紀元会+1)

.
Redisサーバの高可用性を保証する方法について、冒頭で述べた問題を覚えていますか?答えは、いくつかのCentinelサーバを使用して、Raftコンシステンシアルゴリズムによってクラスタの高可用性を保障し、Centinelサーバの半分以上のノードが正常であれば、クラスタは利用可能である.
フェイルオーバ
リーダーSentineは、次の3つのステップでフェイルオーバを行います.
1.ダウンラインしたプライマリ・サーバのすべてのスレーブ・サーバから、新しいプライマリ・サーバとして選択
2.他のスレーブサーバのプライマリサーバを新しいものに設定する
3.ラインオフされたプライマリ・サーバのroleをセカンダリ・サーバに変更し、プライマリ・サーバを新しいものに設定します.このサーバが再ラインアップされると、サーバの役割から作業が続行されます.
最初のステップで新しいプライマリ・サーバを選択するルールは、次のとおりです.
1.ダウンラインしたすべてのスレーブサーバをフィルタする
2.最近の5秒でSentineコマンドに返信しなかったスレーブサーバをフィルタリングする
3.元マスターサーバとの切断時間がdown-after-milliseconds*10を超えるスレーブサーバをフィルタリングする
4.サーバからの優先度に応じて並べ替え、最も優先度の高いものを選択
5.複数のスレーブサーバ優先度が同じである場合、レプリケーションオフセットが最も大きいものを選択します.
6.前のステップのサーバが複数ある場合は、idが最も小さいものを選択します.