1. ZooKeeper とは何ですか?

1. オープンソースの分散調整サービス

分散システムを利用する場合、ノード管理の問題（ノードの状態をリアルタイムに把握する必要がある、ノードを一元管理する必要があるなど）が避けられません。これらの問題は比較的扱いが難しく、システムの複雑さを増大させる可能性があるため、これらの問題を普遍的に解決できるミドルウェアとしてZooKeeperが登場しました。

2. デザインパターンの観点からの理解

ZooKeeperは、オブザーバーパターンに基づく分散サービス管理フレームワークです。誰もが関心を持つデータの保存と管理を担います。データの状態が変化すると、ZooKeeperはZooKeeperに登録されているオブザーバーに通知し、適切な対応を促します。

3. 実施原則

ZooKeeper = ファイル システム + 通知メカニズム。

II. 飼育員の役割

1. 統合構成管理

例えば、A.yml、B.yml、C.ymlという設定ファイルがあり、これらには共通の設定が含まれています。しかし、後からこれらの共通設定を変更する必要がある場合、各ファイルを変更してサーバーを再起動する必要があり、非常に面倒です。

ここで、この公開構成情報を ZooKeeper に保存すると、ZooKeeper 情報に加えられた変更が構成ファイル A、B、C に送信され、非常に便利になります。

2. 統一された命名サービス

ここでの理解はドメイン名と同じです。特定のノードの下にIPアドレスをいくつか配置すれば、ZooKeeperのZnodeノードにアクセスするだけでこれらのIPアドレスを取得できます。

3. 同じクラスタ管理

Zookeeper は、監視と管理のために分散クラスターの状態を保存するために使用されます。

4. 分散調整

これは私たちが最もよく使う方法です。例えば、複数のサービスプロバイダーに関する情報を特定のノードに配置し、サービス利用者がZKを介してそれを呼び出すことができます。

サービスノードの動的なオンライン/オフラインステータス

プロバイダーがダウンした場合、ノードは Zookeeper から削除され、Zookeeper はコンシューマーに通知します。

5. ソフトロードバランシング

6. マスターの動的選出

ZooKeeperは、各イテレーションにおいて、最小のノードをマスターとして選出します。マスターに障害が発生した場合、対応するZnodeは削除されます。その後、最小のノードを持つ新しいノードがマスターとなり、動的な選出を実現します。

III. Zookeeperファイルシステム

ZooKeeper のデータ構造は Unix ファイルシステムに非常に似ています。ツリー構造として捉えることができ、各ノードは Znode と呼ばれます。各 Znode には 1MB のデータしか保存できず、これは設定情報のみです。

次の構造図に示すように、各ノードはパスによって識別できます。

ノードには主に 4 つの種類があります。

1.一時ディレクトリ ノード: このノードは、クライアントが Zookeeper から切断された後に削除されます。

2.一時的な連番ディレクトリノード：基本的な特性は一時ノードと同じですが、連番属性が追加されます。ノード名の後ろには、親ノードによって保持される自動増分整数が付加されます。

3.永続ディレクトリノード: このノードは、クライアントが Zookeeper から切断された後も存在します。

4.永続的な連番ディレクトリノード：基本的な特性は永続ノードと同じですが、連番属性が追加されます。親ノードによって保持される自動増分整数がノード名の後ろに付加されます。

IV. 通知メカニズム（監視メカニズム）

Zookeeper は、Watcher メカニズムに依存する分散データの公開/サブスクライブ機能を提供します。

クライアントはサーバーにWatherリスナーを登録できます。サーバー上で指定されたイベントが発生すると、イベント通知がクライアントに送信されます。

1. 具体的な手順は以下のとおりです。

（1）クライアントはWatherリスナーをサーバーに登録します。

（2）WatherオブジェクトをクライアントのローカルWatherManagerに保存します。

（3）サーバー側のWatherイベントがトリガーされると、クライアントはサーバーから通知を受信し、WatherManager（ウォッチャーマネージャー）から対応するWatherオブジェクトを取得してコールバックロジックを実行します。

