ZooKeeper のしくみと機能を理解しようとしています。ZooKeeper に匹敵するアプリケーションはありますか?
知っている場合、ZooKeeper を素人にどのように説明しますか?
apache wiki、zookeeper sourceforge を試しましたが、まだ関係がありません。
http://zookeeper.sourceforge.net/index.sf.shtmlを読んだだけなので、このようなサービスは他にありませんか? サーバーサービスをレプリケートするだけの簡単なものですか?
簡単に言えば、ZooKeeper は分散アプリケーションの構築を支援します。
ZooKeeper は、結果整合性を備えた複製された同期サービスであると説明できます。永続化されたデータが複数のノード (このノードのセットは「アンサンブル」と呼ばれます) に分散され、1 つのクライアントがそれらのいずれかに接続され (つまり、特定の「サーバー」)、1 つのノードに障害が発生した場合に移行されるため、堅牢です。厳密に過半数のノードが機能している限り、ZooKeeper ノードのアンサンブルは存続します。特に、マスターノードはアンサンブル内のコンセンサスによって動的に選択されます。マスター ノードに障害が発生すると、マスターの役割が別のノードに移行します。
マスターは書き込みの権限です。このようにして、書き込みが順番どおりに保持されることが保証されます。つまり、書き込みは線形です。クライアントがアンサンブルに書き込むたびに、大多数のノードが情報を保持します。これらのノードには、クライアント用のサーバーと、明らかにマスターが含まれます。これは、各書き込みによって、サーバーがマスターで最新の状態になることを意味します。ただし、同時書き込みができないことも意味します。
線形書き込みが保証されていることが、ZooKeeper が書き込み主体のワークロードでうまく機能しない理由です。特に、メディアなどの大きなデータの交換には使用しないでください。コミュニケーションに共有データが含まれる限り、ZooKeeper が役に立ちます。データが同時に書き込まれる可能性がある場合、ZooKeeper は実際に邪魔になります。ライターの観点から厳密に必要でなくても、ZooKeeper は操作の厳密な順序付けを課すからです。その理想的な用途は、クライアント間でメッセージが交換される調整です。
これが ZooKeeper の優れた点です。読み取りは、クライアントが接続する特定のサーバーによって処理されるため、同時実行されます。ただし、これは結果整合性の理由でもあります。マスターは対応するサーバーを限定された未定義の遅延で更新するため、クライアントの「ビュー」が古くなっている可能性があります。
ZooKeeper の複製されたデータベースはznodesのツリーで構成されます。 znodesは、ファイル システム ノードを大まかに表すエンティティです (ディレクトリと考えてください)。各 znode は、データを格納するバイト配列によって強化される場合があります。また、各 znode はその下に他の znode を持つことができ、実質的に内部ディレクトリシステムを形成します。
興味深いことに、znode の名前は連続することができます。つまり、znode の作成時にクライアントが提供する名前は接頭辞にすぎません。完全な名前は、アンサンブルによって選択された連続番号によっても与えられます。これは、たとえば、同期の目的で役立ちます。複数のクライアントがリソースのロックを取得したい場合、それぞれがロケーションに順次 znode を同時に作成できます。最小の番号を取得した人がロックを受ける資格があります。
また、znode はephemeralである場合があります。これは、それを作成したクライアントが切断されるとすぐに破棄されることを意味します。これは主に、クライアントがいつ失敗したかを知るために役立ちます。これは、クライアント自体が新しいクライアントが引き受けるべき責任を持っている場合に関連する可能性があります。ロックの例を挙げると、ロックを保持しているクライアントが切断されるとすぐに、他のクライアントはロックの資格があるかどうかを確認できます。
znode の状態を定期的にポーリングする必要がある場合、クライアントの切断に関連する例は問題になる可能性があります。幸いなことに、ZooKeeperには、znode で監視を設定できるイベント システムが用意されています。これらのウォッチは、znode が具体的に変更または削除された場合、またはその下に新しい子が作成された場合にイベントをトリガーするように設定できます。これは、znode のシーケンシャルおよびエフェメラル オプションと組み合わせると明らかに便利です。
Zookeeper の標準的な使用例は、分散メモリ計算です。この場合、一部のデータはクライアント ノード間で共有され、同期を考慮して非常に慎重な方法でアクセス/更新する必要があります。
ZooKeeper は同期プリミティブを構築するためのライブラリを提供しますが、分散サーバーを実行する機能により、集中化された (ブローカーのような) メッセージ リポジトリを使用するときに発生する単一障害点の問題を回避できます。
つまり、リーダー選出、ロック、バリアなどのメカニズムはまだ存在していませんが、ZooKeeper プリミティブの上に記述できます。C/Java API が目的に対して扱いにくい場合は、ケージ、特にcuratorなど、ZooKeeper で構築されたライブラリに依存する必要があります。
公式ドキュメントは別にして、 Hadoop: The Definitive Guide の第 14 章を読むことをお勧めします。このガイドには、基本的に ZooKeeper が何を行うかを説明する約 35 ページがあり、その後に構成サービスの例が続きます。
Zookeeper は、分散プロセスを確実に調整するのに役立つ、最高のオープン ソース サーバーおよびサービスの 1 つです。Zookeeper は、一貫性と分断耐性を提供する CP システム (CAP Theorem を参照) です。すべてのノードで Zookeeper の状態を複製することで、最終的に一貫性のある分散サービスになります。
さらに、新しく選出されたリーダーは、フォロワーに不足している提案が多数ある場合、不足している提案または状態のスナップショットでフォロワーを更新します。
Zookeeper は、非常に使いやすい API も提供します。例を探している場合は、このブログ投稿Zookeeper Java API の例にいくつかの例があります。
では、これをどこで使用するのでしょうか。分散型サービスで、一元化された信頼性の高い一貫した構成管理、ロック、キューなどが必要な場合は、Zookeeper が信頼できる選択肢であることがわかります。
Zookeeper は、構成情報、命名規則、および分散クラスター環境の同期を維持および管理するための集中型オープン ソース サーバーです。Zookeeper は、低遅延と高可用性を提供することで、分散システムの管理の複雑さを軽減するのに役立ちます。Zookeeper は当初 Hadoop のサブプロジェクトでしたが、現在は Apache Software Foundation の最上位の独立したプロジェクトです。