在学习一样技术之前，咱们需要先想一下，为什么需要学这一门技术？
许多分布式系统都是基于ZK作为底层核心组件对外提供服务，比如Kafka中，将Broker注册到ZK中，此时ZK充当着多重角色，比如注册中心、选举等；再比如说，我公司目前很多项目都是Dubbo，都是需要基于ZK实现服务发现和注册。
另外，ZK内其实也有很多优秀的算法和设计思想，熟悉ZK源码，也可以提升自己的“内功”。
如何快速入门Zookeeper呢？最简单的方式就是直接看 Zookeeper官网 啦！建议读者多参考官方文档和博客内容一起食用，效果更佳噢～
Zookeeper是什么？
字面上意思可以认为是“动物园管理员”！为什么会有这一个名字呢？先来看下 Hadoop 的生态系统图
HADOOP-ECOSYSTEM-Edureka.png
Zookeeper的 Logo 看起来就像个“铲屎官”，服务动物园内的动物们。
“A Distributed Coordination Service for Distributed Applications”，这是摘取官方的解释，我们可以得知Zookeeper 是一个为分布式框架提供协调服务的东东。
举些例子，有哪些分布式框架使用Zookeeper：
-
Kafka（最新版本中其实去掉ZK作为注册中心）
-
Hbase
-
Dubbo
-
HDFS
-
等等
Zookeeper的常用使用场景有哪些？
-
分布式锁
-
注册中心
-
Leader选举
ZK的作用不止上面几个，其实还可以做到负载均衡、统一配置、分布式队列等，但使用场景相对少，企业级系统中，会使用其他更加专业的框架组件。
分布式锁、注册中心、Leader选举将会是ZK系列中，重点分享的内容，敬请期待哈~
重点概念
在ZK中，需要先了解一些专业名词的概念，但不会一下子都列出来，当之后遇到的时候，再重点分析...
1. ZK角色
在ZK集群中，会分为Leader、Follower和Observer角色。
Leader作为集群的大佬，承担写请求和部分读请求；Follower作为Leader的小弟，将会承担部分读请求，当接收到写请求的时候会转发给Leader，由Leader处理写请求；Observer就有点特殊，Observer节点不参与选举和消息过半机制，这个不清楚的读者可以暂时有个记忆就行，之后遇到会重点说明。
ZK集群处理读写请求概览.png
2. 节点类型
-
持久节点(PERSISTENT)
-
持久顺序节点(PERSISTENT_SEQUENTIAL)
-
临时节点(EPHEMERAL)
-
顺序临时节点(EPHEMERAL_SEQUENTIAL)
实际上，节点只分为持久节点和临时节点，但有些场景需要保证顺序，所以就会在持久或临时节点的基础上，添加序号（递增的方式），形成持久顺序节点和临时顺序节点。</br> 那么什么是持久节点，什么是临时节点呢？最直观的一个现象就是，每个ZK客户端连接ZK集群后，都会产生一个节点，如果ZK客户端下线后，节点还存在的就是持久节点，若ZK客户端下线后节点也随着消失，那么该节点就是临时节点。
3. 监听回调
在ZK客户端启动前，可以自定义监听回调函数，这个有什么作用呢？客户端启动后会将监听事件发送给Zookeeper集群，Zookeeper集群中有一个用于记录监听事件的列表，当客户端监听的目录节点发生变化，如节点数据变更、节点增删等，就会通过ZK集群的监听列表，找到对应的客户端回调监听函数，那么客户端这边就可以根据业务场景，做出相应的动作。
4. ZAB协议
ZAB协议的全称是：ZooKeeper Atomic Broadcast。ZAB是Zookeeper保证数据一致性的核心算法。借鉴了Paxos算法的思想，特地为Zookeeper设计的支持崩溃恢复的原子广播协议。其包括两种基本模式：消息广播和崩溃恢复
消息广播指的是，集群中只有一个Leader处理写请求，并将写请求的事件广播给所有Follower，且能够保证数据不丢失。（也就是说，消息的写入是原子性的，因为只能有leader写入）
崩溃恢复指的是，当ZK集群刚启动还没选举出Leader或Leader因故障、重启、网络等原因的时候，ZAB协议会进入崩溃恢复模式，其目的就是为了选举新的Leader，且保证新Leader的数据是最新的，这样就能够避免因为Leader故障而导致单点丢失消息的情况，至于ZAB具体的原理，各位可以先看下以下参考文章，后续有机会我再专门写一篇关于 ZAB 协议的文章~
Zookeeper架构特点
数据模型
ZK内的数据模型结构和Unix文件系统非常相似，是一个有层级关系的树形数据结构。在ZK内，树形的数据结构使用称为ZNode节点保存数据，ZNode是ZK中数据结构最小单元，不仅能够保存数据，还能挂载子节点，形成一个有层次关系的树。
值得注意的是，ZNode的创建是纯内存操作的，所以速度很快，然后在ZK内部会定期将ZNode的数据持久化到磁盘上。
数据模型.png
集群部署
众所周知，在实际的企业应用，面对高并发的场景下，肯定是不能单节点部署，而是通过集群部署保证高并发、高性能、高可用（简称三高）。
高性能：由于ZNode节点是纯内存操作，只要ZK部署在高配置的服务器中，三台ZK服务器抗住每秒几万的请求都是没问题的。 高可用：只要部署奇数的服务器集群（比如3台、5台、11台机器），只要不超过一半的服务器宕机，都能保证ZK集群可用。 高并发：因为ZNode是纯内存操作，所以在写数据的时候，速度是很快；而ZK集群中Leader和Follower节点都能处理读请求，所以ZK集群高并发能力是很强的。
顺序一致性
基于ZAB协议，写请求统一由Leader服务器处理，然后由Leader将写数据的请求广播给其他Follower。
但会不会由于种种原因，如网络波动、Leader脑裂、Follower宕机等，导致消息不一致？
实际上，在ZK中采用2PC两阶段提交的思想，结合ZAB消息广播保证数据一致性。值得注意的是，Zookeeper只能保证最终一致性，并不能保证强一致性
那么具体是怎么保证数据最终一致性的呢？感兴趣的读者可以看下我另外一篇拙作【TODO...】
参考资料：
《从Paxos到Zookeeper分布式一致性原理与实践》
如果觉得文章不错的话，麻烦点个赞哈，你的鼓励就是我的动力！对于文章有哪里不清楚或者有误的地方，欢迎在评论区留言~
网友评论