Zookeeper概述
ZooKeeper学习
ZooKeeper是一个分布式数据一致性的解决方案，分布式应用程序可以基于它实现数据发布/订阅、复杂均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁、分布式队列等功能。
ZooKeeper概述
ZooKeeper可以保证分布式环境下数据的一致性，具体可以实现以下功能。
顺序一致性
从同一个客户端发起的事务请求，最终将会严格地按照请求发起的顺序被应用到ZooKeeper中。
原子性
所有事务请求的处理结果在整个集群的所有机器上的应用情况是一致的，也就是说要么整个集群的机器都应用了某一个事务，要么都没有应用。
单一视图
无论客户端链接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。
可靠性
一旦服务端成功应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直被保存下去。除非有另一个事务对其进行了修改。
实时性
ZooKeeper能够保证最终一致性，无法保证实时一致性。
ZooKeeper之所以能够在大型分布式系统中得到足够的应用，主要和其四个特点有关：简单的数据模型、可构建集群、顺序访问和高性能。
简单的数据模型指的是ZooKeeper服务中保存数据的数据结构，ZooKeeper的数据结构类似于一个树形结构，其中的每一个节点成为ZNode。
可构建集群指的是ZooKeeper集群的每台机器队后在内存中维护当前服务器的状态，并且每台机器之间都互相保持着通信，只要集群中存在超过一半的机器能正常工作，那么整个集群就能够正常对外服务。ZooKeeper的客户端会选择和集群中的某台ZooKeeper服务器创建一个TCP链接，一旦客户端和某台ZooKeeper服务器之间的链接断开后，客户端会自动连接到集群中的其他机器。
顺序访问指的是ZooKeeper对于来自客户端的每个更新请求，都会为其分配一个全剧唯一的递增编号，这个编号反应了所有事务操作的先后顺序。
高性能指的是ZooKeeper将全量数据都保存在内存中，并直接服务于客户端的所有非事务请求。因此ZooKeeper更适用于以读为主的应用场景。
以上是对ZooKeeper的特性的简单介绍。为了更好的学习ZooKeeper，还需要提前了解一下ZooKeeper中的一些核心概念，以下是对一些核心概念的补充介绍。
集群角色：ZooKeeper没有沿⽤传统的Master/Slave概念，⽽是引⼊了Leader、Follower和Observer三种⻆⾊。ZooKeeper集群中的所有机器通过⼀个Leader选举过程来选定⼀台被称为“Leader”的机器，Leader服务器为客户端提供读和写服务。除Leader外，其他机器包括Follower和Observer。Follower和Observer都能够提供读服务，唯⼀的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。
会话：客户端和ZooKeeper的连接成为一个会话，在一个会话中客户端可以和ZooKeeper进行通信。如果客户端与ZooKeeper之间断开连接，在规定时间内重新连接上ZooKeeper，那么之前创建的会话仍然有效。
数据节点：这里特指ZooKeeper中的数据单元而且实际的机器节点，数据节点成为ZNode。ZooKeeper中的数据模型类似树，由斜杠（/）进行分割的路径，就是一个ZNode。每个ZNode都会保存自己的数据内容，同时还有保存一系列属性信息。ZooKeeper中节点也是有状态的，分为持久节点和临时节点。持久节点一旦创建永远也不会实效，除非手动删除。而临时节点的生命周期和一个会话保持一致，一旦这个会话消失了，则这个临时节点也就消失了。此外数据节点可以附带一些属性，不同的属性会有不同的效果。
版本：ZooKeeper会为每一个ZNode节点维护一个叫Stat的数据结构，其中记录了这个数据节点的三个版本数据：version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。
Watcher：这个指的是事件监听器，这是ZooKeeper中一个很重要的概念。ZooKeeper允许用户在指定节点上注册一些Watcher，并且在一定特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上。
ACL：ZooKeeper采用ACL策略来进行权限控制，类似UNIX文件系统的权限控制。ZooKeeper定义了五种权限。
- CREATE：创建节点的权限
- READ：获取节点数据和节点列表的权限
- WRITE：更新节点数据的权限
- DELETE：删除子节点的权限和
- ADMIN：设置节点ACL的权限。
以上是对ZooKeeper的概述，通过以上的内容，可以大致感受到ZooKeeper在分布式系统中的优势和主要功能。
ZAB协议
ZAB协议是专门为ZooKeeper设计的一种支持崩溃恢复的原子广播协议。ZooKeeper利用ZAB协议实现分布式数据一致性，实现了一种主备模式的系统架构来保持及群众各副本之间数据的一致性。ZAB协议的核心是定义对于那些会改变ZooKeeper服务器数据状态的事务请求的处理方式，即：
所有事务请求必须由一个全局唯一的服务器来协调处理（只有一个Leader节点），这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。
协议详情
ZAB协议包括两种模式：崩溃恢复和消息广播。崩溃模式只有在整个ZooKeeper服务在重启的过程中、Leader服务器出现故障等情况时才会进入，崩溃模式的目标是：1、选举Leader节点。2、与Leader节点完成数据同步。当Leader节点选举完成，并且超过一半的机器与该Leader服务器完成数据同步，则会退出崩溃恢复模式。消息广播则是由Leader节点完成，当收到事务请求的时候，Leader节点会生成广播消息通知其他节点；如果非Leader节点收到事务请求，则会将当前请求转发给Leader节点。如果Leader服务器出现故障，或者集群中与Leader节点通信的节点数量低于一半，则在下一轮广播之前会进入崩溃恢复模式，使得整个集群达到一种一致的状态。
消息广播
ZAB的消息广播使用的机制类似于2PC。每当有一个事务请求被Leader接收，Leader节点会想所有的Follower发送事务执行请求。但是Leader并不会等待所有的Follwer都返回确认消息，只要有过半的Follwer返回确认消息，Leader即会发送事务提交请求。ZAB的消息广播没有2PC模式中的中断回滚和等待所有节点确认机制，Follwer对于Leader发送的请求要么确认，要么直接丢弃。同时，消息广播过程中是基于FIFO特性的TCP协议来进行网络通信，因此很容易保证消息接收与发送的顺序性。
在整个消息广播的过程中，Leader会为每个Follower生成对应的事务请求，并且给每一个事务请求分配一个全局单调递增的唯一ID（事务ID），每一个事务请求按照事务ID的先后顺序进行排序和处理。Leader会与每一个Follower维护一个单独队列，然后将需要发送的事务请求发送到这个队列中，并根据FIFO策略进行消息发送。每个Follower在拿到事务请求后，都会将当前请求以事务日志的形式写入到本地磁盘中，并在成功写入后给Leader返回一个确认消息。如果过半的Follower都返回了确认消息，Leader则会广播事务提交请求，Follower在收到事务提交请求后会完成对事务的提交。
崩溃恢复
一旦Leader失去了与过半Follower的联系，则会进入崩溃恢复模式，选举出一个新的Leader。ZooKeeper的选举策略是必须能够确保提交已经被Leader提交的事务请求，同时丢弃已经被跳过的事务请求。选举出来的Leader拥有集群中所有机器最高的事务ID。
完成Leader选举后，新的Leader需要和Follower确认哪些事务需要提交。Leader为每个Follower准备一个队列，并将那些没有被各Follower同步的事务以事务请求的方式发送给各个Follower，并紧接着发送提交请求，表示该事务已经提交。等Follower将所有尚未同步的事务请求都从Leader上通不过来，并且应用到内存数据库中，当前Follower才会被Leader加入到可用列表中。
对于事务丢弃的处理，ZooKeeper采用了将事务ID分为高低位的方式进行处理。事务ID的长度是64位，分为高32位和低32位两部分。低32位只是一个简单的单调递增计数器；高32位则代表了Leader周期epoch的编号，每次选举出新的Leader的时候就会解析当前最大事务ID的高32位值，并将该值加1。新的高32位值作为新周期的epoch值，并将低32位从0开始生成新的事务ID。上一个Leader服务器重启后，由于epoch值比当前集群中的epoch值小，所以只能成为Follower。新的Leader服务器通过对比已提交的事务ID，旧Leader上未提交的事务ID会被丢弃。
小结
ZooKeeper通过ZAB协议为基础，构建了一个高可用的分布式中间件。ZAB通过崩溃恢复和消息广播两种机制，确保ZooKeeper集群能够快速同步消息，以及自适应完成Leader选举。
浙公网安备 33010602011771号