Zookeeper简介
ZooKeeper 是一个开源的分布式 协调服务框架，它是一个为分布式应用提供一致性服务的软件，是雅虎公司创建，是 Google 的 Chubby 一个开源的实现。
Zookeeper设计目标
设计目标主要包含4个：
目标一：简单的数据模型
ZooKeeper使得分布式程序能够通过一个树型结构的名字空间来进行相互协调。
这里所说的树型结构的名字空间，是指ZooKeeper服务器内存中的一个数据模型，其由一系列被称为ZNode的数据节点组成。
目标二：可以构建高可用
一个 ZooKeeper 集群通常由一组机器组成，一般 3～5 台机器就可以组成一个可用的ZooKeeper集群了。
使得分布式单点问题很好解决，而严格的顺序访问控制，使得客户端能够实现一些复杂的同步操作。
目标三：顺序访问
对于来自客户端的每个更新请求，ZooKeeper 都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序。
目标四：构建高性能
由于ZooKeeper将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，因此它尤其适用于以读操作为主的应用场景。
Zookeeper数据模型
Zookeeper 中的所有存储的数据是由 znode 组成的，节点也称为 znode，并以 key/value 形式存储数据。
整体结构类似于 linux 文件系统的模式以树形结构存储，其中根路径以 / 开头。
1.节点构造
如下图所示：
2.节点组成：
图中的每个节点称为一个Znode，每个Znode由3部分组成:
- stat：此为状态信息, 描述该Znode的版本权限等信息；
- data：与该Znode关联的数据；
- children：该Znode下的子节点；
3.节点类型
Znode主要包含4种类型：分别为临时节点、永久节点、序列化节点。
1.临时节点(Ephemeral )
节点的生命周期依赖于创建它们的会话，一旦会话结束，临时节点将被自动删除。
2.永久节点(Persistent )
该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
3.序列化节点(Sequence )
Znode还有一个序列化的特性，如果创建的时候指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。
它的格式为10位数字，没有数值的数位用0补充，例如：0000000001。
4.临时顺序节点
基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
Zookeeper通知Watch
客户端注册监听他关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，Zookeeper会通知客户端。
client端会对某个znode建立一个watcher事件，当该znode发生变化时，zk会主动通知watch这个znode的client，然后client根据znode的变化来做出业务上的改变等。
watch的整体流程如下图所示：
主要流程如下：
1.客户端先向Zookeeper服务端成功注册想要监听的节点状态。
2.同时客户端本地会存储该监听器相关的信息在WatchManager中。
3.当Zookeeper服务端监听的数据状态发生变化时，Zookeeper就会主动通知发送相应事件信息给相关会话客户端，从WatherManager中取出对应Wather对象执行回调逻辑。
Zookeeper工作原理
Zookeeper本身是一个集群结构，有一个leader节点负责写请求，多个follower负责响应读请求，并且在leader节点故障时会自动根据选举机制从剩下的follower中选出新的leader。
1.Zookeeper角色
1.leader
处理所有的事务请求（写请求），可以处理读请求，集群中只能有一个Leader
2. Follower
只能处理读请求，同时作为 Leader的候选节点，即如果Leader宕机，Follower节点要参与到新的Leader选举中，有可能成为新的Leader节点。
3. Observer
Observer：只能处理读请求,不能参与选举。
2.Zookeeper集群
集群为2N+1台，比如N为1的情况就是3台，为什么是3台而不是2台呢？因为集群需要一半以上的机器可用。
3.ZAB协议
Zab协议是为分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议 ，是Zookeeper保证数据一致性的核心算法。
Zab借鉴了Paxos算法但又不像Paxos那样，与Raft算法类似，是一种通用的分布式一致性共识算法。
Zab 协议的原理可细分为如下四个阶段：
1.Leader election(选举阶段)
节点在一开始都处于选举阶段，只要有一个节点得到超过半数节点的票数，它就可以当选准 Leader。
2.Discovery(发现阶段)
在这个阶段，Followers跟准Leader进行通信，同步Followers最近接收的事务提议。
3.Synchronization(同步阶段)
同步阶段主要是利用Leader前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后准Leader才会成为真正的Leader。
4.Broadcast(广播阶段)
到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且Leader 可以进行消息广播，同时如果有新的节点加入，还需要对新节点进行同步。
Zookeeper工作模式
1.Zookeeper从设计模式的角度理解
Zookeeper：是一个基于观察者模式设计的分布式服务管理框架。
2.Zookeeper基于事件监听通知
监听注册到上面的节点的动向，比如：修改、新增、删除等，会实时的通知访问客户端。
3.Zookeeper选举机制
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。
这里会涉及几大核心名字：SID、ZXID、VOTE、Quorum等，如下图所示：
选举的步骤，主要分为如下5步：
第一步:每个Server发出一个投票；
第二步:接收来自各个服务器的投票；
第三步:PK选票并更新选票；
第四步:统计所有投票，判断是否有过半机器接收到相同的投票信息；
第五步:改变服务器状态。
作者简介
陈睿|mikechen，10年+大厂架构经验，BAT资深面试官，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
👇阅读更多mikechen架构文章👇
阿里架构 |双11秒杀 |分布式架构 |负载均衡 |单点登录 |微服务 |云原生 |高并发 |架构师
以上
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》