、飼育係さんのプロフィール
飼育係は、現在はApacheによって維持オープンソースの分散コーディネーションサービスです。飼育係の分散システムは、一般的な出版/サブスクリプション、負荷分散、オーダーサービス、分散協調/通知、クラスタ管理、マスター選挙、分散ロッキングおよび分散キューの機能を実装するために使用することができます。それは次の機能があります。
- シーケンシャル一貫性は：クライアントトランザクションからの要求を開始し、最終的に飼育係に適用するために、その打ち上げに厳密に従うものとします。
- アトミック ;ケースの他の部分が印加されていないが、トランザクションが存在しない機械の一部を適用し、クラスタ全体におけるすべてのトランザクション要求処理結果は、すべてのマシンで同じです。
- 単一のビューすべてのクライアントが一致しているサーバーのデータモデルを参照してください。：
- 信頼性：成功したアプリケーション・サーバーのトランザクションに一度の変化、それは別の会社に変更されるまで、残る原因となります。
- リアルタイム：トランザクションが正常に適用されると、このトランザクションの変更の日付を読み取ることができた直後に、飼育係は、そのクライアントのデータを確保することができます。
二、飼育係の設計目標
飼育係は、大規模な分散システムのそれらのハイスループット用の高性能、高可用性を提供することを約束し、サービスを調整する分散制御機能に厳密シーケンシャルアクセスを有しています。これは、次の4つの目的があります。
2.1目標の一つ：シンプルなデータモデル
飼育係は、一般的なファイルシステムと同様、データのznode組成物と呼ばれる一連のノードから成るツリー構造でデータを格納します。しかし、一般的なファイルシステムと異なる、飼育係は、ハイスループットに格納されたデータの完全な量を実現するために、メモリにもアクセスのレイテンシを削減します。
2.2目的2：クラスタを構築します
飼育係飼育係クラスタを構成することができるサービスのセットで構成され、クラスタ内の各マシンは、限り、クラスタ内のマシンの半分が正しく動作するように、クラスタ全体をメモリに独自の別個の状態を維持し、各マシン間の通信を維持する必要があります私たちは、通常のサービスを提供することができます。
2.3目標3：順次アクセス
クライアントからの各更新要求のために、飼育係は、すべてのトランザクション要求の順序を反映して、グローバルに一意インクリメントIDが割り当てられています。
2.4目標4：高性能、高可用性
いくつかのシナリオで読み書きが高い持っているように、すべての飼育係の更新および削除は、トランザクション・ベースであるため、高性能、高可用性、サービスクラスタを介して達成され維持するために、メモリの総量に格納されたデータを格納するためのZooKeeperパフォーマンス。
第三に、コアコンセプト
3.1役割クラスタ
クラスタ内の飼育係のマシンは、次の3つの役割に分かれています。
- リーダー：クライアントへの識字サービスを提供し、クラスタ選挙によって生成されたクラスタの状態を維持します。
- フォロワー：クライアントへの識字サービスを提供し、定期的にノードリーダーに自分の状況を報告します。また、書き込み動作に関与し、選挙の戦略とリーダー「成功の半分以上を書きました」。
- オブザーバー：、クライアントへの識字サービスを提供し、定期的にノードのリーダーに自分の状況を報告しますが、書き込み動作時には参加しない選挙戦略とリーダー「半分以上の成功を書いた」、そうオブザーバーは、書き込み性能に影響を与えることなく、クラスタを向上させることができますパフォーマンスをお読みください。
セッション3.2
セッション状態が有効心拍検出メカニズムを維持するために、後にサービスのクラスタへのTCP接続を介して長い飼育係クライアントは、最初の接続の開始時からのセッション（セッション）は、確立されました。この接続を介して、クライアントが要求を送信し、応答を受信するだけでなく、イベント通知ウォッチを受け取ることができることがあります。
コアの概念についての別の会話に断線やセッションタイムアウト限り、この時間内に接続を再確立し、以前に作成し、その結果、ネットワーク障害またはクライアント割り込みや他の理由SESSIONTIMEOUT（セッションタイムアウト）、ありますセッションがまだ有効です。
3.3データノード
ZooKeeperのデータモデルは、基本データ単位の系列であるZnodeルートノードであるノードツリーの（データノード）/。各ノード上のデータやノードの情報が保存されます。飼育係ノードは、2つのカテゴリに分けることができます。
- 永続ノード：そうでない場合は、常に存在していない限り、一度作成されたノードは、自動的に削除されます。
- 一時的なノード：そのノードに障害が発生したため、クライアントのセッションを作成すると、すべてのクライアントは、一時的なノードが削除されます作成されます。
一時的および恒久的なノードのノードは、特別なプロパティを追加することができますSEQUENTIAL、増加プロパティを持つノードを代表しているかどうか。この属性を指定した場合は、このノードを作成する際に、飼育係は自動的に親によって維持され、その数字の後ろに増分ノード名を追加します。
3.4ノード情報
各ノードのznodeデータを格納しながら、維持することが知られているStatノードのすべての状態についての情報を記憶するデータ構造を、。次のように：
| 国有財産 | 説明 |
|---|---|
| czxid | トランザクションIDデータノードを作成するとき |
| CTIME | データノードを作成するための時間 |
| mzxid | トランザクションIDのデータが最後の更新ノードた場合 |
| ファイルのmtime | タイム時にデータノードの最後の更新 |
| pzxid | 最後のトランザクションIDが変更されたノードデータの子ノード |
| cversion | 子ノードの数を変更します |
| バージョン | ノードデータの数を変更します |
| 嫌悪 | ノードのACLの数を変更します |
| ephemeralOwner | ノードは、一時的なノードである場合、作成されたセッションは、ノードをセッションID、ノードが永続的なノードである場合、属性値は0であります |
| DATALENGTH | データ内容の長さ |
| するnumChildren | 現在のノードデータの子ノードの数 |
3.5ウォッチャー
一般的に使用される機能で飼育係は、リスナーは、イベントが発生したときに、ユーザーが指定したノードをリッスンするように関心のあるイベントを登録することを可能にするウォッチャー（イベントリスナー）、トリガされているイベント情報をクライアントにプッシュされます。このメカニズムは、飼育係の分散協調サービスを達成するための重要な特性です。
3.6 ACL
飼育係がコントロールにアクセスするには、ACL（アクセス制御リスト）の戦略を使用して、アクセス制御は、UNIXのファイルシステムと同様です。これは、次の5つの権限を定義します。
- CREATE：あなたは子ノードを作成することができます。
- READ：允许从节点获取数据并列出其子节点；
- WRITE：允许为节点设置数据；
- DELETE：允许删除子节点；
- ADMIN：允许为节点设置权限。
四、ZAB协议
4.1 ZAB协议与数据一致性
ZAB 协议是 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。通过该协议，Zookeepe 基于主从模式的系统架构来保持集群中各个副本之间数据的一致性。具体如下：
Zookeeper 使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用原子广播协议将数据状态的变更以事务 Proposal 的形式广播到所有的副本进程上去。如下图：
具体流程如下：
所有的事务请求必须由唯一的 Leader 服务来处理，Leader 服务将事务请求转换为事务 Proposal，并将该 Proposal 分发给集群中所有的 Follower 服务。如果有半数的 Follower 服务进行了正确的反馈，那么 Leader 就会再次向所有的 Follower 发出 Commit 消息，要求将前一个 Proposal 进行提交。
4.2 ZAB协议的内容
ZAB 协议包括两种基本的模式，分别是崩溃恢复和消息广播：
1. 崩溃恢复
当整个服务框架在启动过程中，或者当 Leader 服务器出现异常时，ZAB 协议就会进入恢复模式，通过过半选举机制产生新的 Leader，之后其他机器将从新的 Leader 上同步状态，当有过半机器完成状态同步后，就退出恢复模式，进入消息广播模式。
2. 消息广播
ZAB 协议的消息广播过程使用的是原子广播协议。在整个消息的广播过程中，Leader 服务器会每个事物请求生成对应的 Proposal，并为其分配一个全局唯一的递增的事务 ID(ZXID)，之后再对其进行广播。具体过程如下：
Leader 服务会为每一个 Follower 服务器分配一个单独的队列，然后将事务 Proposal 依次放入队列中，并根据 FIFO(先进先出) 的策略进行消息发送。Follower 服务在接收到 Proposal 后，会将其以事务日志的形式写入本地磁盘中，并在写入成功后反馈给 Leader 一个 Ack 响应。当 Leader 接收到超过半数 Follower 的 Ack 响应后，就会广播一个 Commit 消息给所有的 Follower 以通知其进行事务提交，之后 Leader 自身也会完成对事务的提交。而每一个 Follower 则在接收到 Commit 消息后，完成事务的提交。
五、Zookeeper的典型应用场景
5.1数据的发布/订阅
数据的发布/订阅系统，通常也用作配置中心。在分布式系统中，你可能有成千上万个服务节点，如果想要对所有服务的某项配置进行更改，由于数据节点过多，你不可逐台进行修改，而应该在设计时采用统一的配置中心。之后发布者只需要将新的配置发送到配置中心，所有服务节点即可自动下载并进行更新，从而实现配置的集中管理和动态更新。
Zookeeper 通过 Watcher 机制可以实现数据的发布和订阅。分布式系统的所有的服务节点可以对某个 ZNode 注册监听，之后只需要将新的配置写入该 ZNode，所有服务节点都会收到该事件。
5.2 命名服务
在分布式系统中，通常需要一个全局唯一的名字，如生成全局唯一的订单号等，Zookeeper 可以通过顺序节点的特性来生成全局唯一 ID，从而可以对分布式系统提供命名服务。
5.3 Master选举
分布式系统一个重要的模式就是主从模式 (Master/Salves)，Zookeeper 可以用于该模式下的 Matser 选举。可以让所有服务节点去竞争性地创建同一个 ZNode，由于 Zookeeper 不能有路径相同的 ZNode，必然只有一个服务节点能够创建成功，这样该服务节点就可以成为 Master 节点。
5.4 分布式锁
可以通过 Zookeeper 的临时节点和 Watcher 机制来实现分布式锁，这里以排它锁为例进行说明：
分布式系统的所有服务节点可以竞争性地去创建同一个临时 ZNode，由于 Zookeeper 不能有路径相同的 ZNode，必然只有一个服务节点能够创建成功，此时可以认为该节点获得了锁。其他没有获得锁的服务节点通过在该 ZNode 上注册监听，从而当锁释放时再去竞争获得锁。锁的释放情况有以下两种：
- 当正常执行完业务逻辑后，客户端主动将临时 ZNode 删除，此时锁被释放；
- 当获得锁的客户端发生宕机时，临时 ZNode 会被自动删除，此时认为锁已经释放。
当锁被释放后，其他服务节点则再次去竞争性地进行创建，但每次都只有一个服务节点能够获取到锁，这就是排他锁。
5.5 集群管理
Zookeeper 还能解决大多数分布式系统中的问题：
- 如可以通过创建临时节点来建立心跳检测机制。如果分布式系统的某个服务节点宕机了，则其持有的会话会超时，此时该临时节点会被删除，相应的监听事件就会被触发。
- 分布式系统的每个服务节点还可以将自己的节点状态写入临时节点，从而完成状态报告或节点工作进度汇报。
- 通过数据的订阅和发布功能，Zookeeper 还能对分布式系统进行模块的解耦和任务的调度。
- 通过监听机制，还能对分布式系统的服务节点进行动态上下线，从而实现服务的动态扩容。
参考资料
- 倪超 . 从 Paxos 到 Zookeeper——分布式一致性原理与实践 . 电子工业出版社 . 2015-02-01
更多大数据系列文章可以参见 GitHub 开源项目： 大数据入门指南