Zookeeper の選出アルゴリズムとスプリットブレイン問題の詳細な説明

ZKの紹介

ZK = 動物園の飼育係

ZK は、マイクロサービス ソリューションにおけるサービス登録と検出のコア環境であり、マイクロサービスの基礎となります。サービス登録および検出モジュールとして、ZK は唯一の製品ではありません。現在業界で認知されている他の製品には、Eureka と Consul があります。

[[284109]]

ここでは ZK についてのみ説明します。このツール自体は非常に小さく、zip パッケージはわずか数メガバイトです。インストールは非常に簡単で、クラスターの展開をサポートできます。

背景

クラスター環境における ZK リーダーとフォロワーの概念、およびノー​​ド異常が発生したときに ZK が直面する問題とその解決方法。 ZK 自体は Java で開発されており、Github でオープンソース化されていますが、公式ドキュメントには内部情報がほとんど記載されていません。散在するブログは数多くあり、その中には非常によく書かれたものもあります。

質問：

• Zookeeper の選挙アルゴリズムでは、通常のサービスを提供するには過半数の投票が必要です。この背後にあるロジックは何ですか?

ZK クラスターの単一ノード状態 (各ノードには 1 つの状態のみがあります) では、ZK の配置にはリーダー ノードがロード状態にあることが必要です。

• 探しています: リーダー ステータスを探しています。現在のクラスターにはリーダーがいないため、リーダー選出プロセスが開始されます。
• フォロー中: フォロワー状態。先行ノードからの同期とコマンドを受け入れます。
• leading: リーダー状態。
• 観察中: オブザーバー ステータス。現在のサーバーのテーブル名は observer です。

ZK投票処理戦略

投票情報には、選出されたリーダーの Serverid、Zxid、SelectionEpoch が含まれます。

• エポック判定、ロジックエポックと選択エポック判定: より大きい、より小さい、等しい。
• ZXID のチェックを優先します。 ZXID が大きいサーバーがリーダーとして優先されます。
• ZXID が同じ場合は、myid が比較されます。 myid が大きいサーバーがリーダー サーバーになります。

多数決選挙アルゴリズム

ZK には、LeaderElection、FastLeaderElection、AuthLeaderElection という 3 つの選出アルゴリズムがあります。FastLeaderElection と AuthLeaderElection は類似した選出アルゴリズムです。唯一の違いは、後者が認証情報を追加することです。FastLeaderElection は LeaderElection よりも効率的です。以降のバージョンでは FastLeaderElection のみが保持されます。

理解する：

クラスター環境で複数のノードが起動されると、ZK はまず複数のノードからリーダーとしてノードを選択し、それを Leading 状態にする必要があります。これには選出の問題があり、選出ルールは何ですか? 「多数決アルゴリズム」：投票で過半数の票を獲得したノードが勝利します。つまり、状態が「注目」から「リード」に変わり、より効率的になります。

このアイデアを説明するために 5 台のサーバーを使用しましょう。

サーバー 1 が起動しました。この時点では、起動されているサーバーはこれだけです。サーバー 1 が送信した投票は応答を受け取らなかったため、その選出ステータスは LOOKING 状態になっています。

サーバー 2 が起動し、最初に起動したサーバー 1 と通信して選出結果を交換します。どちらも履歴データを持っていないため、ID 値が大きいサーバー 2 が勝ちます。ただし、サーバーの半数以上 (この例では半数以上は 3) が選出に同意しないため、サーバー 1 と 2 は引き続き LOOKING 状態のままになります。

サーバー 3 が起動します。以前の理論によれば、3 つのサーバーがこれを選出しています。サーバー 3 はサーバー 1、2、3 の中でリーダーになるため、今回の選出のリーダーになります。

サーバー4が起動します。以前の分析によると、理論的にはサーバー4はサーバー1、2、3、4の中で最大になるはずです。しかし、すでに半数以上のサーバーがサーバー3を選択しているため、弟になる運命を受け入れるしかありません。

サーバー 5 は、サーバー 4 と同様に起動し、弟として機能します。

5 台のサーバーのうち 2 台 (3 台と 4 台) に障害が発生し、リーダーにも障害が発生したと仮定します。

リーダーとフォロワーの間でハートビート チェックが行われ、データの同期が必要です。リーダー ノードに障害が発生すると、Zookeeper クラスター全体が外部サービスを一時停止し、新しいリーダー選出ラウンドに入ります。

1) サーバー 1、2、5 はリーダーとの連絡が途絶えたことを発見し、ステータスが「監視中」に変わり、新しい投票を開始します。 2) サーバー 1、2、5 は投票を開始し、投票情報をブロードキャストし、自身のエポックが自動的に増加します。 3) サーバー 1、2、5 は投票を処理し、リーダーを決定し、個別にブロードキャストします。 4) 投票処理ロジックに従って、1 つのサーバーが選択されます (2 票で過半数の票を獲得)。 5) 各サーバーは再びリーダーとフォロワーのステータスに変わります。 6) サービスが再び提供されます。

スプリットブレイン問題

スプリットブレイン問題は、クラスター内のリーダーが死亡し、フォロワーが新しいリーダーを選出し、元のリーダーが復活したときに発生します。ZK の多数決メカニズムでは、一定数のマシンが失われても通常のサービスを提供できるため、リーダーの死亡判定が一貫していないと、複数のリーダーが出現します。

プラン：

ZK の多数決メカニズムにより、スプリットブレイン状況の発生もある程度軽減されます。少なくとも、同時に 3 人のリーダーが存在することはありません。 ZK のエポック機構 (クロック) は、選出ごとに +1 ずつ増加します。通信を行う際には、エポックが一貫しているかどうかを判断する必要があります。自分のエポックより小さい場合は破棄され、自分のエポックより大きい場合はリセットされ、等しい場合は選出されます。

誘導

日常的な ZK の運用とメンテナンスでは、上記のシナリオが極端な場合、特にブレイン スプリットの発生に該当する場合に注意する必要があります。次のものを使用できます。

多数決戦略における展開原則:

1. サーバー クラスターは、3、5、7 などの奇数で展開する必要があります。奇数は、リーダーを選択する最も簡単な構成です。
2. ZK は最大数のノード損失を許可します。原則は「選出の半分以上が正常であることを保証する」ことであり、それ以上は無駄です。

詳細なアルゴリズムロジックは非常に複雑で、多くの状況を考慮する必要があります。その中には、Epoch（自己増加）の概念があり、LogicEpochとElectionEpochに分かれています。各投票サイクルが一貫しているかどうかなどを判断するには、各投票が必要です。