分布式应用，ZooKeeper做了什么？

一个分布式应用，数据包在节点之间传递，一旦网络故障，发送方不知道接收方是否接收到了数据，处理起来会非常麻烦。

新增加一层协调者，来管理子任务是一种常见的解决方案，而ZooKeeper就经常承担协调者的角色。

ZK核心功能是什么？

简单来说，客户端连接ZK，监听ZK上的数据。如果有人修改了ZK中被监听的数据，ZK反过来会告诉客户端数据的变更。

举个栗子:

在Kafka的设计中，Kafka的一个节点在ZK中创建了一个数据，谁先创建成功谁就是集群的主节点，其余的节点都会去监听这个数据。

如果主节点宕机了，ZK对应的数据就会发生变更，既而监听这个数据的其余节点就会感知到主节点宕机了，然后Kafka就需要进行选举。

画外音：ZK协调Kafka集群状态。

ZK的内核，是怎么设计的呢？

在 zookeeper 集群中， 节点的角色有三种：

（1）leader，为客户端提供读写功能。在选举中负责投票的发起和决议；

（2）follower，为客户单提供读服务，写请求转发给leader。在选举中进行投票；

（3）observer，为客户端提供读服务，写请求转发leader。不参与一致性协议过半写入和选举机制，只为提高读性能；

三者关系如下：

分布式架构中，数据一致性很关键，ZK是怎么保证数据一致性的呢?

ZK采用的ZAB（Zookeeper Atomic BroadCast）协议实现数据一致性，主要有数据写入和故障恢复（选举）模式。

数据写入-过半写机制流程

（1）ZooKeeper写数据都是leader节点，leader节点会把数据通过proposal请求发送到所有节点；

（2）所有节点收到数据以后都会写到自己到本地磁盘上面，成功后发送一个ack请求给leader；

（3）leader只要接受到过半的节点ack响应，就会发送commit消息给各个节点，各个节点就会把消息放入到内存中；

（4）返回客户端写入成功；

故障恢复-选主模式流程

ZAB的选举发生在服务启动和leader节点异常时。

用服务启动举个例子，假设有三台服务器组成的ZK集群，它们的serverid从1-3，假设这些服务器依序启动，来看看会发生什么：

（1）1启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的选举状态一直是LOOKING状态；

（2）2启动，它与服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出；

（3）此时二台服务器（超过半数）选举了服务器2，所以它成为了这次选举的leader；

（4）3启动，根据前面的分析，理论上服务器3应该是服务器1,2,3中最大的，但是由于前面已经有半数以上的服务器选举了服务器2，所以它只能接收当小弟的命了；

总结

（1）ZooKeeper是应用很广的协调服务；

（2）Zookeeper常用于主动通知客户端数据的变更；

（3）数据一致性是协调者很重要的特点；

福利来了！！！

免费直播，三天搞定源码级ZooKeeper。

事件：ZooKeeper企业实战&原理剖析

人物：腾讯云全球第一位认证金牌讲师，马中华

时间：7.21-7.23（三天）20:00

分享提纲是什么？

DAY1（7.21）

（1）抽屉原理、分布式事务、分布式一致性算法详解

（2）全网最详尽CAP理论剖析；

（3）ZooKeeper的架构设计实现和核心工作机制；

（4）ZooKeeper的监听机制详解；

（5）ZooKeeper的数据读写和数据同步深度剖析；

DAY2（7.22）

（1）基于ZooKeeper实现服务发布订阅；

（2）基于ZooKeeper实现服务器动态上下线感知；

（3）基于ZooKeeper实现分布式锁；

（4）基于ZooKeeper实现选举算法；

（5）基于典型常见应用场景的实现思路详解；

DAY3（7.23）

（1）ZooKeeper序列化和网络通信协议源码详解；

（2）ZooKeeper集群启动过程源码分析；

（3）ZooKeeper集群的Leader Election算法源码详解；

（4）ZooKeeper服务端是如何处理一次客户端请求的源码详尽剖析；

（5）ZooKeeper如何保证各节点数据一致性源码分析；

（6）ZAB协议：崩溃恢复和消息广播源码详解；

有技术资料么（以下所有课程，免费）？

奈学教育，价值千元的在线视频，免费送！

画外音：这福利，老板也真是拼了。

如何参加免费训练营，领取千元课程资料？

扫码获取直播地址，免费领资料

祝大家在P8之路上前行，阅读原文，福利等你。

阅读原文，3天搞定zookeeper源码。