深入理解ZooKeeper

 什么是ZooKeeper？ZooKeeper是一个分布式、开源的分布式应用协作服务。它提供了一组简单的原语，分布式应用程序可以在这些原语的基础上实现更高级别的服务，用于同步、配置维护、组命名,提供简单易用的接口给用户使用。
 本文将介绍ZooKeeper的基本概念、使用场景、ZAB协议和请求处理。

ZooKeeper的概念和基础

1. 服务架构

image.png

 ZooKeeper本身是一个高可用的服务，ZooKeeper集群中服务器有三种角色leader、follower、observer，leader提供读和写的服务，follower只提供读的服务和参与leader选举，observer和follower的区别是observer不参与选举。

2. 数据结构

image.png

 ZooKeeper的数据结构类似于一个文件系统。存放一个个的数据节点（Znode），Znode的属性有永久（persistent）、临时（ephemeral）和有序（sequential）。

• 永久：创建成功之后将永久存在，只能通过调用delete来进行删除。
• 临时：当创建该节点的客户端崩溃或关闭了与ZooKeeper的连接时，这个节点就会被删除。
• 有序：按照创建的时间顺序节点会分配唯一个单调递增的整数。
  总之，znode一共有4种类型：永久的（persistent）、临时的（ephemeral）、永久有序的（persistent_sequential）和临时有序的（ephemeral_sequential）。

3. 监控与通知
 Watcher是Zookeeper中很重要的机制。客户端通过对znode创建watcher当节点发生变化的时候(节点删除、数据更改、子节点变化等)，ZooKeeper将会通知注册Watcher的客户端节点已经变更。
 监听事件有推和拉的形式，所谓推就是事件触发之后服务器向客户端推送数据，而拉就是客户端轮询服务器检查事件是否触发。而ZooKeeper采用推和拉结合的形式，事件触发之后，服务器给客户端推送事件（不包含事件的内容，只有发生了什么事件），客户端收到通知之后去服务器拉去最新的数据，采用这种方式每次每次通知只需要传输少量数据就行了，减少I/O压力。需要注意的是ZooKeeper在事件通知之后会将Watcher给删除，为了继续监听，客户端必须在每次通知后设置一个新的Watcher。

4. 会话(Session)
 在对ZooKeeper集合执行任何请求前，一个客户端必须先与服务建立会话。客户端与服务器将会建立一个TCP的长连接，第一次建立连接的时候也是Session开始的时候，客户端与服务器通过这个连接发送心跳监控彼此存活的状态。客户端可以设置会话超时时间sessionTimeout，在集群模式下，客户端和ZooKeeper服务器断开连接之后，只要间隔时间不超过sessionTimeout之前建立的会话依然有效。

5. 应用
 因为ZooKeeper自身的分布式一致性和特殊的数据结构，可以使用ZooKeeper解决很多分布式系统的问题，比如数据的发布订阅、分布式锁、Master选举、分布式协调等功能。

• 分布式锁
  使用ZooKeeper的临时有序节点这个特性，实现分布式锁。比如命名一个临时节点/lock，客户端都去争夺创建这个节点，创建成功就代表获取锁成功，由于只会有一个路径相同的节点存在，其他客户端不会再创建这个节点成功。创建失败则注册Watcher检测/lock节点的变化。当获取锁成功的客户端执行完自身逻辑之后去释放锁就是删除/lock节点，或者客户端崩溃由于是临时节点也会将锁释放。其他客户端监听到节点变化事件之后，再次去争夺锁。

• 实现主从模式

  
  
  主从模式

  可以使用上图的数据结构可以实现一个主从模式的服务集群，master的选举、任务的分配。/master使用一个临时节点，所有集群中的服务器都去争夺创建它，但是只要一个服务器会创建成功他就是master节点，其他服务器就分配到/workers作为从节点，并监听/master节点的变化。/tasks其下子节点存放待分配的任务，而/assign则存放任务的分配情况。

. ZooKeeper内部原理

ZAB

 要理解ZooKeeper就必须要先理解ZAB这一部分内容比较多，参考我写的另外一篇文章ZAB协议。

请求处理

 Leader、Follower和Observer根本上都是服务器。我们在实现服务器时使
用的主要抽象概念是请求处理器。请求处理器是对处理流水线上不同阶段的抽象。每一个服务器实现了一个请求处理器的序列。我们可以把一个处理器想象成添加到请求处理的一个元素。一条请求经过服务器流水线上所有处理器的处理后被称为得到完全处理。

请求处理器
 ZooKeeper代码里有一个叫RequestProcessor的接口。这个接口的主要方法是processRequest，它接受一个Request参数。在一条请求处理器的流水线上，对相邻处理器的请求的处理通常通过队列现实解耦合。当一个处理器有一条请求需要下一个处理器进行处理时，它将这条请求加入队列。然后，它将处于等待状态直到下一个处理器处理完此消息。

Leader

Leade请求处理流水线

1. PrepRequestProcessor：接受客户端的请求并执行这个请求，处理结果则是生成一个事务。
2. ProposalRequestProcessor：准备一个提议，并将该提议发送给跟随者ProposalRequestProcessor将会把所有请求都转发CommitRequestProcessor，而且，对于写操作请求，还会将请求转发给SyncRequestProcessor处理器。
3. SyncRequestProcessor：负责将事务持久化到磁盘上。实际上就是将事务数据按顺序追加到事务日志中，并生成快照数据。
4. AckRequestProcessor：一个简单请求处理器，它仅仅生成确认消息并返回给自己。
5. CommitRequestProcessor：会将收到足够多的确认消息的提议进行提交。
6. ToBeAppliedRequestProcessor：这个处理器会从提议列表中删除那些待接受的提议在FinalRequestProcessor处理器执行后删除这个列表中的元素。
7. FinalRequestProcessor：处理更新类型的请求，并执行读取请求。

Follower

Follower请求处理流水线

1. FollowerRequestProcessor ：转发请求给CommitRequestProcessor，同时也会转发写请求到群首服务器。
2. CommitRequestProcessor：直接转发读取请求到FinalRequestProcessor处理器，而且对于写请求，为了保证执行的顺序，CommitRequestProcessor处理器会在收到一个写请求处理器时暂停后续的请求处理，等待leader提交事务的消息。
3. SyncRequestProcessor：当leader接收到写请求时会将提案发送给每个follower，当收到一个提案，follower会发送这个提议到SyncRequestProcessor处理器。
4. SendRequestProcessor：会向群首发送确认消息。

小结

 平时工作中基本都是面向数据库的CRUD，拥有很丰富的搬砖经验，其实代码的质量和水平并不高。如果要实现一个虽然功能很简单，但是要求可用性和拓展性很高组件，这时候感觉自己的水平就不够用了。所以我们为什么要去看一些优秀的项目，也不是说每一段代码都要掌握的很详细，而是学习其中的思想。比如zookeeper其中服务状态的转换、服务之间的通信、FIFO队列、ZAB协议的实现、对于请求处理器一个个的抽象、数据结构的设计等等，这些都是可以从中学习到的思路。将来自己遇到类似的场景，想一想别人是怎么实现的，自己脑子里才有思路，实现功能很简单，最要的是如何实现的可维护、可拓展。当然zookeeper还有很多需要学习地方，本文只是对它做一个简单的介绍和一些核心思想的实现进行说明，大家想深入了ZooKeeper还是需要参考其他资料。

参考

http://zookeeper.apache.org/
《从PAXOS到ZOOKEEPER分布式一致性原理与实践》
《ZooKeeper：分布式过程协同技术详解》
《Zab: A simple totally ordered broadcast protocol》