** zookeeperは主に分散システム、ESクラスター、分散ファイルシステム、mysqlマスター/スレーブレプリケーションにサービスを提供します。主に同じノードで機能しない
ことは分散システム分散システムと呼ばれます。これはハードウェアまたはソフトウェアコンポーネントであり、メッセージパッシングを通じてのみ、ネットワーク内の異なるコンピューター上で相互に通信および連携するシステム。
**
機能：
配布、ピアツーピア、同時実行性（外部にサービスを提供している間）、グローバルクロックの欠如、障害が必ず発生します（ネットワークは常に信頼できるとは限りません）
直面する一般的な問題：
異常な通信、ネットワークパーティション、トライステート（成功） 、障害、タイムアウト）、ノード障害
CAP：2000、7、Eric Brewer、ACM PODC（会議）、
2002、MIT（MIT）、Seth Gilbert、Nancy Lynch;
分散システムは、CAPで2つの
P しか完了できません：パーティションフォールトトレランス
CP：一貫性、フォールトトレランス
AP：可用性、フォールトトレランス
保証された可用性、データの不整合、これは無意味です
BASE：
BA：基本的な可用性（分散システムに障害が発生すると部分的な可用性が失われることを許可されます）
S：ソフト状態（システムが存在することを許可されます）中間状態であり、この状態はシステムの全体的な可用性に影響を与えないと考えています）
E：最終整合性（システム内のすべてのレプリカが同期された後、最終的に整合性のある状態に到達できます）
原因整合性、セッション整合性（セッションで読み取り）データは常に一貫しています）、単調な読み取りの一貫性、単調な書き込みの一貫性、および書き込み内容の一貫性（書き込んだデータは常に自分で読み取ることができ、前後で一貫している必要があります。自分で書き込むことが保証されるのは1人だけです）現時点では、読み取りは一貫しています。分散システムの一貫性を
確保するために、複数のプロトコル：
2PC：2フェーズコミット2端末送信、データ全体が保持されます 2つのステップに分かれます
。1.準備（要求と確認）
要求を送信して
3PC を実行します。3フェーズコミット3端末送信、CanCommitは送信できます（クラスター内のどのノードが送信できるかを判断します）-> PreCommit事前送信-> DoCommit
Paxos Paksethプロトコル（古代ギリシャ、Tianma paxos）：1990年に提案されたLeslie Lamportは、分散環境での一貫性の問題を解決するための最も効果的な方法の中で唯一認められたものです
しかし今では、分散システムのサービス調整と登録管理を提供できるよりシンプルなものがあります。2つのソリューション、zookeeper、etcd、およびdockerは、etcd内の各ノードを使用します。zookeeperはpaxos
ではなくPaxosに実装されています。合意全体が変更され、実装のアイデアも変更されました。paxosはコンピュータアルゴリズムで実装するのが本当に難しいため、
2PC：2フェーズコミット2端子送信、データ保持全体を2ステップで実行する必要があります
。1.準備（要求と確認）
要求の送信と実行
に問題があり、最初に要求したものがブロックされます（バレル）理論的には、ショートボード効果）、最後のリクエストが完了すると、それは完全に完了したと見なされ、完全に完了しないと次のステージを要求するのに十分ではありません
Googleチャビー、分散ロックサービス、GFS（Googleファイルシステム、hdfs hadoopfs）/ BigTable（HBASEコテージBIGテーブル）はすべてチャビー、（高可用性分散ロックサービス）の
役割：ファセットコラボレーション、メタデータストレージ、マスター選出;
共通のサービス、複数のノードで実行されているプロセスの調整、ノード間の調整、およびノード間でメッセージを送信する必要がありますが、途中でハングしているノードがある場合、調整する方法がない
ため、これら3つ2つのノードは調整時に相互に通信しません。これらはすべてパブリックストレージと通信します。これらのノードは定期的に状態をパブリックストレージに同期できます。各ノードは他のノードが関連情報を参照できることを保証します。ストレージはデータノードを保存します。サーバーがハングしてリンクが終了すると、ストレージは削除されます。他のノードがノードに関するデータを取得できない場合、ノードは存在しません。
サーバーはマスターノードをサポートしています一部の機能、パブリックストレージサービス、高可用性、一般的にカーディナリティ、4つ以上のセクションも必要 自分のハングアップを確保するために、他の奉仕を続けて
コテージデブは飼育係です
HDFS / HBase、Zookeeper Zookeeper
は、有名なインターネット会社Yahooによって作成されたオープンソースのファセット調整サービスであり、チャビーのオープンソース実装です。つまり、zkは、分散型の典型的な分散データ整合性ソリューションです。アプリケーションは、データ公開/サブスクリプション、ロードバランシング、ネームサービス、分散調整/通知、クラスター管理、マスター選択、分散ロック、それに基づく分散キューを実装できます。
HDFS + mapreduce = hadoop
hbase cottage big tableはhdfsで列データサービスを提供します
Puppetは同期で1つずつ更新され、zkはすべてのサブスクライバーに通知できます
基本的な概念：
クラスターの役割：リーダー、フォロワーの評価、オブザーバーオブザーバー（zkで少なくとも3つのノードはクラスター、通常は2つのフォロワー、リーダー）
リーダー：選挙、読み取り/書き込みサービスを提供;
フォロワー：選挙に参加、選出（リーダーがハングし、マスターになる可能性があります）、読み取りサービス;
オブザーバー：選出に参加する、選出できない（マスターになれない）、読み取りサービスを提供する; 
セッション：ZK、クライアント<->サーバー、長いTCP接続を確立する、ノードが分散システムに参加しないまで、
sessionTimeout（ネットワークの問題によりリンクを設定できない）
zkデータ管理モデルは逆ツリー管理構造であり、分散アプリケーションはこのノードで各ホストに子ノードを登録できます、そこにオンライン、現在のホストに関する情報を保存するために使用され、リーフノードは、オンラインに存在しないが、存在しない
ホストがZKに接続され、セッション情報が常に存在しますが、ホストがダウンし、このセッションは、情報オフになります
に配布します各ノードは、各ノードとzkが持続的にセッションを確立する必要性を調整し、このセッションを通じて、絶えず変化します。それらの間ZKは、自分のノードのステータス情報には、そのような3秒ごととして、他のノードは、ノードがまだ生きていると考えて、まだこのノードのファイルを確認することです
データノード（ZNode）：zkデータモデルのデータ単位。zkデータはメモリに格納され、データモデルはツリー構造（ZNodeツリー）です。各ZNodeは独自のデータをメモリに保存します。
ノードには2つあります。クラス
永続ノード：明示的な削除後にのみ消える
一時ノード：セッションが終了すると自動的に消えます（zkクライアントとzkの間に確立されたセッションリンク）
データノードにはバージョン
バージョン（バージョン）があります。ZKは、各ZNodeのStatと呼ばれるデータ構造を維持します。これは、現在のZNodeバージョンの3つのデータバージョンを記録します
。現在のバージョン
cversion：znode子ノードの現在のバージョン
aversion：現在ZnodeのACLバージョン（アクセスリスト）
複数の分散システムはzkを使用する可能性があるため、zkはそれらを
ACL
に分離する必要があります。ZK はACLメカニズムを使用して、権限制御CREATE、READ、WRITE、DELETE、ADMIN
イベントリスナー（Watcher ）：
ZKでは、ユーザーが指定したトリガーメカニズム。特定のイベントが発生すると、ZKは関連するクライアントに通知でき、
ノードはリスナーをzkに登録します。データが変更されると、zkは登録されたリスナーに変更をすぐに通知できます。デバイスの関連ノード、そして誰もが新しい村長を選択するようになります。
すべての分散ノードは、zkに基づいて選挙、調整、公開、購読を完了できます。Zk は、ZK の特別契約ZABプロトコル：Zookeeper Atomic Broadcast、ZKアトミックブロードキャストプロトコルによって実現さ
れます; zabプロトコルが完了し、各ノードの参加者間のリーダー選出
により、リーダーがクラッシュしたときに新しいリーダーを再選することができます。また、データの整合性を確保
し、クラッシュリカバリメカニズムをサポートする必要があります。
すべてのトランザクション要求はリーダーによって処理されます。他のサーバーfollowとobsrv
は、ZABプロトコルで3つの状態のみを提供します：
（1）見る、
（2）フォローする、
（3 ）リーディング
ユーザーが書き込みリクエストを送信すると、それはzkのリーダーに送信されます。リーダーが情報を受信した後、リーダーはこの変更リクエストを提案に変え、それをzkクラスターにブロードキャストし、変更データが一致するかどうかを確認します。 、データをソースデータに更新
zk内のすべてのものは、リーダーによって受け入れられ、処理される必要があります。クライアントがどのzkノードに接続されていても、リーダーでない場合は、この情報をリーダーに転送する必要があります。リーダーは、各クライアント要求を提案に変換しますプレイヤーの現在のクラスターにブロードキャストします。フォロワーの投票の半分以上が受信されると、この操作が確認され、結果が他のフォロワーにブロードキャストされて送信が完了します
：3つの状態ZAB協定がある
指導者を探していたときに（1）を探しては、各ノードZKだけで、開始（選挙の過程、見ているプロセス）
、となっているリーダーに続いて（2）
の（3）大手リーダーノードの状態
ごとノードは3つのノード間で変換される可能性があります。zkが起動すると、すべてのノードがデフォルトの[Looking]状態になり、クラスタ全体がリーダーを選出しようとし、選出されたスイッチが先行し、他のスイッチはに従います
。 zabプロトコルはアトミックブロードキャストステージに入ります。リーダーデータはフォロワーノードにパッケージ化される必要があります。リーダーノードとフォロワーノードは、ハートビート検出メカニズムを使用して、各フォロワーが通常の状態にあるかどうかを検出する必要があります。クラスタ内のデータノードはデータバージョンを更新します。更新が続く場合、リーダーはそれらが正常であると見なします。フォロワーが時間を超えている場合、フォロワーは自身の指定された情報を更新していない場合、接続を失ったと見なされます。リーダーが失われた場合、全員が探しに切り替わり、リーダーの
選出、解放、同期、ブロードキャストなどを提案します。
