Javaの実用的な参照、次のメカニズムのZooKeeper各クライアントキュレーターの飼育係クライアントの詳細Javaの。
Http://zookeeper.apache.org/doc/current/zookeeperOver.html,http://zookeeper.apache.org/doc/current/zookeeperInternals.html公式文書では、ZKの内部の仕組みの一部を説明したが、十分ではありませんフレンドリーで詳しく説明。
飼育係について
公式サイトによると、ZooKeeperのは、分散アプリケーションのために必要なサービス、分散協調とパケットサービスセンターサービスを、命名、コンフィギュレーション情報を提供するために使用されます。実用的な観点からは、飼育係は、ダボ、カフカ、Hadoopの、ES-ジョブと飼育係が提供する分散協調および登録サービスにそれほど依存含む最も広く使用されている分散コーディネーションサービス、です。登録サービスを提供するためのその他のミドルウェアはまた領事とetcd、ユーレカが、広範囲ではないと飼育係が含まれます。
公式サイト：httpsを：//zookeeper.apache.org/,https：//zookeeper.apache.org/doc/r3.4.14/
コアメカニズム
飼育係のノードの役割
飼育係において、ノードは、以下の役割に分割しました：
- 世論調査や解像度を担当するリーダー（指導者）、システム状態、飼育係のクラスタ、一つのノードのみリーダーを更新します。
- フォロワー（フォロワ）と観察者（観察者）を含む学習（学習）。
- クライアントの要求を受け入れ、クライアントが望んでいる結果を返すためのフォロワーは、予備選挙の過程での投票に、飼育係のクラスタは、フォロワーは複数であってもよいです。
- オブザーバーは、リーダーに転送書き込み要求をクライアント接続を受け入れることができますが、観察者が投票プロセスに参加していない、唯一の同期状態のリーダーは、観測者の目的は、（選挙の複雑さを軽減し、投票に参加しない）、システムを拡張し、読み出し速度を向上させることです
1つの飼育係クラスタでは、ノード間の相互作用は次の通り：
注：ほとんどのミドルウェアに基づいて、すべての近代的な分散アーキテクチャは、カフカ、ESなどと同様の慣行に基づいています。
以上のことから、すべての要求は、クライアントによって開始され、またはそれがローカルzkCli Javaクライアントかもしれません。以下に詳細に各役割の責任。
盟主
リーダーの責務は、次のとおりです。
- データ復旧。
- ハートビートを維持する学習者は、要求を受信し、学習者の学習者の要求メッセージのタイプを決定し、
次のように図の模式リーダーワークフローは、実際の実装においては、3つのスレッドは、機能を実現し始めます。
フォロワー
フォロワー主な責務は以下のとおりです。
向Leader发送请求；接收Leader的消息并进行处理；接收Zookeeper Client的请求，如果为写清求，转发给Leader进行处理
フォロワワークフロー概略を以下に示すが、実際の実装では、フォロア関数は5つのスレッドによって達成されます。
次のようにメッセージの意味は次のとおりです。
PING：心跳消息。
PROPOSAL：Leader发起的提案，要求Follower投票。
COMMIT：服务器端最新一次提案的信息。
UPTODATE：表明同步完成。
REVALIDATE：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息。
SYNC：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。飼育係のデータ記憶機構
飼育係が使用するファイルシステム記憶機構が、しかし、すべてのデータがメモリに格納されています。その外国人は、UNIXのファイルシステムに似たビューを提供します。Unixファイルシステムに対応したツリーのルート・パスののznodeルートノード。
ノードタイプ
ZK（、データファイル格納フォルダであるデータレジスタとしても知られている）のznodeと呼ばれるノードに、それらのライフサイクルの長さは、永続的なノード（PERSISTENT）と一時的接合（はかない）に分けることができる。Shihaiを作成その経路飼育係サーバで複数のノードによって同一の親ノードの下に作成区別するためのシーケンス番号の系列を追加するかどうかを選択。
後に次の4つの組み合わせのznodeノードタイプがあります。
- 永続：永久のznode。
- はかない：はかないノードが子を許可しない、クライアントと一緒に自動的に削除閉じて、彼らはまだ、すべてのクライアントに表示され作成されます。それは、分散協調を実現するためのコアメカニズムです。
- シーケンシャル：に接続されたノードの2種類の特性を上述しました。あなたが作成すると、飼育係は、その名のシリアル番号が割り当てられます。グローバルに分散キューとして使用することができます。次のとおりです。
一貫性を確保する飼育係
飼育係は、一貫性を確保するために、以下のメカニズムによって実現しました：
» 所有更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
» 数据更新原子性，一次数据更新要么成功，要么失败
» 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的，基于所有写请求全部由leader完成，然后同步实现
» 实时性，在一定事件范围内，client能读到最新数据読み取りと書き込みメカニズム
» Zookeeper是一个由多个server组成的集群
» 一个leader，多个follower
» 每个server保存一份数据副本
» 全局数据一致
» 分布式读写
» 更新请求全部转发由leader完成，并在成功后同步给follower
客户端写请求的过程如下：
次のようにプロセスは次のとおりです。
- 1.すべてのトランザクション要求をハンドルにリーダーのサーバークラスタと呼ばれ、リーダーサーバが提案（案）へのトランザクション要求を変換し、世界的な増分のためのユニークなIDを生成しますが、このトランザクションIDは、すなわち、IDでZXID 、リーダー・サーバーの提案は、そのZXIDソートおよび処理するためです。
- サーバ後2. FIFO方式フォロワサーバに（各フォロワに対して別々のキューを割り当てるリーダー）各対応するキューに入れ、そして送信されたリーダーフォロワ提案を送信します。
- サーバが3.Follower提案トランザクションを受信した後、トランザクションログは、第1の実施形態のローカルディスクに書き込まれ、サーバーが成功した後にACK応答のリーダーを返します。
- 4.Leaderは、リーダー自身が提案の提出を完了しますしながら、長いフォロワーACK応答のサーバとして、それは、提案書を提出通知するコミットフォロワーにメッセージをブロードキャストするよう半分以上を受け取りました。
要求のそれぞれがリーダーと投票プロセスに転送する必要があるため、そのようなシーケンスジェネレータ、分散ロック、ノードの異なる数として、書き込みが集中飼育係のシーンに適していない、別の書き込みTPSの割合は、次のことをZK：
公式テストから。上記のテスト3.2,2Ghz Xeonプロセッサ、2ブロックSATA 15K RPMハードドライブに基づいています。別のログディスクには、OSのシステムディスクの書き込みのスナップショット、読み取りと書き込みのそれぞれ1Kのサイズを、クライアントが直接指導しません。そして上から、より多くのノード、低速の書き込みとは、より速く読み。
zkid
znodeノードステータス情報はczxidを含み、それはそれぞれの時間は、状態の変化、増加トランザクションIDに対応する、zxid呼ばID、ZKで？何であるかその後zxid。増分性質は以下zxid2よりzxid1場合zxidため任意のノードから任意のノードまたは更新データを作成するか、または任意のノードを削除zxid2、zxidの値の増加をもたらす、飼育係の状態変化をもたらすであろう前に、その後zxid1確かに起こります。
ノード情報のznode
znode構造は、Aノードのznode Getコマンド情報を取得することにより、二つの部分の記憶されたデータおよびステータス情報により支配され、以下の通りであります：
最初の行は、cZxidからのznodeステータス情報を始め、データのznodeに格納されています。znodeのステータス情報より、いくつかの主要なは次のようになります。
-
czxid：
ZXIDを作成したこと、それはのznodeノードのトランザクションIDの作成を表し -
mzxid：
すなわち変形ZXIDは、ノードIDを更新するために、最後のトランザクションを表します -
バージョン
のznodeノードのバージョン番号。バージョン番号が0の場合に、各更新されたバージョンは、につながる、各ノードが作成されるのznodeプラス1、更新前と更新は、バージョン番号が1増加される場合でも変わりませんした後に保存されたのznodeの値。イメージのバージョン値がのznodeを更新するノードの数として理解することができます。バージョン番号情報のznodeステータス情報サーバが同じのznodeの更新操作で同時実行制御複数のクライアントを行うことができるように。JavaとCASのようなビットの全体のプロセスは楽観的ロックの同時実行制御戦略であり、バージョン値は、衝突検出として機能します。クライアントのバージョンが情報のznodeを取得し、バージョン情報を添付し、サーバがのznodeを更新する際に、クライアントのバージョンとは、実際のバージョンのznodeを比較するときに更新する必要があり、場合にのみ、これらの二つのバージョンと一致して変更されます。
飼育係の他のコアメカニズム
- 飼育係は、原子放送の中核であり、この機構は、様々なサーバ間の同期を保証します。このメカニズムのプロトコル実装はザブ契約と呼ばれています。ザブプロトコルは、（マスタから選択される）リカバリモードとブロードキャストモード（同期）している二つのモードを有します。サービスを開始またはリーダーがクラッシュした後は、ザブは、リーダーが選出され、ほとんどのサーバーの同期と国家の指導者の後に終了したリカバリーモードに入ったときは、リカバリモードは終わりました。状態同期は指導者を確保し、サーバーは、同じシステムの状態を持っています。
- 業務の順序の一貫性を確保するために、トランザクションを識別するために増加トランザクションID番号（zxid）を使用して飼育係。すべての提案（案）をzxid時に追加することが提案されています。実装zxidがリーダーとの間の関係を識別するために使用される高32エポックは、リーダーが選出されるたびに変更されているである64ビットの数である、それは新しい時代、指導者の治世に属する現在のロゴを持っています。低カウントのため32。
- ：各サーバーは、自分の仕事の過程で3つの状態があり
LOOKING：サーバーが現在の指導者が探している人を知りません
LEADING：現在のサーバーが選出されたリーダーである
、次のリーダーが選出された、同期させるために現在のサーバーを
パクシ島のアルゴリズムを達成するために、分散システムの一貫性
パクシはこの原理に基づいたアルゴリズム：
• 在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。
• Paxos算法解决的什么问题呢，解决的就是保证每个节点执行相同的操作序列。好吧，这还不简单，master维护一个
全局写队列，所有写操作都必须 放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一
致性。没错，就是这样，可是如果master挂了呢。
• Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，
只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一
轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点接受了一个
编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己 数据
不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）
因此在生产中，要求zookeeper部署3（单机房）或5（单机房）或7（跨机房）个节点的集群。Javaの公式クライアントのコアパッケージの紹介を飼育係
- org.apache.zookeeper主のZooKeeperクライアントクラスを含み、かつ様々なZooKeeperのウォッチコールバックインターフェースを定義します。
- データレジスタorg.apache.zookeeper.data定義と関連するプロパティ
- org.apache.zookeeper.server、org.apache.zookeeper.server.quorum、org.apache.zookeeper.server.upgradeは、コアインタフェースサーバの実装です
- 4文字の言葉の主なカテゴリを定義org.apache.zookeeper.client
あまりにも非友好的な公式のJavaクライアントの飼育係の最後として、とても一般的なクライアントキュレーターで三者の実際の使用。そのため、クライアントは、この論文の最初の部分を参照して、詳細な分析をZooKeeperのキュレーターを説明していません。
時計のメカニズム
一回オブザーバー機構ノード（障害が発生した後すなわち、ワンショット、手動で時計を再作成する必要がある）のための飼育係を見て、データベースと同様に動作をトリガします。
時計を生成するデータを監視した場合、時計が通知クライアント、つまり、クライアントのウォッチャーを提供します。ウォッチャ機構は、データがいくつかの変更、イベント・タイプを有し、状態の対応するタイプが存在するであろう監視することで、クライアントノード限り、いくつかの新たなウォッチャーの数で生成されたコードに反映された複数のノードを監視することができ変更プロセスを存続します。次のようにどちらの図です。
znode関連および関連クライアントインスタンス：飼育係では、聞くことができる2種類のイベントがあります見て。それらは次の通りです：
- イベントの種類：（関連のznodeノード）は、[ノードのためにあなたが観察するものに関するものです]
- EventType.NodeCreated [作成]ノード
- EventType.NodeDataChanged [ノードデータの変更]
- EventType.NodeChildrenChanged [このノード変更の子ノード]
- EventType.NodeDeleted削除現在のノード]
- :(）に関連するクライアントインスタンスと[状態の種類は、アプリケーションサービスとのZooKeeperクラスタ間の変化の様子です]
- KeeperState.Disconnected [接続されていません]
- KeeperState.SyncConnected [接続]
- KeeperState.AuthFailed認証失敗[]
- KeeperState.Expired [期限切れ]
要約すると、ZK時計機能は次のとおりです。
- 使い捨て：ウォッチャーのZooKeeperについて、あなたは一つだけを覚えておく必要がある、イベント、ワンオフ時計はすべてのZooKeeperのモニタリングによるデータの変更、時計のクライアント通知の設定、そのウォッチャーを監視するときにトリガが見飼育係使い捨てなので、それぞれがモニターに設定する必要があります
- クライアントのシリアル実行：クライアントのウォッチャーコールバックプロセスは私達に順序を保証同期シリアルプロセスである、と開発者は、クライアント全体に影響を与えませんが、少しの注意を払う必要があるため、ウォッチャーコールバックのウォッチャーの処理ロジック
- 軽量：通知のステータス、イベントタイプとノード・パス：WatchedEvent通知部は、最小の全体のZooKeeperウォッチャー通知機構であり、全体の構造は、三つの部分を含んでいます。ウォッチャーは、ちょうどその具体的な内容なしイベントの発生が通知クライアントを教えて、クライアントがそのようなNodeDataChangedイベントとして、独自の買収を実行するために非常に簡単な必要があることを通知は、ZooKeeperのは、クライアント指定されたノードのデータが変更された通知されますしかし、直接特定のデータコンテンツを提供していません
選挙LEADERサーバ
選挙は、いずれの場合も、リーダーノード、初期クラスタ建物起こる;第二に、いずれにしても、リーダーは常に可能なダウンタイムが発生する可能性があります。次のように選挙プロセスにおける飼育係のリーダーは、次のとおりです。
クラスタサーバが他のすべてのフォロワーサーバーメッセージを送信すると、メッセージが投票用紙と呼ばれる視覚化することができ、投票は（デジタルMYIDファイルに設定されている）選出されたIDリーダーサーバで構成される二つの主要な情報で構成されていそして、サーバーのトランザクションIDは、トランザクションは、サーバ、大規模トランザクションのサーバーID、より多くのそれの新しいデータの状態を変更する操作を示します。次のように全体のプロセスは、次のとおりです。
- キャスト投票（SID、ZXID）、へ1.Followerサーバ初めて各フォロワーは各フォロワー最初の投票は、そのサーバIDとトランザクションIDを追い出されていることを意味リーダーサーバ、として自分自身を選出します。
- 2.それぞれのフォロワーは、それが次の規則に基づいて投票用紙を再生成します、他のフォロワーからの票を受け取ります：得票の比較とそのサイズZXIDを、そして最大のいずれかを選択します。あなたはZXIDと同じであるSIDを選択した場合サーバID最大。各サーバは、最終的に投票用紙を再生成し、投票用紙を追い出します。
サーバーのいずれかが、より多くの票の半分以上を得た場合、投票のように多くのラウンド後、それはリーダーとして選ば紹介します。上記の分析から、飼育係のクラスタは、それらのよりZXID、すなわち、データ更新のマシンに有利になるように偏った、リーダーサーバの偏った選択をしています。
全体のプロセスを以下に示します。
そこでここでは、実際に簡素化、プロセスの詳細については、最終的な合意がさらに精緻（その後のサプリメント）を必要としています。
回復
サーバー障害によるデータ損失を回避するために、トランザクションログとデータのスナップショットによって飼育係。この時点の取引メカニズムを使用して、すべてのストレージの実装では、達成するためにWAL +再生メカニズムを使用して、同じです。
- トランザクションログは、リーダーとフォロワーのサーバは、トランザクション・ログを記録し、メモリのデータを更新する前に、ディスクに書き込まれたオペレーションのトランザクションログに最初のサーバーを指します。
- 木構造データメモリモードの深さによって横断されたスナップショット周期データは、外部メモリのスナップショットに転送されます。しかし、スナップショットを作成するときに、メモリデータが変更された可能性があるため、このスナップショットは、「ファジー」であることに注意してください。トランザクション自体飼育係の操作が冪等の保証を行っているのでしかし、スナップショットデータがメモリにロードされているので、後にトランザクションログの用語の実行の仕方によって最新の状態に復元されます。
権限システム
ACL認証飼育係のメカニズム、および関連統合は、参照する飼育係ACL認証メカニズムとダボ、カフカ統合、zooviewer /アイデアZKプラグインの設定を。