2. 主な監視内容は次の 2 つの側面で構成されます。

（１）Znodeノードのデータの変更をリッスンします。つまり、ノードの情報が更新されたときです。

（2）子ノードの変更（Znodeの追加または削除）を監視します。

V. 飼育員の機能

1. 1 回限り: Water がトリガーされると、Zookeeper はそれをストレージから削除します。

2. クライアント側のシリアル処理：クライアント側のWatherコールバック処理はシリアル同期プロセスです。1つのWatherのロジックがクライアント全体をブロックしないように注意してください。

3. 軽量：天気通知の単位はWattedEventです。WattedEventには通知ステータス、イベントタイプ、ノードパスのみが含まれており、具体的なイベントコンテンツは含まれていません。具体的な時間コンテンツは、クライアントが能動的に取得する必要があります。

VI. 飼育員クラスター

• リーダー: データの書き込みを担当します。(データの書き込みにはトランザクションが伴います)。
• フォロワー: データの読み取り、ノードの選択、書き込みの成功を担当します (データの読み取りにはトランザクションは関与しません)。
• オブザーバー: 読み取りのみを担当します。

上記のロールから、Zookeeper ノードの動作状態 (サービス ステータス) をまとめることができます。

• LOOKING: リーダー探索状態。サーバーがこの状態にある場合、現在のクラスターにはリーダーが存在しないと想定し、リーダー選出状態に移行する必要があります。
• フォロー中: フォロワーのステータス。現在のサーバーロールがフォロワーであることを示します。
• LEADING: リーダーステータス。現在のサーバーの役割がリーダーであることを示します。
• OBSERVING: オブザーバー状態。現在のサーバーの役割がオブザーバーであることを示します。

zxid: グローバル トランザクション ID。2 つの部分から構成されます。

(1) 時代区分：時代区分は、現在のクラスターがどの指導者に属しているかを表します。指導者の選出は王朝の交代に似ています。前の王朝の剣では、現在の王朝の官吏を殺すことはできません。時代区分は、現在の命令の有効性を表します。

（２）カウンターパートは、グローバルに順序付けられた増加数である。

VII. データ書き込みの原則

1.リーダーに書き込み、リーダーが他のノードに通知します。

2.フォロワーに書き込みます。フォロワーに書き込み権限がない場合は、リーダーに書き込み権限が渡され、リーダーから通知されます。

3.半数過半数メカニズム：上図に示すように、ZooKeeper が他のノードに書き込みを通知する際、半数のノードが書き込みを完了した時点でクライアントに書き込み完了を通知します。すべてのノードが書き込みを完了する必要はありません。そのため、クラスター内のノード数は一般的に奇数になります。

8. ZooKeeper はどのようにしてデータの一貫性を確保するのでしょうか?

ZooKeeper にデータを書き込むことができるのはリーダーノードのみであるため、他のノードがデータの書き込み要求を受信すると、その要求をリーダーノードに転送します。

ZooKeeper は、2PC (Two-Phase Commit) に類似したプロセスである ZAB プロトコルを通じて、データの結果順序一貫性を実現します。ZAB には、メッセージブロードキャストとクラッシュリカバリ（選出）の 2 つのモードがあります。

通常、メッセージをブロードキャストします。

フェーズ1：放送業務フェーズ

1. リーダーはリクエストを受信すると、それを提案に変換し、各提案にトランザクション ID: zxid を割り当てます。

2. 次に、提案を FIFO キューに入れて、FIFO 戦略に従ってすべてのフォロワーに送信します。

3. フォロワーは提案を受信すると、それをトランザクション ログの形式でローカル ディスクに書き込み、書き込みが成功した後にリーダーに ACK を返します。

第2フェーズ: 放送提出操作

リーダーはフォロワーの半数以上から ACK を受信すると、データの書き込みが成功したと見なし、フォロワーにコミット コマンドを送信して、提案を送信できることを伝えます。

この記事はWeChat公式アカウント「Nezha Programming」から転載したものです。以下のQRコードからフォローできます。転載の許可については、Nezha Programming公式アカウントまでお問い合わせください。