I. 飼育員の働き方

集中型システムと比較して、分散型システムは、強力なコンピューティング能力とストレージ能力、単一障害点の回避など、多くの利点を提供します。しかし、分散型デプロイメントにおいてネットワーク障害やその他の問題が発生した場合、すべてのノード間でデータの一貫性と可用性を確保することは極めて重要です。

[[313075]]

したがって、分散クラスターでは、さまざまなサービスとノードを調整して提供できる仲介者、つまり Zookeeper が必要です。

設計パターンの観点から見ると、ZooKeeper はオブザーバーパターンに基づく分散サービス管理フレームワークです。ZooKeeper は、誰もが関心を持つデータの保存と管理、そしてオブザーバーの登録を受け付ける役割を担っています。データの状態が変化すると、ZooKeeper は登録済みのオブザーバーに通知し、適切な対応を促します。

II. データ構造

Zookeeper のデータ構造は Linux のディレクトリ構造に似ており、次の図に示すように、データ構造のツリーにも似ています。

ZooKeeper は、Znode と呼ばれるノードに基づいてデータを保存します。Znode はパスによって参照され、各 Znode はパスによって一意に識別されます。

Znode には、次の図に示すように、データ、子ノード参照、アクセス権限などが含まれます。

• データ: Znodeに保存されているデータ情報
• ACL: Znode のアクセス権限を記録し、ノードへのアクセスを許可するユーザーまたは IP アドレスを指定します。
• child: 現在のノードの子ノードへの参照。バイナリ ツリーの左と右の子に似ています。
• stat: トランザクション ID、バージョン番号、タイムスタンプ、サイズなど、Znode に関するさまざまなメタデータが含まれます。

stat はルートディレクトリに関する詳細情報を表示します。

 [zk: localhost:2181(接続済み) 0] 統計 / 
 
 cZxid = 0x0 
 
 ctime = 1970年1月1日木曜日 08:00:00 CST 
 
 mZxid = 0x0 
 
 mtime = 1970年1月1日木曜日 08:00:00 CST 
 
 pZxid = 0x0 
 
転換率 = -1 
 
データバージョン = 0 
 
 aclバージョン = 0 
 
一時所有者 = 0x0 
 
データ長 = 0 
 
子供の人数 = 1

III. 選挙の仕組み

Zookeeperクラスタはマスター・スレーブアーキテクチャを採用しており、マスターがリーダー、スレーブがフォロワーとなります。リーダーは選出されます。

Zookeeper クラスターには次の特性があります。

Zookeeper: リーダーと複数のフォロワーで構成されるクラスター。

リーダーは、投票の開始と解決、およびシステム ステータスの更新を担当します。

- フォロワーは、クライアントのリクエストを受信して​​結果をクライアントに返すために、また、リーダー選出プロセス中に投票に参加するために使用されます。

- クラスター内の半数以上のノードが稼働している限り、Zookeeper クラスターは通常のサービスを提供できるため、Zookeeper は奇数台のサーバーにインストールするのに適しています。

- グローバルなデータ一貫性: 各サーバーはデータの同一のコピーを保存し、クライアントがどのサーバーに接続してもデータの一貫性を保証します。

更新要求は順番に処理されます。同じクライアントからの更新要求は、送信された順に実行されます。

- データ更新の原子性: データ更新は成功するか失敗するかのいずれかです。

- リアルタイムパフォーマンス: 一定の時間枠内で、クライアントは最新のデータを読み取ることができます。

リーダー選出は、分散データの一貫性を確保するために不可欠です。Zookeeperは、以下のいずれかの状態になったときに、リーダー選出を開始する必要があります。

• サーバーの初期化と起動
• リーダーは墜落して倒れた。

1. サーバーの初期化と起動時の選出

（1）3台のサーバーで構成されるクラスターを例にとると、クラスターの初期化フェーズで、サーバー1が起動すると、サーバー1だけで選挙を完了することはできません。サーバー2が起動すると、2台のマシンが相互に通信できるようになり、各マシンがリーダーを探そうとするため、選挙状態になります。

(2) 各サーバーはまず自身に投票します。初期段階では、各サーバーは自身をリーダーとして投票します。各投票には、(myid, ZXID, エポック) などの情報が含まれます。このとき、サーバー1の投票は(1, 0)、サーバー2の投票は(2, 0)です。その後、各サーバーはこの投票をクラスター内の他のマシンに送信します。

