Zookeeper工作原理

一 Zookeeper是什么

  ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户，主要为了解决分布式架构下数据一致性问题，典型的应用场景有分布式配置中心、分布式注册中心、分布式锁、分布式队列、集群选举、分布式屏障、发布/订阅等场景。简单说zookeeper=文件系统+通知机制。

1，Zk的文件系统

每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

1. 持久化目录节点：客户端与zookeeper断开连接后，该节点依旧存在，只要不手动删除该节点，他将永远存在。
2. 持久化顺序编号目录节点：客户端与zookeeper断开连接后，该节点依旧存在，只是zookeeper给该节点名称进行顺序编号。
3. 临时目录节点：客户端与zookeeper断开连接后，该节点被删除。
4. 临时顺序编号目录节点：客户端与zookeeper断开连接后，该节点被删除，只是zookeeper给该节点名称进行顺序编号。

2，zk的通知机制

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。监听事件如下：

1、None：连接建立事件
2、NodeCreated：节点创建
3、NodeDeleted：节点删除
4、NodeDataChanged：节点数据变化
5、NodeChildrenChanged：子节点列表变化
6、DataWatchRemoved：节点监听被移除
7、ChildWatchRemoved：子节点监听被移除

3，zk的角色

• 领导者（leader），负责进行投票的发起和决议，更新系统状态
• 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
• Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。zoo.cfg中添加peerType=Observer，这表示这个server以observer角色运行，即不参与投票。再在所有 server的配置文件中，修改server.X配置项，在那些observer的节点上加上:observer后缀。例如，server.1对应的server要作为observer：Server.1=IP:2181:3181:observer
  这样配置后，ZooKeeper集群中的所有服务器节点都知道哪些节点扮演的是observer角色。
• 客户端（client），请求发起方
  

Leader 服务器会和每一个 Follower/Observer 服务器都建立 TCP 连接，同时为每个Follower/Observer 都创建一个叫做 LearnerHandler 的实体。LearnerHandler 主要负责 Leader 和Follower/Observer 之间的网络通讯，包括数据同步，请求转发和 proposal 提议的投票等。Leader 服务器保存了所有 Follower/Observer 的 LearnerHandler 。

4，CAP理论

zookeeper：满足数据的最终一致性,但是在leader选举过程中不可用。
Eureka：在任何时间都可用,但是可能有数据不一致的情况.

• C是一致性,Consistency,就是各个节点保存的数据都是最新的。
• A是Availability, 可用性，每次请求都可以获得响应，但是没法保证是最新的响应。
• P是分区容错性（Partition tolerance），就是每个节点可能都存在于不同的子网络，也就是不同的分区，不同分区之间的通信总是有可能发生故障的，或者总是有可能存在一些节点挂了的情况。

可以认为P总是成立的，C和A是无法同时做到。所以一般对于数据一致性要求特别高的业务，例如支付，交易相关的业务，就是会优先保证一致性C和分区容错性P，就是保证数据一致性，例如让所有子节点都收到更新后才算提交成功，就像MySQL主从同步中的全同步模式一样。普通的业务是优先保证可用性A和分区容错性P，比如在MySQL主从同步时，默认就是异步的方式，我们执行一条更新SQL，只需要主节点更新成功就行就对事务进行提交，不需要等待从节点更新数据成功，主节点会异步把SQL发送给从节点。

二 zk的工作流程

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后 ，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid） 来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于