Apache ZooKeeperの説明


376

ZooKeeperのしくみと仕組みを理解しようとしています。ZooKeeperに匹敵するアプリケーションはありますか?

ご存知の場合、ZooKeeperを素人にどのように説明しますか?

私はapache wiki、zookeeper sourceforgeを試してみましたが、それでも私はそれに関係することができません。

http://zookeeper.sourceforge.net/index.sf.shtmlを読んだだけなので、このようなサービスは他にありませんか?サーバーサービスの複製と同じくらい簡単ですか?


6
似てではなく、あなたが探している正確な答え:stackoverflow.com/questions/1479442/real-world-use-of-zookeeper
zengr


このペーパーを読むことができますZooKeeper: 2つのYahoo!によって書かれたインターネット規模のシステムのための待機なしの調整 エンジニア
ヤフェット2013

これは、RentTheRunwayのCTOであるCamille FournierによるApache ZooKeeperの紹介であるテクニカルトークです。お役に立てれば幸いです。
Genadinik 2013年

@Luca Geretti ...私によれば、Zookeperは一連のAPIを提供しているため、それを利用して分散アプリケーションを調整できます。私が間違っている場合は私を修正します。
user3797438 14

回答:


434

一言で言えば、ZooKeeperは分散アプリケーションの構築を支援します。

使い方

ZooKeeperは、結果整合性を備えた複製同期サービスとして説明できます。永続化されたデータは複数のノード(このノードのセットは「アンサンブル」と呼ばれます)に分散され、1つのクライアントがそれらのいずれかに(つまり、特定の「サーバー」)接続して、1つのノードに障害が発生すると移行します。ノードの厳密な過半数が機能している限り、ZooKeeperノードのアンサンブルは生きています。特に、マスターノードはアンサンブル内のコンセンサスによって動的に選択されます。マスターノードに障害が発生すると、マスターの役割が別のノードに移行します。

書き込みの処理方法

マスターは書き込みの権限です。このようにして、書き込みが順序どおりに保持されることが保証されます。つまり、書き込みは線形です。クライアントがアンサンブルに書き込むたびに、大多数のノードが情報を保持します。これらのノードには、クライアントのサーバーと、明らかにマスターが含まれます。これは、書き込みごとにサーバーがマスターで最新になることを意味します。ただし、同時に書き込みを行うことはできません。

線形書き込みの保証は、ZooKeeperが書き込みが主なワークロードに対して十分に機能しないという事実の理由です。特に、メディアなどの大きなデータの交換には使用しないでください。通信に共有データが含まれている限り、ZooKeeperが役立ちます。データを同時に書き込むことができると、ZooKeeperは実際には邪魔になります。これは、ライターの観点から厳密に必要でなくても、操作の厳密な順序付けを課すためです。その理想的な用途は、クライアント間でメッセージが交換される調整のためです。

読み取りの処理方法

これがZooKeeperが優れているところです。読み取りは、クライアントが接続する特定のサーバーによって処理されるため、同時読み取りです。ただし、これは結果整合性の理由でもあります。マスターが対応するサーバーを制限された未定義の遅延で更新するため、クライアントの「ビュー」が古くなる可能性があります。

詳細に

ZooKeeperの複製データベースはznodeのツリーで構成されます。これは、ファイルシステムノードを大まかに表すエンティティです(それらをディレクトリと考えてください)。各znodeは、データを格納するバイト配列によって拡張できます。また、各znodeにはその下に他のznodeがあり、実際には内部ディレクトリシステムを形成しています。

シーケンシャルznode

興味深いことに、znodeの名前は順次にすることができます。つまり、znodeの作成時にクライアントが提供する名前はプレフィックスにすぎません。完全な名前は、アンサンブルによって選択された連続番号によっても与えられます。これは、たとえば同期の目的で役立ちます。複数のクライアントがリソースのロックを取得したい場合、それぞれがロケーションに順次znodeを同時に作成できます。最も小さい番号を取得する人には、ロックを付与する権利があります。

エフェメラルzノード

