まず、どのような飼育係その？
ZooKeeperのクラスタ・マネージャであるオープンソース分散コーディネーションサービス、モニター提出フィードバックに基づいて、クラスタノードの各ノードの状態であり、次のステップは、合理的な操作です。最後に、簡単には、ユーザにシステムのインタフェースで効率的な性能、機能及び安定性を使用します。
こうした/サブスクライブ飼育係の実現の下でリリースされたデータ、負荷分散、ネームサービス、分散協調/通知、クラスタ管理、マスター選挙、分散ロッキングおよび分散キュー機能などの分散アプリケーション、。主な用途：単一障害点を解決します。
飼育係は、次のような特徴の一貫性を確保するために配布さ：
- シーケンシャル一貫性：クライアントからの更新は、クライアント・プロセスによって送信された順序に厳密に従うものとします
- 原子性：更新または成功したか失敗したか、部分的な成功、またはシーンの一部の障害が存在しません
- シングルビュー：クライアントが見るために、サーバーに接続するに関係なく、同じ図であり、
- 信頼性：更新を有効にすると、それは再び更新されるまでそこに残ります
- リアルタイム：時間の特定の期間内に、任意のシステムを変更するには、クライアントによって見ることができる、またはを聞いています
クライアントの読み取り要求は、任意のマシンのクラスタで処理することができます。同時に他のマシンと飼育係の合意に送信されます書かれた要求については、要求が成功を返します。したがって、増加飼育係クラスタマシンと、増加するが、減少するスループット書き込み要求スループット要求を読み取ります。
秩序は、飼育係の非常に重要な特性である、すべての更新が発注したグローバルで、それぞれの更新は、ユニークなタイムスタンプ、zxid（飼育係トランザクションID）と呼ばれるタイムスタンプを持っています。しかし、唯一のある整然とした更新する読み取り要求、に関して、読み取り要求は、最新のzxid飼育係で結果を返します。
第二に、共通APIおよびコマンド
1.API
作成/パスデータ
の削除/パスが
存在する/パス
のsetData /パスデータ
のgetData /パス
GetChildrenメソッド/パス
Javaの：参照Apacheのキュレーター（ネットフリックス、オープンソース）、またはZK zkClient来る
ネイティブZKに基づいてクライアントをパッケージ化するための学芸員の枠組みを、ZKが提供するようなシナリオで、さまざまな：分散ロック、クラスターリーダー選挙、共有カウンタ、キャッシング、分散キュー。
：主に使用ZKの複雑さを低減するために以下の態様からキュレーター
リトライメカニズム：すべての捕捉回収異常（後で話す）の戦略は、いくつかの内部標準（指数関数を提供する再試行再試行戦略に構成される補償）
接続状態が監視：状態変化が適切な治療作るいったん初期化後のキュレーターは常に、ZKリスニングに接続される
ZKクライアントのインスタンスの管理を：必要なときキュレーターは、クライアントからサーバーへの接続のクラスタ管理と復興ZK ZKますたとえば、クラスタ接続信頼性のZK。
2.コマンド
開始：./ zkServer.shが開始
ZK動作状況を確認する：./ zkServer.shステータス
クライアント接続がZK：./zkClis.sh
LSを：ビューが
取得：ノードデータを取得し、更新
cZxid：上記のid上記ノードの作成
CTIMEを：作成したノード
mZxid：上記のidを超えるノードを変更する
ノードの変更に時間：ファイルのmtime
pZxid：IDの子ノード
cversionを：バージョンの子はノード
dataVersionを：ノードデータの現在のバージョン
aclVersion：バージョン権
ephemeralOwner：一時ノードかどうかを判断するために
データ長：データ長
するnumChildren：子供の数はノード
STAT：取得ノードの更新は
-e作成：一時的なノードを作成
-sを作成：注文ノードを作成
、削除：削除/パス
のstatパス時計：時計イベントを設定し
、時計イベントセット：パスの時計を取得
第三に、典拠コントロール飼育係
ACLアクセス制御：
ZKは5つの操作する権限がありますノード：CREATE、READ、WRITE、DELETE 、ADMINは削除、追加、あり、変更、検索、権限を管理、crwda（すなわちと略記5つの権限：最初の各単語を文字の略語）。
注：これらの5つの権限、削除権限が子ノードを削除するには指し、権利の他の4つの種類には、独自のノードの操作権限を指し、
アイデンティティ認証4つの方法があります。
- 世界：デフォルトモード、全世界の缶アクセスの同等
- 認証：ユーザーの代表は、（addauthダイジェストユーザーがCLIことができます。現在のコンテキストPWDに許可されたユーザを追加する）によって認定されています
- ダイジェスト：つまりユーザー名：この方法でパスワード認証、最も一般的に使用される業務システムであります
- IP：使用してIPアドレス認証
コマンドを：
GETACL：ノードへの適切な情報を取得する
SETACL：権限を設定
四、のznodeノード
- 永続的なノード
- 一時的なノード
- 注文した永続的な
- 一時的には注文
に作成され、アクティブノードを削除するには、削除操作があるまでは、いわゆる永続的なノードは、ノードを指し、それが存在する-ノードは、クライアント・セッションが消えて失敗し作成されません。
ノードタイプ上、このようなノードの基本的な特性は同じです。その他の機能があり、ZKに、各親ノードは、彼の最初のレベルの子ノードのタイミングを維持し、順序が作成され、それぞれの子ノードを記録されます。この特性に基づいて、子ノードを作成するときに、あなたは、そのノードの作成プロセスをこのプロパティを設定することができ、ZKは自動的に新しいノード名として、数値サフィックスを持つノード名が与えられます。この図の範囲は、最大の整数の接尾辞です。
そして、持続的なノードが異なり、クライアント・ノード・セッションのライフサイクルは、一時的な結合します。クライアント・セッションが失敗した場合、つまり、そのノードが自動的に削除されます。なお、ここで言及したセッションフェイルオーバーではなく、切断。また、あなたは一時的なノードに子ノードを作成することはできません。
ライフサイクルとクライアントのセッションは一時的なノードのバインディング。クライアント・セッションが失敗した場合、つまり、そのノードが自動的に削除されます。注作成したノードは自動的に番号を追加します。
データハイスループット、低遅延、また証明ZKファイルノードがデータを保存するために大きすぎてはならないので、メモリに保存されています。
第五に、監視と通知
1、ポーリングビュー
2、ウォッチャー機構
図1-1 2の複数のネットワークのオーバーヘッドを低減させるこの機構飼育係、。
図1-2に配置されたモニターポイント時計プロセスである：
1：クライアントにおけるC2モニタ変化接続はC1 /タスクはタスク1ノードディレクトリインクリメント順序付けリスニングで作成された後、
2：C2通知時計受信
ZKにC2：3登録/タスク再び
質問：第3工程と、c3の後に新しいクライアント接続がある場合は、新しい時計のC2のノードを追加するには、新しいタスク/タスクを追加するために、クライアントC2は、この変更を欠場するものではありませんか？
回答：ステップ3でノードする新しい時計を設定する前に次の状態を読み取るために
注：常に成功していない、単一のイベントを見て、一つのイベントにいくつかの変更を監視するようにしてください、時計は専用メモリに保持され、ハードディスクに保持されません、クライアントとサーバーが切断され、時計をリセットする必要があります
ノートにウォッチポイントを使用します：
- 時計は1回通知され、登録が繰り返されなければなりません。
- CONNECTIONLOSSが発生した後、限り接続としてSESSION_TIMEOUT以内に再度（すなわちのsessionExpiredが起こらない）を、接続はまだ時計に登録されています。
- バージョンノードデータ変更トリガは、このバージョンは、特に変更を記述していること、ノートをNodeDataChanged。ケースには関係なく、内容は前と同じであるとNodeDataChangedをトリガーするかどうかの、限りのsetData（）メソッドの実装を成功として、があります。
- ノードの時計のためにサインアップしますが、削除されたノードは、その後、削除されます。このノードの時計に登録。
- ZKは1つのノードが登録され、同じ時計上のクライアントで、あなただけの通知を受け取ります。
- Watcher对象只会保存在客户端，不会传递到服务端在，具体流程上，简单讲，客户端在向 ZooKeeper 服务器注册 Watcher 的同时，会将 Watcher 对象存储在客户端的 WatchManager 中。当ZooKeeper 服务器触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatchManager 的实现类中取出对应的 Watcher 对象来执行回调逻辑。
六、版本与运行模式
版本控制并发
举例：Client1和Client2每次setData后，会保存服务器的版本号在客户端，下次变更会携带版本号，两个调用以版本号作为传入参数，只有传入参数和服务器版本号一致，才能变更(CAS)
Zookeeper两种运行模式：
独立模式、仲裁模式
仲裁模式下有法定人数的概念，一般最少设置为（n/2+1）后续讲解
七、会话
セッションは、ZooKeeperのサーバおよびクライアントのセッションを指します。ZooKeeperのでは、クライアントとサーバのTCP接続長とのクライアント接続を指します。クライアントが起動すると、最初のサーバとのTCP接続を確立すると、最初の接続は、クライアントセッションのライフ・サイクルの最初から始まっ確立されています。この接続を介して送信することができ、クライアントは要求のZooKeeperハートビートによって、サーバーとの有効なセッションを維持することができ、また、ウォッチは、接続を介してサーバからのイベント通知を受信している間、サーバーは、応答を受け付けます。セッションSESSIONTIMEOUT値はタイムアウトクライアントセッションを設定するために使用されます。サーバー、ネットワーク障害またはクライアント割り込み接続、およびクライアント接続の他の原因に指定された時間内に限り、失われているため、あまりにも多くの圧力は、クラスタ内のすべてのサーバ上で再接続できSESSIONTIMEOUTたら、前に作成しますセッションがまだ有効です。
あなたは、クライアントのセッションを作成する前に、サーバは、最初のクライアントごとにセッションIDを割り当てます。セッションIDは、セッションセッションID操作機構に関連する多くはこれに基づいて、飼育係のセッションを識別することが重要であるので、サーバはクライアントセッションIDに割り当てられているどんなにので、グローバルに一意性を保証することを確認しています。
セッションのライフ・サイクル：
タイムアウトために、クライアントとサーバーの場合、クライアントはSESSIONTIMEOUTまで接続のまま。セットSESSIONTIMEOUT =トン、その後、時間T / 3で、クライアントが再接続し、それが失敗した場合、2トン/ 3の時に、他のサーバを探します場合は、接続してみてください。
サーバーへの新しい接続のステータスは、元のサーバーの背後にすることはできません。だから、zxid背後を使用するかどうかを決定します。
