ZooKeeper的基本概念

ZooKeeper主要服务于分布式系统，提供分布式数据一致性解决方案。可以用ZooKeeper来做：注册中心、分布式锁、命名服务、集群管理、负载均衡、配置管理等。

ZooKeeper使用案例：Hadoop、HBase、Dubbo等。

用途详解

数据结构（ZNode）

ZooKeeper提供的命名空间与标准的文件系统非常类似，一个名称就是一个由"/"分割的路径序列。每个节点叫做ZNode，每一个节点可以通过路径来标识。ZNode可以设置关联数据。

ZNode有两种类型：持久节点、临时节点（当客户端和服务端断开连接后，所创建的ZNode会删除，临时节点不能拥有子节点）

另外还有持久顺序节点和临时顺序节点，创建顺序节点时会在节点名后边会追加了一个由父节点维护的自增整型数字（10位，最大2147483647）来实现顺序。

ZNode数据结构图

Znode数据结构

会话（Session）

客户端与服务端之间的连接是基于TCP长连接，也就是session会话。

从第一次连接建立开始，客户端会话的生命周期就开始了，每个会话都有一个超时时间Timeout。

每次客户端创建会话的时候，ZooKeeper都会为其分配一个全局唯一的sessionID。

会话原理

监听器（Watcher）

节点上可以注册事件监听器（Watcher），当事件触发时，服务端会将事件通知到客户端，该机制是ZooKeeper实现分布式协调服务的重要特性。

ZooKeeper的监听事件有四种：

• nodedatachanged 节点数据改变
• nodecreate 节点创建事件
• nodedelete 节点删除事件
• nodechildrenchanged 子节点改变事件

Watcher机制，可以分为四个过程：

• 客户端注册watcher
• 服务端处理watcher
• 服务端触发watcher事件
• 客户端回调watcher

监听器原理剖析、详解

集群角色

• Leader：一个集群同一时间只会有一个Leader，它会发起并维护与各Follower及Observer间的心跳。所有的写事务必须要通过Leader完成再由Leader将写操作广播给其它服务器。
• Follower：一个集群可同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读事务，同时会将写事务转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。
• Observer：角色与Follower类似，但是不参与选举。

Follower和Observer也可以叫Learner、订阅者、从。

选举

选举时机：服务器启动时、Leader宕机时

选举过程：

1. 所有节点第一票先选举自己当Leader，将投票信息广播出去；
2. 从队列中接受投票信息；
3. 按照规则判断是否需要更改投票信息，将更改后的投票信息再次广播出去；

4. 判断是否有超过一半的投票选举同一个节点，如果是选举结束根据投票结果设置自己的服务状态，选举结束，否则继续进入投票流程。

选举原则：选举出数据最完整的服务。

选举原理

事务ID（ZXID）

在Leader服务器广播事务请求之前会为其分配一个全局唯一的事务ID，即ZXID。类似数据库的TRX_ID事务ID，用于标识一次更新操作。

为了保证顺序性，该ZXID必须单调递增。ZooKeeper使用一个64位的数来表示ZXID，高32位是Leader的epoch，从1开始，每次选出新的Leader，epoch加1。低32位为该epoch内的序号，每次epoch变化，都将低32位的序号重置。这样保证了zxid的全局递增性。

服务状态（选举状态）

• LOOKING：当节点认为群集中没有Leader，服务器会进入LOOKING状态，目的是为了查找或者选举Leader。
• LEADING：对应Leader角色。
• FOLLOWING：对应Follower角色。
• OBSERVING：对应Observer角色。

ZAB状态

• ELECTION: 集群进入选举状态，此过程会选出一个节点作为Leader角色；
• DISCOVERY：连接上Leader，响应Leader心跳，并且检测Leader的角色是否更改，通过此步骤之后选举出的Leader才能执行真正职务；
• SYNCHRONIZATION：整个集群都确认Leader之后，将会把Leader的数据同步到各个节点，保证整个集群的数据一致性；
• BROADCAST：过渡到广播状态，集群开始对外提供服务。

ZAB协议

ZAB协议保证了ZooKeeper集群数据的一致性。主要分为两部分：消息广播、崩溃恢复。

消息广播

• 读请求：直接由当前节点响应。
• 写请求：若当前节点不是Leader就转发给Leader执行，然后将请求转为事务转发给订阅者，过半数ACK后，提交写操作，再广播给订阅者。遇到单点问题通过崩溃恢复解决。

崩溃恢复

一旦Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去了与过半Follower的联系，就会进入崩溃恢复模式，需要选举出一个新的Leader服务器。

ZAB协议崩溃恢复可以保证：

• Leader提交的事务最终会被所有服务器提交
• 丢弃Leader没有提交的事务

ZAB协议原理