また、znodeは一時的なものである可能性があります。つまり、znode は、それを作成したクライアントが切断するとすぐに破棄されます。これは主に、クライアントがいつ失敗するかを知るために役立ちます。これは、クライアント自体が新しいクライアントが行うべき責任を持っている場合に関連する場合があります。ロックの例をとると、ロックを保持しているクライアントが切断されるとすぐに、他のクライアントは、ロックを取得する資格があるかどうかを確認できます。

時計

クライアントの切断に関連する例は、znodeの状態を定期的にポーリングする必要がある場合に問題になる可能性があります。幸い、ZooKeeperはznodeにウォッチを設定できるイベントシステムを提供しています。これらのウォッチは、znodeが特に変更または削除された場合、またはznodeの下に新しい子が作成された場合に、イベントをトリガーするように設定できます。これは、znodeのシーケンシャルおよびエフェメラルオプションと組み合わせると明らかに便利です。

どこでどのように使用するか

Zookeeperの標準的な使用例は分散メモリ計算です。この場合、一部のデータはクライアントノード間で共有され、同期を考慮するために非常に注意深くアクセス/更新する必要があります。

ZooKeeperは、同期プリミティブを構築するためのライブラリーを提供し、分散サーバーを実行する機能は、集中型(ブローカーのような)メッセージリポジトリを使用するときに発生する単一障害点の問題を回避します。

ZooKeeperは機能が軽いため、リーダーの選出、ロック、バリアなどのメカニズムはまだ存在していませんが、ZooKeeperプリミティブの上に記述できます。C / Java APIが目的に合わない場合は、ケージや特にキュレーターなど、ZooKeeperで構築されたライブラリに依存する必要があります。

続きを読む場所

公式ドキュメントは別として、かなり良いです。Hadoopの第14章を読むことをお勧めします。ZooKeeperの基本的な機能を説明する35ページ以下のDefinitive Guideと、構成サービスの例が続きます。


2
あなたが提案している通信方式を理解しているとは思いませんが、ZooKeeperを使用してプロデューサーからの情報を「公開」し、複数のコンシューマーに読み取らせることができます。一方、各種類のサーバーのインスタンスが1つしか存在しない場合、ZKを使用してもほとんどメリットがありません。
Luca Geretti、2014年

57
IMOこれは、ZooKeeperが素人にとって何であるかを説明できません。ZooKeeperはいつ必要になりますか?何を書けばいいですか?それはどのような問題を解決しますか?それはキーバリューストアですか?サーチエンジン?分散ロック?Redisやファイル、JIRA、付箋などでZooKeeperを選択するのはなぜですか?ZooKeeperについてはよくご存知ですが、技術的な説明は少ないですか?
Dan Passaro 2017年

1
Zookeeperには線形書き込みがあるため、非同期APIを使用してノードを作成し、応答をコールバックで受け取ることを止めることはありませんか?内部的には同時書き込みが許可されていない場合がありますか、それとも何か不足していますか?
jdk2588 2017年

1
「クライアントがアンサンブルに書き込むたびに、大多数のノードが情報を保持します。これらのノードにはクライアントのサーバーが含まれ、明らかにマスターが含まれます」=>ドキュメントを参照してください。またはこれが説明されている何か?クライアントが接続されているサーバーを除いて、状態が正常に変更された可能性があるかどうか疑問に思っています(この場合、クライアントは、自分の書き込みをしばらく読み取れないという奇妙な動作を経験する可能性があります)
センシウウ

2
尋ねられた質問に完全かつ完全に反対です。時計であれば、ぜんまい、輪列、脱進機、振動の周期、慣性モーメント、人工サファイア結晶の影響に基づくそれらの相互作用の説明ではなく、「計時装置」を探します。
Rick O'Shea

10

Zookeeperは、分散プロセスを確実に調整するのに役立つ最高のオープンソースサーバーおよびサービスの1つです。Zookeeperは、一貫性とパーティションの許容範囲を提供するCPシステム(CAPの定理を参照)です。すべてのノード間でZookeeper状態を複製することにより、最終的に一貫した分散サービスになります。

さらに、新しく選出されたリーダーは、フォロワーが欠落している多くの提案がある場合、欠落している提案または州のスナップショットでフォロワーを更新します。

