一个分布式应用,数据包在节点之间传递,一旦网络故障,发送方不知道接收方是否接收到了数据,处理起来会非常麻烦。
新增加一层协调者,来管理子任务是一种常见的解决方案,而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)数据一致性是协调者很重要的特点;