分布式应用,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源码。

猜你喜欢

转载自blog.csdn.net/shenjian58/article/details/107502498