[]シナリオは、飼育係概説します

• まず、データは（物流センター）をパブリッシュおよびサブスクライブ
• 第二に、ロード・バランシング
• 第三に、ネームサービス（ネーミングサービス）
• 第四に、分散通知/コーディネート
• V.クラスタ管理とマスターの選挙
• 第六に、分散ロック
• 七、分散トランザクション

まず、データは（物流センター）をパブリッシュおよびサブスクライブ

• パブリッシュ及びサブスクライブ・モデルを、いわゆる物流センター、定義によりそれは出版社が加入者の動的データ収集、集中管理及び動的更新設定情報をノードZKにデータを公開しますです。このようなグローバルコンフィギュレーション情報、サービスアドレスリストや他のサービス・サービス・フレームワークとしての使用に非常に適しています。

第二に、ロード・バランシング

• ここでは、ソフトロードバランシングロードバランシングを意味します。分散環境では、高可用性を確保するためには、通常、同一のアプリケーションやサービスプロバイダと他のサービスに到達するよりも多くを展開します。そして、消費者は、メッセージが、典型的なミドルウェアの生産、消費、負荷分散であり、これらのピア・サーバーを実行するために、関連するビジネス・ロジックを選択する必要があります。
• すべての生産を行うためにKafkaMQオープンソースとオープンソースmetaqアリをLinkedInの、のメッセージングミドルウェアのロードバランシングと加入者で掲示される、消費者は、飼育係による負荷分散します。ここでは、例えば、metaqに話し、次のとおりです。
• メーカーのロードバランシング：metaqは、メッセージを送信するためにメッセージを送信する時にブローカ上のパーティションを選択する必要がありますメッセージプロデューサを送信するので、運転中のmetaq、およびブローカーは、すべてのパーティション情報が登録されているすべてに対応しますとき指定されたノードにZK、デフォルト戦略はパーティションbrokerIdの配列順に、ZKを介してパーティションプロデューサのリストを取得した後、順次ポーリング処理であり、パーティションの順序リストに編成され、送信時間に応じて、開始から終了までパーティションを選択するメッセージを送信するために反復的。
• 消費者のロードバランシング：消費プロセスでは、消費者はニュースで1つまたは複数のパーティションを過ごすことになるが、パーティションは、消費者によって消費されます。MetaQの消費者の戦略は次のとおりです。
  1. 同じグループの各パーティションには、消費者をマウントします。
  2. パーティションの数よりも多いグループと消費者の数ならば、消費者のうち、より消費に参加しません。
  3. パーティションの数よりも少ないのグループと消費者の数は、一部の消費者が存在する場合、追加のタスクの消費量に着手する必要があります。
• 故障や消費者を再起動する場合は、他の消費者は、（消費者の飼育係のウォッチリストで）この変更を認識し、その後、すべてのパーティションは、消費者の支出を持っていることを保証するために、バランスをとる負荷を再します。

第三に、ネームサービス（ネーミングサービス）

• サービスに名前を付けると、シーンの分散システムは比較的一般的なタイプです。分散システムでは、ネーミングサービスなので、上の指定したリソースまたはサービス名、情報提供者とのアドレスを取得することができ、クライアントアプリケーションを使用します。名前付きエンティティように、通常はマシンのクラスタ、提供するサービスのアドレス、リモートオブジェクト、およびすることができます - 私たちは、名前（名）としてそれらを参照することができました。より一般的なの一つは、いくつかの分散サービスフレームワークサービスアドレスリストです。ZKが提供するノードを作成するためのAPIを呼び出すことで、簡単にグローバルに一意のパスを作成することができ、このパスは名前として使用することができます。
• そのネームサービスとしてダボのZooKeeperに分散サービスのためのオープンソースのフレームワークを使用してアリババグループ、サービスのグローバルアドレス一覧を維持し、ダボのオープンソースプロジェクトを見るにはこちらをクリックしてください。ダボの実装では：
• それは起動時に、サービスプロバイダは、ZK /ダボ/ $ {serviceNameを} /プロバイダディレクトリの下に、この操作が完了出版サービスである上の指定されたノードへのあなたのURLアドレスを書きます。
• 消費者サービスの起動、サブスクライブ/ダボ/ \（プロバイダディレクトリURLアドレス/下{serviceNameを}プロバイダ、および/ダボ/は\）ディレクトリ{serviceNameを}の下に、独自のURLアドレス/消費者を書き込みます。
• ZKのノードアドレスに登録されているすべては一時的なものですので、我々は、サービス・プロバイダーと消費者は、自動的にリソースの変化を感知することを保証できることに注意してください。また、ダボのすべての情報提供者と消費者のサブスクリプション/ダボ/ $ {serviceNameを}ディレクトリにより、粒度を監視するためのサービスがあります。

