概述
定位
分布式协调服务
在分布式系统中共享配置, 协调锁资源, 提供命名服务
数据结构
类似树, 基于节点, Znode
不同于树的节点, Znode的引用方式是路径引用
这样的层级结构，让每一个Znode节点拥有唯一的路径，就像命名空间一样对不同信息作出清晰的隔离
/动物/仓鼠
Znode包含:
data：Znode存储的数据信息。
ACL：记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。
stat：包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。
child：当前节点的子节点引用，类似于二叉树的左孩子右孩子。
Znode并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，
每个节点的数据最大不能超过1MB。
常用API
create 创建节点
delete 删除节点
exists 判断节点是否存在
getData 获得一个节点的数据
setData 设置一个节点的数据
getChildren 获取节点下的所有子节点
这其中，exists，getData，getChildren属于读操作。
Zookeeper客户端在请求读操作的时候，可以选择是否设置Watch。
当这个Znode发生改变，也就是调用了create，delete，setData方法的时候，
将会触发Znode上注册的对应事件，请求Watch的客户端会接收到异步通知。
当被Watch的Znode已删除，
服务端会查找哈希表WatchTable，找到该Znode对应的所有Watcher，异步通知客户端，
并且删除哈希表中对应的Key-Value
WatchTable:
Key: /动物/猫
Value: [客户端A]
如何实现分布式一致性
为了应对单机挂掉的情况, 维护了一个集群
Zookeeper Service集群是一主多从结构
在更新数据时，首先更新到主节点（这里的节点是指服务器，不是Znode），再同步到从节点。
在读取数据时，直接读取任意从节点。
为了保证主从节点的数据一致性，Zookeeper采用了ZAB协议，这种协议非常类似于一致性算法Paxos和Raft。
ZAB
Zookeeper Atomic Broadcast
解决了Zookeeper集群崩溃恢复, 以及主从同步数据的问题
Zab协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性。
它依靠事务ID和版本号，保证了数据的更新和读取是有序的。
三种节点状态
Looking ：选举状态。
Following ：Follower节点（从节点）所处的状态。
Leading ：Leader节点（主节点）所处状态。
最大ZXID也就是节点本地的最新事务编号，
包含epoch和计数两部分。
epoch是纪元的意思，相当于Raft算法选主时候的term。
崩溃恢复
假如Zookeeper当前的主节点挂掉了，集群会进行崩溃恢复。
ZAB的崩溃恢复分成三个阶段：
1. Leader election 选举阶段，
此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票，
投票当中包含自己的服务器ID和最新事务ID（ZXID）。
接下来，节点会用自身的ZXID和从其他节点接收到的ZXID做比较，
如果发现别人家的ZXID比自己大，也就是数据比自己新，那么就重新发起投票，
投票给目前已知最大的ZXID所属节点。
每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。
如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。
其他节点的状态变为Following。
2.Discovery 发现阶段，
用于在从节点中发现最新的ZXID和事务日志。
是为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。
这一阶段，Leader集思广益，接收所有Follower发来各自的最新epoch值。
Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。
各个Follower收到全新的epoch后，返回ACK给Leader，
带上各自最大的ZXID和历史事务日志。
Leader选出最大的ZXID，并更新自身历史日志。
3.Synchronization 同步阶段，
把Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。
只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。
自此，故障恢复正式完成。
写入数据
Zookeeper常规情况下更新数据的时候，由Leader广播到所有的Follower
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式，先发送Propose广播给Follower。
4.Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader。
5.Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower。
应用场景
1.分布式锁
这是雅虎研究员设计Zookeeper的初衷。
利用Zookeeper的临时顺序节点，可以轻松实现分布式锁。
2.服务注册和发现
利用Znode和Watcher，可以实现分布式服务的注册和发现。
最著名的应用就是阿里的分布式RPC框架Dubbo。
3.共享配置和状态信息
Redis的分布式解决方案Codis，就利用了Zookeeper来存放数据路由表和 codis-proxy 节点的元信息。
同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。
此外，Kafka、HBase、Hadoop，也都依靠Zookeeper同步节点信息，实现高可用。
原文链接
https://juejin.im/post/5b037d5c518825426e024473
Annex
若有收获，就点个赞吧
0 人点赞
