https://www.cnblogs.com/felixzh/p/5869212.html
飼育係の機能と作品
何その1.ZooKeeper？
ZooKeeperのは、Googleのデブが送信フィードバックノードに応じて、分散アプリケーションのための分散、オープンソースのコーディネーションサービス、それがクラスタ・マネージャであり、オープンソース実装であるクラスタ妥当次のステップにおいて、各ノードの状態を監視しています操作。インターフェースとユーザーが利用できるシステムの効率的なパフォーマンス、機能性と安定性を使用して最後に、簡単に
何を提供2.ZooKeeperを？
1）システムファイル
2）通知メカニズム
3.Zookeeperファイルシステムを
、のznodeと呼ばれ、ファイルシステムである、我々は自由に追加することができるネームサービスなどの各サブディレクトリエントリのznodeを削除する、のznodeで増加、サブのznodeを削除のみznodeの違いは、データが格納されていることです。
：のznodeの4つのタイプがあります
。1、PERSISTENT-ディレクトリノードの永続性
のZooKeeperクライアントの後には切断されているが、ノードがまだ存在する
2、PERSISTENT_SEQUENTIAL-永続的なディレクトリノードのシーケンス番号
のZooKeeperクライアントが切断した後は、ノードがまだあります存在するが、飼育係は、ノード名に順次番号
3、ephemeral-が一時ディレクトリノード
のZooKeeperクライアントが切断された後、ノードを除去し
、4 EPHEMERAL_SEQUENTIAL-シーケンス番号一時ディレクトリノード
クライアントが飼育係後に切断され、ノードが削除されるが、飼育係は、ノード名に順番に番号が付け
<ignore_js_op> 
4.Zookeeper通知機構
クライアントは、飼育係がクライアントに通知するノードのディレクトリの変更（変更データが削除されているが、サブディレクトリノード増加を削除する）場合、ディレクトリノードを監視するために、その関心を登録します。
5.Zookeeperは何をしましたか？
3. 4. 5.分散ロック・キュー管理サービスクラスタ管理構成管理の命名1. 2.
サービスを命名6.Zookeeper
飼育係のファイルシステムのディレクトリを作成するには、それが唯一の道です。私たちが展開するときにマシンが相互の発見を探求することが可能である経路を通って、下流経路プログラムとよく一致することができ、上流プログラムをtborg使用して決定することはできません。
7.Zookeeper構成管理
設定を変更するには、複数のマシン、一つ一つに配備分散プログラムが困難になる場合は、プログラムは常に、設定が必要です。今まで入れZooKeeperのこれらの構成のすべてを入れて、設定情報の変更後は、各アプリケーションは飼育係が通知されます、ディレクトリノードの飼育係に格納され、その後、ディレクトリノードに関連するすべてのアプリケーションには、監視するために、飼育係は、その後のようなシステムに新しい構成情報から取得した
<ignore_js_op> 
8.Zookeeperクラスタ管理
二つを気にせずに、いわゆるクラスタ管理：マシンは、選挙のマスターを終了し、参加しています。
最初のポイントでは、すべてのマシンはその後、親ディレクトリGROUPMEMBERSで一時ディレクトリノードを作成することに同意した子ノード変更メッセージの親ディレクトリノードをリッスンします。兄弟ディレクトリが削除され、誰もが知っている：：マシンがハングアップしたら、マシンが飼育係のオフに接続されている、それは一時的なディレクトリノードが削除されて作成し、他のすべてのマシンに通知していること、ボード上A。
新しいマシンは、すべてのマシンが通知を受け、参加に似ています。新しい兄弟が参加し、第二の点のために、あったhighcount、私たちは少しの変更、すべてのマシンの一時ディレクトリノード番号を作成するために、マスターとしてたびにマシンを最小の番号を選択しますうまく。
<ignore_js_op> 
9.Zookeeperは、ロック分散
やすく、飼育係とロックの問題をファイルシステムの整合性を。ロックサービスは2つのカテゴリに分類することができ、一方が他方には、タイミングを制御することで、排他性を維持することです。
最初のカテゴリのために、私たちはcreateznodeの方法によって達成されるロック、と見られて飼育係でのznodeます。ロックを所有しているクライアントの最終的な成功を作成/ distribute_lockノードを、作成するすべてのクライアント。削除するには、ロックを解除します作成distribute_lockノードを実行します。
第二のカテゴリーについては、/ distribute_lockはすでに既存の、すべてのクライアントが同じマスターを、その下の番号の一時ディレクトリノードを順次作成し、選択するために、最も小さい番号のロックが削除され、便利に排気しました。
<ignore_js_op> 
10.Zookeeperキュー管理
キューの2つのタイプがあります。
彼らはキューのすべてのメンバーを集めたときに1、同期キュー、キューは、すべてのメンバーが到着するのを、それ以外の場合は待っている、使用可能です。
2、FIFOモードでのキューのエンキューおよびデキュー操作。
最初のカテゴリは、番号が我々の要求を監視ノードの数であるかどうか、契約の下のディレクトリに一時ディレクトリノードを作成します。
第二のタイプ、および数によってシーンの基本原理、番号列、列と一致分散ロックサービス制御配列。
11.分散データ複製
一貫性のあるデータ・サービスを提供するために、クラスタとして飼育係、当然、それはすべてのマシン間でのデータレプリケーションを行うことです。データ複製の利点：
1、フォールトトレランス：動作を停止するようにシステム全体を保証するノード・エラー、他のノードがその仕事を引き継ぐことができ、
図2に示すように、システムのスケーラビリティを増加させる：負荷が複数のノードに分散され、または増加ノードシステムの負荷容量を増加させること;
ユーザーのアクセス速度を向上させ、最寄りのローカルアクセスノードにクライアント：3、パフォーマンスを向上させます。
読むと透明性の点のクライアント・ポイントからのアクセスを書き込み、データレプリケーションクラスタの二点以下：
1、書き込みマスター（WriteMaster）：指定されたノードに提出されたデータの修正。そのような制限を読まない、任意のノードが読み取ることができます。;この場合、クライアントは、通常の読み取りおよび書き込み別として知られ、差を読み書きするために必要とされる
データの変更は、任意のノードに提出することができる同一の繰り返し：2、任意ライト（すべての書き込み）。この場合、クライアントとクラスタノードと透明の変化の役割。
飼育係のために、方法には、いずれかを書面で使用されています。マシンを増加させることにより、その読み取りスループットと応答性、スケーラビリティが非常に良いです、と書き、機械のスループット容量の増加と確かに（これはまた、それはオブザーバーを設立した理由である）下落し、対応する能力は、特定の実装に依存し、ありますすぐに応答すぐに一貫性、またはコピーを維持するために、最終的なコピーを遅らせます。
12.Zookeeperロール説明は、
<ignore_js_op> 
13.Zookeeperクライアント
<ignore_js_op> 
14.Zookeeperに設計された
1。最終的一貫性：クライアントを関係なく、サーバーに接続し、そのうちの最も重要な飼育係である、同じビューに提示されますパフォーマンス。
2.信頼性：メッセージがサーバーに受け入れられた場合、単純な、堅牢で、優れた性能、それはすべてのサーバーに受け入れられるだろう。
3.リアルタイム：飼育係は、クライアントが時間間隔の範囲、または情報サーバの障害内に更新情報サーバーを受信することを確認してください。しかし、ネットワークの遅延やその他の理由のために、飼育係のデータ（）インターフェースを読む前に同期を呼び出す必要があり、2つのクライアントが同時にただ、必要に応じて最新のデータを更新されたデータを受信できることを保証するものではありませ。
4.（待つ-無料）独立した待機：各クライアントが効果的に待つことができるように、クライアントの低速または失敗は、高速の介入要求クライアントではないかもしれません。
5.原子性：唯一の成功または失敗、ない中間状態を更新します。
6.順：半順序とグローバル順序2種類の方法があります。世界的な順序は、メッセージの前にメッセージがサーバBに掲載されている場合、メッセージはすべてのBサーバーの前にメッセージに掲載されることを意味します。半順序は先にバインドされたBの、もしポストB同じメッセージのメッセージ送信者の後を意味します。
15.Zookeeperが機能
コア飼育係は、原子放送で、このメカニズムは、様々なサーバ間の同期を保証します。このメカニズムのプロトコル実装はザブ契約と呼ばれています。ザブプロトコルは、（マスタから選択される）リカバリモードとブロードキャストモード（同期）している二つのモードを有します。サービスが開始またはリーダーが選出され、ほとんどのサーバーの同期と国家の指導者の後に終了したときにリーダーがクラッシュした後、ザブは、リカバリモードに入ったときは、リカバリモードは終わりました。状態同期がリーダーとサーバーが同じシステムの状態を持って保証します。
トランザクションを識別するために増加トランザクションID番号（zxid）を使用して業務のための一貫性、飼育係を確保するために。すべての提案（案）をzxid時に追加することが提案されています。実装zxidがリーダーとの間の関係を識別するために使用される高32エポックは、リーダーが選出されるたびに変更されているである64ビットの数である、それは新しい時代、指導者の治世に属する現在のロゴを持っています。低カウントのため32。
サーバーの動作状態の下で16.Zookeeper
：各サーバーのは、自分の仕事の過程で3つの状態があり
Serverは、現在の指導者が探している人を知りません：LOOKING
LEADINGを：現在のサーバが選出されたリーダーであります
リーダーは同期させるために、現在のサーバーが選出された次の
17.Zookeeper予備選挙プロセス（基本パクシ）を
するときに、新しいリーダーリーダーリーダーがクラッシュしたり、フォロワーのほとんどが失われ、この時間ZKはリカバリモードに、リカバリーモードに再選出する必要がありますそのように、すべてのサーバーを適切な状態に復元されています。ZK選挙アルゴリズム、2があります：1は、他の実装高速Paxosアルゴリズムに基づいており、基本的なパクシの認識に基づいています。デフォルトの選挙アルゴリズムは高速Paxosです。
1.選挙を開始し、現在のスレッドのサーバーが保持しているスレッドの選挙、その主な機能は、統計と選出された推奨サーバーに投票することで、
すべてのサーバーに（自分を含む）最初の問い合わせを起動するスレッドの2選挙;
3.選挙スレッド返信を受けた後、自分の照会（検証zxidが同じである）が起動した後、ID（MYID）の反対側を取得し、現在の問い合わせオブジェクトリストに保存され、最終的に相手のリーダーは、関連する情報を提案し得る確認します（ID、zxid） ;および選挙テーブルの投票記録への情報格納
4.サーバーの応答が結局受信されたが、最大zxidサーバー、サーバーおよび関連情報は、サーバーを投票したい次の時間を設定すると計算されたが、
5.この時点で優勝サーバサーバ票のn / 2 + 1を取得する場合、現在の推奨リーダーにサーバーへの現在のzxid最大のサーバーを通し、関連勝利サーバーに基づいて受賞サーバーのリーダーのための現在の勧告を、設定情報はそれ以外の場合は、自分の状態を設定し、リーダーが選出されるまで、このプロセスを継続します。プロセス分析によって、我々は結論することができます。大半のリーダーサーバのサポートを入手するには、サーバーの合計数が奇数2N + 1でなければならず、サーバーの生存数はそれぞれスタートServerは上記のプロセスを繰り返すことになります後のn + 1以上です。それが崩壊するだけの状態であるか、単にサーバがディスクスナップショットからのデータとセッション情報の復元を開始します復元する場合は、リカバリモードでは、ZKトランザクションログを記録し、定期的なスナップショットは、回復の状態の回復を促進します。選択されたメインの詳細なフローチャートに示すように：
<ignore_js_op> 
18.Zookeeperは、メインフロー（高速Paxos）から選択された
最初のサーバーは、サーバーは、他の提案を受信するリーダーでなければならないすべてにサーバを提案し、選挙プロセスにおける高速Paxosプロセス、紛争解決とzxidエポック、および他の党の提案を受け入れ、[他の側面を完了し、プロセスを繰り返すの提案を受け入れるようにメッセージを送信するためには、最終的にリーダーを選出する必要があります。
<ignore_js_op> 
19.Zookeeper同期処理が
完了リーダー後に選択され、ZK状態同期処理に入ります。
1.リーダー待機サーバ接続;
2 .Follower接続リーダー、リーダーをzxidに送ら最大;
3 .Leader同期点がフォロワに応じて決定されるzxid;
.. 4同期が従動uptodate状態通知になった後。
5の後.Followerはuptodateニュースを受信するだけでなく、クライアントにサービスを提供する要求を再受け入れること。
<ignore_js_op> 
20.Zookeeperワークフロー-Leader
。データ復旧1;
2学習維持ハートビートは、要求を受信し、学習者の学習要求メッセージタイプを決定する;
3つの.Learnerメッセージタイプは、PINGメッセージは、要求メッセージ、ACKメッセージであります、異なるメッセージタイプに応じて、メッセージを再検証し、異なる処理が行われます。
PINGメッセージは、ハートビート学習者指し、
REQUESTメッセージは、書き込み要求および同期要求を含むフォロワ送信オファー情報、である
ACKメッセージは、その後、提案をコミットよりフォロワの半分を通るよりも、提案された応答のフォロワーであり、
メッセージが再検証しますSESSIONは、効果的な時間を延長します。
<ignore_js_op> 
21.Zookeeperワークフロー-Follower
：フォロワーは、4つの主な機能有し
; 1リーダー（PINGメッセージは、要求メッセージ、ACKメッセージ、メッセージを再検証）に要求を送信
2.リーダー・メッセージが受信され処理;
3.クライアント書き込み要求がリーダーの投票に送信される場合、要求は、;
4.クライアントは結果を返します。
従動メッセージループ処理リーダーから複数のメッセージである：
1つの.PINGメッセージ：ハートビートメッセージ。
2 .PROPOSALメッセージ：リーダーの提案を開始したがフォロワーの投票を必要とする
3 .COMMITメッセージ：。最新の提案についてのサーバーの情報;
4 .UPTODATEメッセージ：同期が完了したことを示し、
5 .REVALIDATEメッセージ：リーダーの再検証の結果、再検証をクローズするとセッションや、彼がメッセージを受信することができます。
6つの.syncメッセージ：SYNCリターン結果をクライアントには、ニュースは当初、最新の更新プログラムを入手するために強制的に、クライアントによって開始されました。
<ignore_js_op> 
まあ、それは、飼育係の私の理解だし、新しい技術はそれを楽しみにしてくださいと私はあなたを更新していきます！！！
1.ZooKeeper是什么？
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户
2.ZooKeeper提供了什么？
1)文件系统
2)通知机制
3.Zookeeper文件系统
每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
有四种类型的znode：
1、PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在
2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3、EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除
4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
<ignore_js_op>
4.Zookeeper通知机制
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
5.Zookeeper做了什么？
1.命名服务 2.配置管理 3.集群管理 4.分布式锁 5.队列管理
6.Zookeeper命名服务
在zookeeper的文件系统里创建一个目录，即有唯一的path。在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好path，通过path即能互相探索发现。
7.Zookeeper的配置管理
程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。现在把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好
<ignore_js_op>
8.Zookeeper集群管理
所谓集群管理无在乎两点：是否有机器退出和加入、选举master。
对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。
新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了，对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。
<ignore_js_op>
9.Zookeeper分布式锁
有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。
对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。
<ignore_js_op>
10.Zookeeper队列管理
两种类型的队列：
1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
11.分布式与数据复制
Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处：
1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
3、提高性能：让客户端本地访问就近的节点，提高用户访问速度。
从客户端读写访问的透明度来看，数据复制集群系统分下面两种：
1、写主(WriteMaster) ：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离；
2、写任意(Write Any)：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。
对zookeeper来说，它采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降（这也是它建立observer的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。
12.Zookeeper角色描述
<ignore_js_op>
13.Zookeeper与客户端
<ignore_js_op>
14.Zookeeper设计目的
1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
2.可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。
3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4.等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
5.原子性：更新只能成功或者失败，没有中间状态。
6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
15.Zookeeper工作原理
Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
16.Zookeeper 下 Server工作状态
每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步
17.Zookeeper选主流程(basic paxos)
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
1.选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
2.选举线程首先向所有Server发起一次询问(包括自己)；
3.选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；
4.收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；
5.线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。 通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1. 每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选主的具体流程图所示：
<ignore_js_op>
18.Zookeeper选主流程（fast paxos）
fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。
<ignore_js_op>
19.Zookeeper同步流程
选完Leader以后，zk就进入状态同步过程。
1. Leader等待server连接；
2 .Follower连接leader，将最大的zxid发送给leader；
3 .Leader根据follower的zxid确定同步点；
4 .完成同步后通知follower 已经成为uptodate状态；
5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。
<ignore_js_op>
20.Zookeeper工作流程-Leader
1 .恢复数据；
2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
PING 消息是指Learner的心跳信息；
REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；
ACK消息是 Follower的对提议的回复，超过半数的Follower通过，则commit该提议；
REVALIDATE消息是用来延长SESSION有效时间。
<ignore_js_op>
21.Zookeeper工作流程-Follower
Follower主要有四个功能：
1.向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
2.接收Leader消息并进行处理；
3.接收Client的请求，如果为写请求，发送给Leader进行投票；
4.返回Client结果。
Follower的消息循环处理如下几种来自Leader的消息：
1 .PING消息： 心跳消息；
2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；
3 .COMMIT消息：服务器端最新一次提案的信息；
4 .UPTODATE消息：表明同步完成；
5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
<ignore_js_op>
好了，以上就是我对zookeeper的 理解了，以后我还会继续为大家更新新的技术请大家期待吧！！！