第四に、分散通知/コーディネート

　　分散環境では、異なるシステム間での良好な通知および調整を達成するために、特有ウォッチャー登録および非同期通知メカニズムを飼育係、データ変更のリアルタイム処理。通常、異なるシステムを使用し、別のシステムが通知を受信し、それに応じて反応する、（のznode独自のコンテンツと子ノードを含む）の変更ののznodeを監視し、同じのznodeのZKレジスタ上のすべてのznodeのシステムアップデートの一つでありますプロセス

1. 別のハートビート検出：検出システムと検出システムとの間で直接関連するが、大幅に連結システムを減らす、ZKに関連付けられているノードによってれません。
2. 別のシステム・スケジューリング・モード：システム・コンソール、および2つの部分から構成プッシュシステム、プッシュプッシュ方式の作業を対応する制御コンソール機能。コンソールのためのいくつかの運用管理では、実際には、ZK上の特定のノードの状態を変更することで、ZKは、これらの変更を入れて、すなわち、適切なプッシュタスクを作成し、その後、システムを押して、登録ウォッチャークライアントを通知します。
3. 作業モードの別のレポート：何か同様のタスク分散システム、サブタスクは一時的なノードを登録するにはZKを開始し、その進捗状況のタイミングを報告する（この一時的なノードの進捗状況を書き戻す）、その上のタスクマネージャあなたは、リアルタイムでタスクの進捗状況を知ることができます。
   要約すると、分散のために飼育係通知および調整を使用すると、大幅にシステム間の結合を低減することができます

V.クラスタ管理とマスターの選挙

1. クラスタマシンの監視：これは通常、マシンの状態をクラスタ化するために使用される種類で、マシンはすぐに、クラスタマシンの変化に対応することができ、シーンのオンライン率が高い要件があります。このようなシナリオは、リアルタイム検出マシンクラスタの生存かどうか、監視システムを持っている傾向があります。過去の練習は通常、次のとおりです。各マシンのタイミングや各マシンの監視システムへの独自の定期的な報告を検出する（pingなど）何らかの手段による監視システム、「私は生きているんです。」このアプローチは動作しますが、2つの明らかな問題があります。
2. クラスタマシンはより多くの関与は、物事を変更する際に変更されることがあります。
3. 一定の遅延。使用ZooKeeperのは、別のクラスタマシンのライブネス監視システムを実現することができ、二つの特徴があります。
4. クライアントノード上のX変更のウォッチャー、その後、もしX？子供を登録し、クライアントに通知します。
5. ノードの一時的なタイプを作成、セッションのクライアントとサーバの終了または期限切れたら、そのノードが消えます。
   • 例えば、/ clusterServers上の監視システムウォッチャーノード登録は、すべてのマシンの後に追加動的、ノードタイプ/ clusterServers乗っエフェメラル作成：/ clusterServers / {ホスト名}したがって、監視システムは、機械によってリアルタイムで知ることができるであろう。監視システムその後の処理動作と同様に、ケースを保存します。
