飼育係さんのプロフィール
飼育係は何ですか
-
ZooKeeperのは、Googleのぽっちゃりのオープンソース実装である、ビッグデータは、生態系の重要な構成要素である、分散アプリケーションのための分散、オープンソースのコーディネーションサービスです。これは、クラスタ・マネージャであり、合理的なフィードバックの提出ノードに応じて次の動作のためにクラスタ内の各ノードの状態を監視します。最後に、簡単には、ユーザにシステムのインタフェースで効率的な性能、機能及び安定性を使用します。
-
分散アプリケーションのミドルウェアのための協調的なサービスを提供するために、一貫性のあります
ZooKeeperのは、何を提供します
- ファイルシステム
- マルチレベルの名前空間ノード（ノードと呼ばれるのznode）を提供飼育係。そして、ファイルシステムが異なっているこれらのノードがあることを、関連するデータを設定することができ、およびファイルシステムがデータファイルだけのノード・ディレクトリーのノードを格納することができますすることはできません。飼育係は、このツリーのディレクトリ構造のメモリ内に維持低レイテンシと高スループットを確実にするために、この特徴は飼育係が行う大量のデータを格納するために使用することができない、データの上限を格納する各ノードは、1Mで。
- 通知メカニズム
- クライアント側は、のznodeを確立するウォッチャーイベントときのznodeが変更されると、クライアントはこれらのZKが通知され、クライアントはのznodeの変化に応じてサービスに変更を加えることができ、。
分散システムとは何ですか
-
多くのコンピュータは、全体の全会一致と同じリクエストを処理し、全体を形成します
-
各コンピュータは、互いに内側（REST / RPC）と通信することができます。
-
リクエストの終了に応じて、サーバーへのクライアントは、複数のコンピュータを受けます
-
別紙1
-
別紙2
分散システムの問題点
-
動的サービス登録と発見、（書き込みには、設定ファイルで死亡）、高並行性をサポートするために、OrderServiceのが4配備されては、各クライアントは、サービスプロバイダのリストを維持しますが、このリストは静的ですサービスプロバイダは、例えば、いくつかのマシンをダウン変更されている、またはOrderServiceの例を追加した場合、クライアントは非常に、手動で設定ファイルを更新する必要があり、URLのサービスプロバイダの最新リストを取得したい、知りません。便利。
-
質問： 密結合クライアントとサービス・プロバイダー
-
ソリューション： -デカップルは、中間層を追加 登録センター提供できるサービスを保持している名前を、とのURLを。これらのサービスの第一は、クライアントのクエリは、名前だけを与えるとき、レジストリはURLが与えられます、レジストリに登録されます。サービスにアクセスする前に、すべてのクライアントは、あなたがする必要があり、登録センターの最新のアドレスを取得するには、尋問のために。
-
レジストリツリー構造であってもよいし、各サービスは、以下のいくつかのノードを有し、各ノードは、サービスのインスタンスを表しています。
-
ハートビートを例とみなされていない特定の時間には、インスタンスを削除し、ハングアップしたら、レジストリや様々なサービスインスタンスが直接セッションを確立し、要求されたインスタンスは、定期的に送信ハートビートでした。
-
-
ジョブコーディネーション
-
3台の異なるマシン上に配備仕事同じ3つの特徴は、ケース、残りの二つが選出する必要一顧がある場合にのみ、1であることが、実行できることが必要
Masterな作業を続けます
-
仕事だから、互いに協調するために、これらの3つの必要性
-
使用する共有データベース・テーブルを。私たちは、マスターが誰であるか成功した表の中に同じデータのインサート3つの仕事をできるように、データベースの主キーの競合を知ることができません。欠点は、仕事グラブマスターは、常に存在するレコードをハングアップした場合、他のジョブのデータを挿入することができないということです。それは定期的に更新するためのメカニズムと結合されなければなりません。
-
行き、開始後に仕事をしてみましょう登録センター（マスターで成功したツリーノード、作成、ある登録、登録センターは成功は一度だけ作成することができますを確認する必要がありますが）。
-
したがって、ノードが削除された場合、戦いの新しいラウンドを開始しました。
-
-
-
分散ロック、複数のマシン上で実行している別のシステムは、同じリソースを操作します
-
あなたが作成つかむことができるの使用マスター選択方法、誰もトライを盗むために聞かせて、
/distribute_lockノードを、それは私たちが戻ってグラブに来るように、読んだ後に削除されます。欠点は、システムが繰り返し、公正十分をつかむかもしれないということです。 -
したがって、各システムレジストリという
/distribute_lock子ノードの下に作成されたが、その後、番号、各システムは、次の図のように、ロックを保持している少数のロックシステムを保持していると思う自分の番号を、確認してください
-
システム動作が完了したら、削除process_01入れ、その後、新しいノードprocess_04を作成することができます。思考システム2がロックを保持しているので、この時点でProcess_02は、最小です。
-
操作が完了したら、それはまた、process_02削除ノードは、新しいノードを作成する必要があります。この時間process_03が最小である、あなたがロックを保持することができます。
-
-
可用性レジストリ
- 登録センターは、システム全体の一顧を切った、ということだけでマシンの場合。だから、複数のマシンの必要性は高い可用性を確保します。こうした複数のマシン間で同期させるツリー構造のニーズなどの新たな問題が、このリードは、通信が機械に強い木構造間の整合性を確保するために、どのように行う方法をタイムアウトしました。
飼育係の役割
- 選挙のマスターノードマスターノードがダウンした後、それはノードから仕事を引き継ぐ、これはいわゆるサミットモードでのみノード、であることを確認し、我々は高可用性クラスタであることを確認するようにします
- 統合管理コンフィギュレーションファイル、すなわち、必要が単一のサーバを展開するために、同じプロファイルが雲によって特に動作中、他のすべてのサーバに対して同時に更新することができる（例えば、修飾された均一な構成はRedisの）
- 公開し、メッセージキューに似たデータを、サブスクライブMQ
- マルチプロセスのロックに似た分散ロック、分散環境、異なるプロセス間でリソースの競合、
- クラスタの管理は、クラスタ内のデータの強い一貫性を確保するために、
飼育係の特徴
- 一貫性：一貫性データ、バッチで順に蓄積データ
- アトミック：Aトランザクションがどちらか成功するか失敗します
- シングルビュー：ZKクライアントはクラスタ内の任意のノードに接続するには、データが一致しています
- 信頼性：ZKの動作状態がサーバー上に保存されるたびに
- リアルタイム：クライアントは、最新のサーバー側のデータZKを読むことができます