网站制作售后,做网站 修复漏洞,专业网站建设设计,网站栏目推介怎么做Zookeeper入门概述特点结构应用场景选举机制节点信息监听原理写数据原理分布式锁概述
Zookeeper是一个开源的分布式的#xff0c;为分布式框架提供协调服务的Apache项目。
Zookeeper 从设计模式的角度来开#xff1a;是一个基于观察者模式设计的分布式服务管理框架#xf…
Zookeeper入门概述特点结构应用场景选举机制节点信息监听原理写数据原理分布式锁概述
Zookeeper是一个开源的分布式的为分布式框架提供协调服务的Apache项目。
Zookeeper 从设计模式的角度来开是一个基于观察者模式设计的分布式服务管理框架它负责存储和管理大家都关心的数据然后接受观察者的注册一旦这些数据的状态发生变化Zookeeper就通知已经注册的观察者做出相应的反应
特点
Zookeeper由一个领导者多个跟随着组成的集群集群中只要有半数以上的节点存活Zookeeper就可以正常服务。因此适合安装基数台服务器全局数据一致每个Server保存一份相同的数据副本Client无论连接到哪个Server数据都是一致的更新请求顺序执行来自同一个Client的更新请求按照发送的顺序依次执行数据更新原子性一次数据更新要么成功要么失败实时性在一定时间范围内Client能读取到最新的数据
结构
Zookeeper的数据模型的结构和Unix文件系统很类似整体上可以看作是一棵树每个节点都是一个ZNode每个ZNode默认存储1MB的数据(因此不适合存过大的数据)每个ZNode都可以通过其路径来唯一标识。
Zookeeper 文件系统 通知机制
应用场景 一般要求一个集群中所有节点的配置信息是一致的对配置文件修改后希望能够快速同步到各个节点上比如 kafka集群 实现 可将配置信息写入Zookeeper上的一个Znode各个客户端服务器监听这个Znode一旦Znode中的数据被修改Zookeeper将通知各个客户端服务器 分布式环境中实时掌握每个节点的状态是必要的可以根据节点实时状态做出调整Zookeeper可以实现实时监控节点状态变化 实现 可将节点信息写入Zookeeper上的一个ZNode监听这个ZNode可以获取他的实时状态变化
选举机制
Zookeeper分为leader 和 follower 两种
假设有五台服务器初始的选举方法
服务器1先启动发起第一次选举。服务器1会投自己一票此时服务器1只有一票没有达到半数以上无法选举成功服务器1的状态为Looking服务器2启动再次发起选举服务器1和2先投自己一票然后交换选票信息此时服务器1发现服务器2的myid比自己目前投票的大就将投票改为服务器2此时服务器1没有票服务器2两票但是此时并没有服务器的票数超过半数所以无法选举成功服务器12状态都保持Looking服务器3启动发起一次选举。和上述过程相似此时服务器3的myid最大会获得3票因为已经过半所以服务器3为Leader,服务器12为follower。并改变服务器12的状态为Following, 服务器3的状态为Leading服务器4启动发起选举因为服务器123的状态都不是Looking所以不会再更改选票信息最后服务器3三票服务器4自己投了一票服务器4将自己的票投给服务器3并将状态改为Following服务器5同服务器4一样
SID 服务器的ID唯一标识Zookeeper集群中的机器每台机器都不可以重复和myid一致 ZXID 事务IDZXID是一个事务ID用来标识一次服务器状态的变更。在某一时刻集群中的每台机器的ZXID的值不一定完全一致这与Zookeeper对客户端更新请求的处理逻辑有关 Epoch 每个Leader任期的代号没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加
Zookeeper选举Leader的情况
服务器初始化启动服务器运行期间无法和Leader保持连接
当机器进入选举流程时当前集群可能会处于以下两种状态
集群中是存在Leader的。这种情况下机器去选举Leader会被告知当前服务器的Leader信息该机器只要和Leader建立连接即可集群中不存在Leader。当有Leader故障时集群会选择新的Leader选取的规则为1比较EPOCH大的胜出 2ECOPH相同是比较事务Id即ZXID大的胜出 3事务ID相同时比较服务器ID大的胜出
节点信息
节点信息
持久客户端和服务器断开连接后创建的节点不删除短暂客户端和服务器断开连接后节点会自己删除
节点类型
持久化目录节点 客户端与Zookeeper断开连接后节点依旧存在持久化顺序编号目录节点客户端与Zookeeper断开连接后该节点依旧存在只是Zookeeper给该节点名称进行顺序编号临时目录节点客户端与Zookeeper断开连接后节点被删除临时顺序编号目录节点客户端与Zookeeper断开连接后该节点被删除只是Zookeeper给该节点名称进行顺序编号
监听原理
首先需要一个main线程在main线程中创建Zookeeper的客户端这时会创建两个线程一个负责网络连接通信一个负责监听通过connect线程将注册的监听事件发给zookeeper在zookeeper的注册监听器列表中将注册的监听事件添加到列表中zookeeper监听到有数据或路径变化后将这个消息发生给listener线程listener线程内部调用了process方法
写数据原理
对Leader节点进行写操作时客户端将写数据发给LeaderLeader将请求发送给一个Fllower,当Follower节点收到后回复给LeaderLeader统计目前有多少Follower收到了如果已经过半就回复给客户端剩余的Follower慢慢写入对Follower节点进行写操作时客户端将写数据发给FollowerFollower先把请求发给LeaderLeader向发送给他的Follower再次发送数据来确保接受的数据是正确的Follower收到后向Leader发送确认请求。之后再依次向各个别的Follower发送写数据当有过半的节点确认后Leader向第一次客户端写入的Follower发送确认请求Follower再向客户端进行确认。
分布式锁
服务端接收到客户端的请求后
在/locks节点下创建一个临时顺序节点判断自己是不是当前节点下最小的节点如果是则获取到锁。如果不是则对前一个节点进行监听获取到锁、处理完业务后。delete节点去释放锁然后下面的节点将收到通知重复第二步的操作