6. マスターの選挙は、最も古典的なシナリオで飼育係です。
   • 分散環境では、同じビジネスアプリケーションが異なるマシン上に分布し、いくつかのビジネスロジックは、（例えば、時間のかかる計算、ネットワークI / Oプロセスの数）、マシンの多くの場合、一つだけでは、実行のためのクラスタ全体を作るために残りのマシンが大幅に重複を削減し、パフォーマンスを向上させることができ、結果を、共有することができますので、マスターの選挙は、このシナリオで発生した主な問題です。
   • ZooKeeperのは、つまりグローバル一意性を、分散型高同時実行の下に作成されたノードを確実にするために、強い整合性を使用します、成功を作成するために、最終的にのみ、特定のクライアント要求を/ currentMasterノードを作成するために、複数のクライアント要求があります。この機能を使用して、それが簡単に分散環境でクラスタを選択することができます。
   • また、このシナリオの進化を見て、それは動的なマスターの選挙です。この使用は、ノードの種類の特性をEPHEMERAL_SEQUENTIALします。
   • 、成功を作成することができ、最終的に一つだけを作成するために、すべてのクライアント要求。このわずかな変化では、すべての要求を作成することができるようにすることですが、創造の順序を持​​っている必要があり、その後、ZK一つの可能​​な状況に最終的な結果を作成するためのすべての要求はこれです：/ currentMaster / {セッションID} -1、/ currentMaster / {セッションID} -2、/ currentMaster / {セッションID} -3 ...機械に連結されている場合、ノードは、直ちに、最小の後、彼の時間を作成するため..各マシンは、マスターとして最小のシリアル番号を選択しますそれは、マシンのマスターです。
7. 検索システムでは、クラスタ内の各マシンがフルインデックス量を生成する場合は、時間がかかり、互いにインデックスデータ間の整合性を保証するものではありません。だから、クラスタマスターは、インデックスの完全な量を生成してみましょう、その後、クラスタ内の他のマシンに同期します。また、災害復旧は、手動でマスター情報を取得することはできませんZKで使用する場合、あなたは、このようなHTTPの方法によるような場所にマスターを得ることができ、いつでもマスターを指定することができますマスター選挙を測定します。
8. HBaseのでは、選挙がダイナミックHMASTER利用のZooKeeperを達成することです。、HBaseの実装では、ZKはテーブルの上に保存され、飼育係HRegionServerに登録されたいくつかのアドレスROOTのHMASTERアドレスは、一時的なノード（エフェメラル）にHMASTERはいつでも各HRegionServerの生存状況を知覚できるような方法を自分自身を配置します同時に、HMASTER問題と、このように一点HMASTERの問題を回避、HMASTERランに再選出されます

第六に、分散ロック

　　私たちは、データの整合性を確保するために分散ロックは、これは強いZooKeeperのが主な原因です。ロックサービスは2つのカテゴリに分類することができ、一方が他方には、タイミングを制御することで、排他性を維持することです。

1. 排他的な、いわゆるキープ、すべての試みがクライアントのロックを取得するために、そして最終的には一つだけが正常にロックを得ることができるということです。通常の練習はのznodeの方法を作成することによって達成されるロック、と見られてのznodeのZKの上に置くことです。ロックを所有しているクライアントの最終的な成功を作成/ distribute_lockノードを、作成するすべてのクライアント。
2. タイミングの制御は、すべてのビューがクライアントにロックを取得することで、最終的に実行するためにスケジュールされますが、グローバルタイミングアップがあります。そしてだけ/ distributelockすでに既存上記の慣行、と実質的に類似し、クライアントは（プロパティノードによって制御することができます。CreateMode.EPHEMERALSEQUENTIALは、指定された）注文した一時的なノードを作成し、その下。ZK親ノード（/ distribute_lock）従って、子ノードの作成のタイミングは、各クライアントのグローバルタイミングを形成することを保証するために、配列を維持します。

七、分散トランザクション