エポックは、複数の投票が同じ選挙サイクルにあるかどうかを判断するために使用されます。この値はサーバー側で自動的に増加されるシーケンスであり、新しい投票ラウンドが始まるたびに1ずつ増加します。

（3）各サーバーは他のサーバーから投票を受け取ります。投票を受け取った後、クラスター内の各サーバーはまず、その投票が現在のラウンドの投票であるかどうか、LOOKING状態のサーバーからの投票であるかどうかなど、投票の有効性を判断します。

(4) 投票処理。各投票において、サーバーは他のユーザーの投票と自身の投票を比較する必要があります。比較ルールは以下のとおりです。

ZXID のチェックを優先します。ZXID が大きいサーバーがリーダーとして優先されます。

ZXIDが同じ場合は、myidを比較します。myidが大きいサーバーがリーダーサーバーになります。

Server1の投票値は(1, 0)で、Server2の投票値は(2, 0)です。まず、両者のZXIDを比較します。どちらも0です。次に、両者のmyidを比較します。Server2のmyidが最大なので、投票値を(2, 0)に更新します。その後、再投票を行います。Server2は投票値を更新する必要はありません。以前の投票情報をクラスター内のすべてのマシンに再送信するだけです。

(5) 投票統計。各投票後、サーバーは投票情報を集計し、半数以上のマシンが同じ票を獲得したかどうかを判断します。サーバー1とサーバー2については、クラスター内の2台のマシンが(2, 0)の票を獲得したと判断されます。この時点で、リーダーが選出されたとみなされます。リーダーが選出されると、myidとZXIDの値に関係なく、後続のすべてのマシンは自動的にリーダーのフォロワーになります。

（6）サーバーの状態を変更する。リーダーが決定されると、各サーバーは状態を更新します。フォロワーの場合は「FOLLOWING」に、リーダーの場合は「LEADING」に状態が変更されます。

2. リーダーサーバーの障害時の投票メカニズム

起動時とは異なり、各サーバーは履歴データを保持しています。選出前に、非リーダーサーバーはまず状態を「LOOKING」に変更します。運用中は各サーバーが異なるZXIDを持つため、起動時と同様に新たな選出が行われます。

IV. 監視メカニズム

まず、main() スレッドが必要です。

Zookeeper クライアントはメイン スレッドで作成され、ネットワーク接続と通信用とリスニング用の 2 つのスレッドが作成されます。

登録されたリスナー イベントは、接続スレッドを介して Zookeeper に送信されます。

登録されたリスナー イベントを ZooKeeper 登録リスナー リストに追加します。

Zookeeper はデータまたはパスの変更を検出すると、このメッセージをリスナー スレッドに送信します。

リスナー スレッドは内部的に process() メソッドを呼び出します。

V. APIアプリケーション

Zookeeper でよく使用される API は次のとおりです。

`create` はノードを作成します。`delete` はノードを削除します。`exists` はノードが存在するかどうかを確認します。`getData` はノードのデータを取得します。`setData` はノードのデータを設定します。`getChildren` は指定されたノードのすべての子ノードを取得します。

これらのうち、exist、getData、getChildrenは読み取り操作です。読み取り操作を要求する際、ZookeeperクライアントはWatchを設定するかどうかを選択できます。

「見る」とはどういう意味ですか?

これは特定のZnodeに登録されたトリガーと考えることができます。このZnodeが変更されると、つまりcreate、delete、またはsetDataメソッドが呼び出されると、Znodeに登録されている対応するイベントがトリガーされ、Watchを要求しているクライアントは非同期通知を受け取ります。

具体的なインタラクションプロセスは次のとおりです。

• クライアントは、`watch` パラメータを `true` に設定して `getData` メソッドを呼び出します。サーバーはリクエストを受信し、ノードデータを返し、監視対象の Znode のパスと Watcher のリストを対応するハッシュテーブルに挿入します。
• 監視対象の Znode が削除されると、サーバーはハッシュ テーブルを検索してその Znode に対応するすべての Watcher を見つけ、クライアントに非同期的に通知し、ハッシュ テーブルから対応するキーと値のペアを削除します。

VI. アプリケーションシナリオ

Zookeeper は、統合ネーミング サービス、統合構成管理、統合クラスタ管理、動的サーバー ノードのオンライン/オフライン ステータス、ソフト ロード バランシングなどのサービスを提供します。