ZooKeeperの私たちは、ほとんど聞いたことがあるはずです、あなたが直接開発に使用することはできませんと思いますが、一般的にHadoop、HBaseの、カフカ、ダボと他の人がZooKeeperのを使用する必要が使用されます。最後にZooKeeperのZooKeeperのそれを使用する必要が果たしたどのような役割、なぜこれらのフレームワーク、システム、どのように我々は、開発プロセスでのZooKeeperを使用し、ZooKeeperのそれの選択肢があるかどうかべきです。この記事では、次の3つの側面を開始し、これらの質問に焦点を当てます。
- 起源と役割。
- クラシックシナリオ;
- 代替。
1.起源と役割
何ZooKeeperの最初に設計されたのですか？これは、およそYahooの話から、研究チームです。その際、Yahooの中に発見の研究者が連携を分散分散型のシステムコンポーネントに依存する必要性をたくさん持っているが、これらの成分の存在は、多くの場合、シングルポイントの問題を配布しています。Yahooがされるように、組織が開発されていない一点問題で配布さの調整のための共通の枠組みのZooKeeper、決済され、シングルポイントのを、一方で、されるコーディネートを分散分散システムからは引か開発を可能にし、アウトビジネスロジックに集中。
ここで、「一点の問題」と「分散協調」には言われました。
1.1シングルポイントの問題
（また、単一障害点として知られている、障害、SPOFの単一のポイント）一点問題システム全体の故障コンポーネントを動作しません一度システムを指します。例えば、システムは、唯一のマシンAに障害が発生した場合、システム全体が機能しません、マシンAマシン上に展開されます。マシンの数が同時に失敗しない限り、システムが適切に機能するように、この問題を解決するために、一般に、マシンの数を増やすことは、冗長な方法で使用されます。
ZooKeeperのは、クラスタの単一の点によって問題を解決します。一見クラスタ、シングルポイントの問題を解決することができ、いくつかのマシンよりも多くの展開の仕方によって。まず、我々はに精製の単一のポイントを発行する必要があり、一点のステートレスと国家の問題の一つのポイント。ここで状態は、ネットワークプロトコル、HTTPのステートレスプロトコルの概念の存在または非存在を指すことができることを、各リクエストは独立しており、TCPステートフルプロトコルは、信頼性の高い伝送が記録状態に依存完了する。
単純なステートレス一点問題がクラスタ、例えば、フォワードプロキシノード行うためのメッセージを用いて解決することができるため、以下に示すように、それは、何の状態ではありません。
メッセージ転送Xサーバがダウンしている場合は、同様に、サーバYは、正常に動作し続け、そしてマシン高可用性のより多くの数になります。
状態、同じ、と私たちは直面することになるではないため、分散整合性の問題を。一人でこの問題は、単にマシンを解決することはできません追加しています。一般的な解決策は次のとおりです。
- 状態に移動：ステートレスの問題が除去される、例えば、DBの信頼性の高いストレージ状態に。
- マスタとスレーブ：プライマリデータ処理の状態は、マスターコピーから、書き込み動作処理マスタ、よだれバイナリログ同期状態によってMySQLのようにマスター、マスタ同期よだれを行います。
MySQLのソリューション、およびZooKeeperのZABするには、上記の簡単な紹介は、強い一貫性を達成するために使用されるプロトコルです。この問題に関するコンセンサスを分散、我々は説明していきません、誰もが最初に覚えているだろう強い一貫性を確保するために、単一ポイントの問題を解決するためのZooKeeperをデータの不整合が生じZooKeeperのクラスタマシンのダウンタイムがあるので、心配しないでください。
問題の単一のポイントを経由チャット、ZooKeeperのに必要とされている以下のチャット、下の分散協調が役割を果たしています。
1.2分散コーディネーション
分散環境での文字通りの意味、協調と連携、その意味を配布しました。例えば、一つのケースでは、同時に複数のスレッドがこのような在庫から1を引いたものとして、リソースへの変更を行うにしたい場合。精度を確保するために、我々は、このリソースをロックします。しかし、分散の場合には、複数のマシンがリソースを変更する場合、どのように我々は、このリソースそれをロックしていますか？今回は必要なコーディネータが発生します。あなたが他のマシンがロックされていないマシンをお知りになりたい場合は、だけでなく、ロックがコーディネータによって管理されていることを、他のマシン、通信の単純コーディネーターと通信する必要はありませんし、リソースのロックを知ることができます。
あなたはコーディネーターとして飼育係すべき理由、なぜクラスタ内で直接マシンを選択しないと言うかもしれません。はい、もちろんすることができます、しかし、あなたは（マシンのダウンタイムのコーディネーターとして）単一ポイントコーディネータの問題を解決する必要がありますの。そして、分散システムなぜなら、主に、このようなコーディネーター・コンポーネントを必要とし、再利用するためには、それを取り出し、これがあるだろう、分散協調システム。したがってダボ、Kafakや他のフレームワークはのZooKeeperそれらの使用、そうコーディネーターを達成するためのコンポーネントを繰り返す必要はありませんに直接配布さ実装する場合。そして、プログラマは、我々は唯一の分散開発で達成するために、ビジネスロジックに集中する必要があります。
要約の下では、ZooKeeperのの役割は、分散サービスの連携の問題のない単一のポイントを提供していないです。
2.古典的なシナリオ
このセクションでは、ZooKeeperの使用方法を最後に見てZooKeeperの古典的なシナリオをいくつか説明しますが、最初のZooKeeperのデータモデルに必要な、ノード特性、ウォッチャーメカニズムはいくつかの知識を持って、次のように簡単になります。
2.1のZooKeeper基礎
データモデルが何であるか、データが格納形式として理解することができ、以下に示すように、例えばRedisのキーは、データの形式で格納され、ZooKeeperのツリーです。
ルートノード名であることを特徴と「/」は、ルートノードは、「A」は、「X」、「Y」、「Z」3つのつの子ノードがあり、「A」と「B」2つのつの子ノードを有しています。私たちは、ツリーノードを使用すると、ファイルシステムが少し気持ちのようである、ノードにデータを保存することができ、必要に整理することができます。
データモデルの基本的な理解では、また次のノードの特性を知っておく必要があり、4つのノードは、よく理解されている、があります。
- 永続ノード：イニシアチブは削除しない限り持続します作成。
- ノードの順序ラスティング：その永続性と永続的なノードを、それはシーケンシャルがあり、プラスの数値サフィックスノード名は...、彼らが作成した順序を示し例えば、1,2,3,4;
- 一時的なノード：ノードに障害が発生したことをセッションを作成する場合は、そのノードが削除されます。
- 時間的順序ノードは：オーダーの概念の一時的な増加をノード。
最後に、ウォッチャーの仕組みを知って、我々はデータノードの内容の変化を監視することができ、感知機構である私たちがイベントを監視すると、サブノードの変更は、ZooKeeperのは、私たちに知らせます。
このセクションのトピックへ次のエントリへのZooKeeperいくつかの基本的な紹介。
2.2データのパブリッシュ/サブスクライブ
よるウォッチャーメカニズムデータは、パブリッシュ/サブスクライブのために。一例として、中央シナリオを構成します。ZooKeeperの及び他のマシン上のノードに設定を公開することは、動的にモニタZooKeeperの上のノードに設定変更を更新することによって達成することができます。例えば、我々はデータベースの設定に「/ CONFIGSERVER / APP1 / database_config」ノードを入れ、その後、各マシンが起動時にノードからデータベース構成情報を取得するために聞かせて、コンテンツノードにおけるモニターの変更時に、設定の変更が発生し、構成を取得。
2.3ネーミングサービス
よるZooKeeperのノード順グローバルに一意なIDを生成します。例えば、分散タスクスケジューリングシステム、タスクのためのグローバルにユニークなIDの生成は、次のように：
タスク名の配列ノードユニークIDを作成した後、例えば、「TYPE1ジョブ-000000003」、スプライスのノード名によって得ることができます。
2.4クラスタ管理
ZooKeeperの一時的なノードとウォッチャー機構クラスタの動作状態を監視するために、次のように：
新しいマシンがクラスタに追加する場合、「機械」の下で、一時的なノードを作成します。マシンがダウンすると、一時的なノードを削除する失敗します。サーベイランス「機械」の下の子ノードの変化によって、我々は、クラスタマシンの状態を知ることができます。
2.5分散ロック
分散ロックは、二つのカテゴリー、排他ロックと共有ロックがあります。
トランザクションリソースのロック時の排他ロックは、他のトランザクションが読み書きすることはできません。一時ノードの下に示すように、ロックを表現することができるであろう。
「resourceA \ exclusive_lock」の「ロック」ノードの確立ノードは排他ロック上のリソースを表します。複数のマシンが「exclusive_lock」の下に「ロック」ノードを作成しようとすると、唯一の成功があるだろう他の人がマシンは変更の「exclusive_lock」子供を聞きます失敗しながら、作成することができます。ロックが積極的にまたは下にリリースされると、「ロック」ノードが削除されますが、他のマシンに通知し、ロックを獲得するために「ロック」ノードを作成しようとしていきます。
読書のために他のトランザクションが可能、トランザクションリソースのロック時にロックを共有しました。静止画データの内容を読み取り、書き込み、読み出しと書き込みとを区別する必要がノードによって表されてもよいということである、例えば、Rは、読み出し動作を表し、Wは、書き込み動作を示すノードロック差で表されます。下図のように：
読み取りおよび書き込み操作を「shared_lock」ノードの「ロック」を作成すると呼ばれているノードの中間順序が、異なるデータ内容。数が少ない場合、読み取り操作については、ご自身の子ノードは、書き込み操作に含まれるノードの数が少ないが、待つ必要がある場合は、読むことができる、彼は成功したロックを取得したと考えて、読み取り要求されている息子「shared_lock」のを聞くよりも、ノードの変更。書き込み操作のために、彼らは変更の「shared_lock」子供を聞いて待機中の子ノードの最小数は、されていない場合。
3.選択肢
第2節で、我々は分散ロック、クラスタ管理と他の機能を実現するためのZooKeeperを使用する必要はありません、分散環境での多くのシナリオがあるのZooKeeperについて学びましたか？もちろんない、から選択する他の技術があります。例えば、Redisのは、分散コーディネーションサービスに使用することができ、達成することができる、これらのシーンの第二に言ったが、その理由は、異なるデータモデルの異なる設計が必要になります。
私たちは、ZooKeeperのか、Redisのそれを使用すること？シーンに応じて決定される。このニーズは、我々は分散ロック・シーンの両方の長所と短所でダウンコントラスト：
- Redisの高同時実行をサポートし、ロック操作を解除し、データの整合性の問題が発生する可能性を100％保証することはできません（まれ）。
- ZooKeeperの：ロック堅牢なモデル、強い一貫性、頻繁なアプリケーションロックは、大きな動作して圧力のZooKeeperクラスタのロックを解除します。
Redisのデータの一貫性は、Redisのように良いと高い同時実行をサポートするためのZooKeeper、およびZooKeeperの優れています。
最後には、紹介したいのeCTD、これは、高可用性、キーと値のストレージ・システムであり、囲碁の書き込みを使用して、コピー、ログがKubernetesシステムで使用される処理筏アルゴリズムによる強い一貫性を保証するであろう。ZooKeeperの言葉と比較すると、多くの異なる技術的な詳細がありますが、私はいくつかの幅広いをあげる、ZooKeeperのは当然のことながら、このようなGCの一時停止などのJava、という欠点を持っていますが、何の問題GCの一時停止をeCTDのない、Javaベースの実装です。優れたJavaクライアントライブラリを持って飼育係、それはまた、他の言語での新星としてのeCTDをクライアントライブラリを提供し、何も良いのJavaクライアントライブラリが存在しない、それだけでHTTP経由で呼び出すことができます。
Redisのは上記のみのヘルプ読者に隠蔽されていないECTD、のZooKeeperに限定されません。そして、具体的な技術選択を行うためにどのように、彼らはまだ言っていない、経験が不足しています。
4.リファレンス
- 「パクシからのZooKeeperへ」
- なぜZooKeeperの
記事のジュニアパートナーのような私は、あなたは国民の関心は私のコード番号の下に掃引することができます：「草の子ピンチ」