飼育係の定義
Zookeeper は、分散フレームワークの調整サービスを提供するオープン ソースの分散 Apache プロジェクトです。
飼育係の仕組み
Zookeeper は、設計パターンの観点から理解されます。つまり、共通の関心事のデータを格納および管理し、オブザーバーの登録を受け入れる、オブザーバー パターンに基づく分散サービス管理フレームワークです。これらのデータの状態が変化すると、Zookeeper は、Zookeeper に登録されているオブザーバーにそれに応じて応答するよう通知する責任があります。つまり、Zookeeper = ファイル システム + 通知メカニズム
飼育係機能
- Zookeeper: クラスターのリーダーとフォロワー
- Zookeeper クラスター内のノードの半分以上が存続している限り、Zookeeper クラスターは正常に動作できます。そのため、Zookeeper は奇数のサーバーをインストールするのに適しています
- グローバルなデータの一貫性: 各サーバーはデータの同じコピーを保存します。クライアントがどのサーバーに接続しても、データは一貫しています。
- 更新要求は順番に実行され、同じクライアントの更新要求は送信された順序、つまり先入れ先出し (FIFO) で実行されます。
- データ更新の原子性、データ更新は成功または失敗のいずれか
- リアルタイム、クライアントは特定の時間範囲内の最新データを読み取ることができます
飼育係のデータ構造
ZooKeeper データ モデルの構造は、Linux ファイル システムの構造と非常によく似ており、全体がツリーのように見え、各ノードは ZNode と呼ばれます。各 ZNode はデフォルトで 1MB のデータを保存でき、各 ZNode はそのパスによって一意に識別できます
Zookeeper アプリケーションのシナリオ
提供されるサービスには、統一されたネーミング サービス、統一された構成管理、統一されたクラスター管理、動的オフライン サーバー ノード、ソフト ロード バランシングなどがあります。
統一ネームサービス
分散環境では、識別を容易にするために、多くの場合、アプリケーション/サービスの名前を統一する必要があります。例: IP は覚えにくいが、ドメイン名は覚えやすい
統合された構成管理
(1) 構成ファイルの同期は、分散環境では一般的です。通常、Kafka クラスターなど、クラスター内のすべてのノードの構成情報は一貫している必要があります。構成ファイルを変更した後、各ノードにすばやく同期できることが望まれます
(2) 構成管理を ZooKeeper に引き継ぐことができます。設定情報を ZooKeeper に書き込むことができます。上の 1 つ以上の Znode。すべてのクライアント サーバーは、この Znode をリッスンします。Znode のデータが変更されると、ZooKeeper はクライアント サーバーに通知します。
統合クラスタ管理
(1) 分散環境では、各ノードの状態をリアルタイムで把握する必要があります。これは、ノードのリアルタイムの状態に応じて実行できます。
(2) ZooKeeper はノードの状態変化をリアルタイムで監視できます。ノード情報を ZooKeeper に書き込むことができます。上の ZNode。この ZNode をリッスンして、リアルタイムのステータス変更を取得します
サーバーの動的なアップとダウン
クライアントは、サーバーとダウンライン間の変化をリアルタイムで把握できます
ソフト ロード バランシング
Zookeeper の各サーバーへの訪問回数を記録し、訪問回数が最も少ないサーバーに最新のクライアント要求を処理させます
飼育係の選出メカニズム
サーバーが5台の場合
初めて選出メカニズムを開始する
(1) サーバー 1 が起動し、選出を開始します。サーバー 1 は自分自身に投票します。この時点で、サーバー 1 の投票数は 1 票で半分以下 (3 票) であり、選挙は完了できず、サーバー 1 のステータスは LOOKING のままです。
(2) サーバー 2 が起動し、別の選挙を開始します。サーバー 1 とサーバー 2 は自分自身に投票し、投票情報を交換します。この時点で、サーバー 1 はサーバー 2 の myid が現在の投票プッシュ (サーバー 1) よりも大きいことを発見し、投票をサーバー 2 に変更します。この時点で、サーバー 1 は 0 票、サーバー 2 は 2 票で、結果は半分以下であり、選挙を完了することはできず、サーバー 1 と 2 のステータスは L00KING のままです。
(3) サーバー 3 が起動し、選挙を行います。Server1 と Server2 は投票を Server3 に変更します。投票結果：サーバー1 0票、サーバー2 0票、サーバー3 3票。サーバー 3 が過半数の票を獲得し、サーバー 3 がリーダーに選出されました。サーバー 1、2 は状態を FOLLOWING に変更し、サーバー 3 は状態を LEADING に変更します。
(4) サーバー 4 が起動し、選挙を行います。この時点で、サーバー 1、2、3 は L00KING 状態ではなくなり、投票情報は変更されません。投票情報の交換結果: サーバー 3 は 3 票、サーバー 4 は 1 票です。サーバー 4 は多数決に従い、投票情報をサーバー 3 に変更し、状態を FOLLOWING に変更します。
(5) サーバー 5 は 4 の弟として起動します。
サーバーが3台の場合
初めて選出メカニズムを開始する
(1) サーバー 1 が起動し、選出を開始します。サーバー 1 は自分自身に投票します。この時点で、サーバー 1 の投票数は 1 票で半分以下 (2 票) であり、選挙は完了できず、サーバー 1 のステータスは LOOKING のままです。
(2) サーバー 2 が起動し、別の選挙を開始します。サーバー 1 とサーバー 2 は自分自身に投票し、投票情報を交換します。この時点で、サーバー 1 はサーバー 2 の myid が現在の投票プッシュ (サーバー 1) よりも大きいことを発見し、投票をサーバー 2 に変更します。この時点で、サーバー 1 は 0 票を投じ、サーバー 2 は半分以上の票を獲得し、サーバー 2 がリーダーに選ばれました。サーバー 1 は状態を FOLLOWING に変更し、サーバー 2 は状態を LEADING に変更します。
(3) サーバー 3 が起動し、選挙を行います。この時点で、サーバー 1 と 2 は L00KING 状態ではなくなり、投票情報は変更されません。投票情報の交換結果: サーバー 2 は 2 票、サーバー 3 は 1 票です。サーバー 3 は多数決に従い、投票情報をサーバー 2 に変更し、状態を FOLLOWING に変更します。