Zookeeperには、非常に使いやすいAPIも用意されています。このブログ投稿「Zookeeper Java APIの例」には、例を探している場合の例がいくつかあります。

では、これをどこで使うのでしょうか?分散サービスが、集中化された、信頼性があり、一貫性のある構成管理、ロック、キューなどを必要とする場合、Zookeeperは信頼できる選択肢です。


4
「Zookeeperは、一貫性とパーティションの許容範囲を提供するCPシステム(CAPの定理を参照)です。」Zookeeperにはマスターとフォロワーがいると思います。マスターがダウンすると、フォロワーの1人がリーダーとして選出されるため、ZookeeperはAP、ただしCは最終的には一貫しています。
YuFeng Shen

5
CAPの定理に関して、「C」は実際には線形化可能性を意味します。実際、ZooKeeperは「シーケンシャル一貫性」を提供し、クライアントからの更新が受信順に適用されることを意味します。これは線形化可能性よりは弱いですが、依然として非常に強力で、「最終的な一貫性」よりもはるかに強力です。ZookeeperはAではありません。リーダーを選出できない(定足数がない)場合、Zookeeperはリクエストに失敗します。これが高可用性ではない理由です。
Binu George

7

ZooKeeperは一般的には理解していますが、「定足数」と「スプリットブレイン」という用語に問題があったので、調査結果をあなたと共有できます(私も素人と思います)。

5つのサーバーからなるZooKeeperクラスターがあるとします。サーバーの1つがリーダーになり、他のサーバーがフォロワーになります。

  • これらの5つのサーバーがクォーラムを形成します。クォーラムは、「これらのサーバーは、誰がリーダーになるべきかについて投票できる」という意味です。

  • したがって、投票は過半数に基づいています。過半数は単に「半分以上」を意味するため、特定のサーバーがリーダーになるには、サーバー数の半分以上が同意する必要があります。

  • したがって、「スプリットブレイン」と呼ばれる、起こり得るこの悪いことがあります。スプリットブレインは、私が理解している限り、これだけです。5台のサーバーのクラスターが2つの部分に分割されるか、「サーバーチーム」と呼びましょう。どちらの「サーバーチーム」も特定の注文を実行する必要がある場合、これは本当に悪い状況です。どのチームを優先するかをどのように決定しますか?クライアントから異なる情報を受け取った可能性があります。したがって、どの「サーバーチーム」がまだ関連しており、どれを無視できる/すべきかを知ることが非常に重要です。

  • 過半数は、奇数のサーバーを使用する必要がある理由でもあります。4つのサーバーと2つのサーバーが分かれているスプリットブレインがある場合、両方の「サーバーチーム」は「ねえ、私たちは誰がリーダーであるかを決定したいのです!」しかし、どの2つのサーバーを選択するかをどのように決定すればよいでしょうか。サーバーが5台の場合は簡単です。サーバーが3台のサーバーチームが過半数を占め、新しいリーダーを選択することができます。

  • サーバーが3つしかなく、そのうちの1つに障害が発生しても、残りの2つは過半数を占め、そのうちの1つが新しいリーダーになることに同意できます。

少し考えてみれば、もうそれほど複雑ではない用語を理解できたと思います。これがまた、これらの用語を理解する上で誰にも役立つことを願っています。


1

Zookeeperは、分散クラスター環境の構成情報、命名規則、および同期を維持および管理するための集中型オープンソースサーバーです。Zookeeperは、低遅延と高可用性を提供することにより、分散システムが管理の複雑さを軽減するのに役立ちます。Zookeeperは当初Hadoopのサブプロジェクトでしたが、現在はApache Software Foundationのトップレベルの独立したプロジェクトになっています。

詳しくは


2
飼育係が一元化されていると言うのはなぜですか?Zookeeperは分散して実行できます。
Benjamin HammerNørgaard2017

1

次のリソースをお勧めします。

  1. 論文:https : //pdos.csail.mit.edu/6.824/papers/zookeeper.pdf
  2. MIT 6.824が36:00から提供する講義:https ://youtu.be/pbmyrNjzdDk?t=2198

ビデオを見て、論文を読んでから、ビデオをもう一度見ることをお勧めします。事前にラフトを知っている方がわかりやすいでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.