常用框架-ZooKeeper学习

ZooKeeper：通用的无单点问题的分布式协调框架。最早起源于雅虎研究院的一个研究小组。

ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

原语：操作系统或计算机网络用语范畴。是指由若干条指令组成的，用于完成一定功能的过程。具有不可分割性，即原语的执行必须是连续的，在执行过程中不允许被中断。

ZooKeeper是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等功能。

使用场景：用户担任服务生产者和服务消费者的注册中心（提供发布订阅服务）。服务生产者将自己提供的服务注册到ZooKeeper中心，服务的消费者在进行服务调用的时候先到ZooKeeper中查找服务，获取到服务生产者的详细信息后，再去调用服务生产者的内容和数据。如图：

为社么使用奇数台服务器构成ZooKeeper集群？

所谓的zookeeper容错是指，当宕掉几个zookeeper服务器之后，剩下的个数必须大于宕掉的个数的话整个zookeeper才依然可用。假如我们的集群中有n台zookeeper服务器，那么也就是剩下的服务数必须大于n/2。先说一下结论，2n和2n-1的容忍度是一样的，都是n-1，大家可以先自己仔细想一想，这应该是一个很简单的数学问题了。 比如假如我们有3台，那么最大允许宕掉1台zookeeper服务器，如果我们有4台的的时候也同样只允许宕掉1台。 假如我们有5台，那么最大允许宕掉2台zookeeper服务器，如果我们有6台的的时候也同样只允许宕掉2台。

 

 

 

特点：

• 顺序一致性：同一客户端发起的事务请求，最终将会严格地按照顺序被应用到ZooKeeper中。
• 原子性：所有地事务请求的处理结果在整个集群中所有的机器上的应用情况是一致的。
• 单一系统映像：无论客户端被连到哪一个ZooKeeper服务器上，其看到的服务端数据模型都是一致的。
• 可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

 

 

 

ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。

构建集群：为了保证高可用，最好是以集群形态部署ZooKeeper。客户端在使用ZooKeeper时，需要直到集群机器列表，通过与集群中某一台机器建立TCP连接来使用服务，客户端使用这个TCP连接来发送请求，获取结果，获取监听事件以及发送心跳包。

如果这个连接断开了，客户端可以连接到其他的机器上。

集群间通过 Zab 协议（Zookeeper Atomic Broadcast）来保持数据的一致性。

官方提供的结构图

ZooKeeper没有选择传统的Master/Slave概念，而是引入了Leader,Follower,Observer三种角色。

当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。这个过程大致是这样的：

1. Leader election（选举阶段）：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。
2. Discovery（发现阶段）：在这个阶段，followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。
3. Synchronization（同步阶段）:同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后 准 leader 才会成为真正的 leader。
4. Broadcast（广播阶段） 到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。

如何保证顺序访问？

对于来自客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用ZooKeeper这个特征来实现更高层次的同步原语。这个编号也叫做时间戳（zxid）(ZooKeeper Transcation Id)。

ZAB协议：

ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

两种基本的模式：

• 崩溃恢复：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。
• 消息广播：当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。

Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。

 

 

参考

• https://snailclimb.gitee.io/javaguide/#/docs/system-design/framework/ZooKeeper