1、飼育係のデータモデル
同様のデータモデル、データ構造ツリーを飼育係。
ツリーはノードで構成され、飼育係データストレージは、ノードに基づいて、このノードが呼び出されているのznode
しかし、ノードツリーとは異なる、のznode参照はファイルパスに同様の参照パス、です。
/动物/猫
/汽车/宝马
このような階層構造は、各ノードが固有のパスのznodeを有するように、わずかに異なる情報を同じ名前空間明確な分離を行います。
2、のznodeは、どのような要素が含まれていますか？
- データ：データストレージのznode。
- ACL：アクセスのznodeレコード、であるか、どのようなこのIPノードにアクセスすることができます。
- STAT：のznodeは等トランザクションID、バージョン番号、タイムスタンプ、サイズなど、様々なメタデータを含みます
- 子：現在のノード参照の子
：注
小さなシーンのデザインを読み書きのための飼育係。
znodeは、大規模なビジネスデータを格納するために使用されていないが、ストレージの少量のため**状態及び構成情報、各ノードの最大データ**は1メガバイトを超えることはできません。飼育係は、一貫性のあるものの、データベースとして使用されるのを避けるために。
3、飼育係の基本的な操作
ノードを作成します
create
[ノードの削除
delete
ノードがあるかどうかを確認
exists
ノードのデータを取得します
getData
ノードのデータを設定します
setData
ノードのすべての子ノードを取得します。
getChildren
これらの中で、それが存在する、のgetData、GetChildrenメソッドは、操作が属する読みください。
しかし、ビジネスや一回の書き込み操作のフックと、となりますトランザクションは関係生成。
読み取り操作を要求するとき飼育係のクライアントは、あなたが設定するかどうかを選択することができますウォッチ
4、取引の飼育係通知
ウォッチのznodeが引き金に登録された特定として理解することができます。
作成、削除と呼ばれているこののznodeの変更、のsetDataメソッドがときのznodeに対応するイベントの登録をトリガーする場合は、ウォッチは、クライアントの要求は、非同期通知を受け取ることになります。
5、飼育係の一貫性
分散システム連携サービスとして飼育係、そのハングそれに対処する方法の場合は？
スタンドアロンのハングを防ぐために、飼育係は、クラスタを維持します。（故障の単一点）
飼育係クラスタサービスはマスターマルチスレーブ構成。
場合、更新データは、まず更新するメインSERVIC飼育係 E、再同期から-サービス飼育係を。
データの読み出し時に直接読みいかなるから-サービス飼育係を。
飼育係用いて、マスタノードからのデータの整合性を保証するために、ZABプロトコルを、このプロトコルは、一貫性のPaxosアルゴリズムラフトと非常に類似しています。
6、ZAB契約
放送飼育係（飼育係）アトミック原子）（放送、配信、送信）、
効果的な溶液飼育係クラスタクラッシュ回復、ならびにデータのマスタ-スレーブ同期の問題。
ZABプロトコルは、三のノードの状態を定義します
- 探している相手：状態の選挙を。
- 以下の：フォロワーは、ノード（スレーブ・ノード）を述べます。
- 大手：リーダーノード（マスターノード）の状態で
ZABプロトコルは、強い整合性も弱い一貫性もあるが、両者の間で非単調性（シーケンシャル一貫性）。
それはに依存しているトランザクションIDとバージョン番号、更新を確保するために、リードデータがされて注文に。
7、飼育係のクラスタのクラッシュリカバリ
（マスタースレーブRedisのレプリケーションに似ていますが、同様の）
主な飼育係サーバー飼育係の吊りクラスタ場合、クラスタは回復をクラッシュします。
ある1、選挙相は、すべてのサブ飼育係サーバーは投票を取ります。（この時点で、すべての状態の子サービスを探しています：国家選挙を）
サブ飼育係サーバーの半分よりも大きい2票を、リーダーのリーダー、（大手：リーダーノード（マスターノード）での状態）になって、他の子のサービスは、フォロワーのフォロワー、（次のとおりでノードの状態からフォロワノード（））
3、他のサブサービスからサービスのリーダー、発見のための見て、最新のZXIDおよびトランザクションログを。そして、自分自身を更新します。
4、取得した歴史的なトランザクションログのちょうど最新コレクション、クラスタのすべてのフォロワーへの同期のリーダー。半分しかフォロワーの同期が成功し、準リーダーは、公式のリーダーになること。
