从设计模式角度理解
观察者模式设计的分布式服务管理框架,负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,zk就将负责通知已经在zk上注册的那些观察者做出响应的反应;zk=文件系统+通知系统;
1.一个leader和多个follower组成的集群
2.只要半数以上节点存活,就可以提供服务,适合安装奇数台服务器
3.全局数据一致,每个server保存一份相同数据的副本,client无论连到哪个server,数据都是一致
4.来自同一个client的更新请求按其发送顺序依次执行
5.数据更新原子性,一次数据更新要么成功要么失败
6.实时性,在一定时间范围内,client能读到最新数据
节点数多,好处:提高可靠性,坏处,增加通信延迟
数据结构
与unix文件系统类似,整体上可以看做一棵树,每个节点称做一个znode,默认存储1MB数据,每个znode都可以通过其路径唯一标识;
应用场景
统一命名服务
分布式环境下,经常需要对应用/服务进行统一命名,便于识别
统一配置管理
一个集群中所有节点配置信息一致;修改后快速同步到各个节点;
统一集群管理
实时掌握每个节点的状态,将节点信息写入zk上的一个znode
服务器动态上下线
客户端实时洞察到服务器上下线的变化
软负载均衡
记录每个server的访问数,让访问最少的server去处理最新的客户端请求
节点类型
1.持久节点(PERSISTENT)
所谓持久节点,是指在节点创建后,就一直存在,直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失
2.持久顺序节点(PERSISTENT_SEQUENTIAL)
给创建的持久节点后面加上序号后缀。 非常适用于分布式锁、分布式选举等场景
3.临时节点(EPHEMERAL)
如果客户端会话失效,那么这个节点就会自动被清除掉。会话失效,而非连接断开。临时节点下面不能创建子节点
4.临时顺序节点(EPHEMERAL_SEQUENTIAL)
配置参数解读
配置文件zoo.cfg中参数含义解读
1.tickTime=2000
通信心跳时间,zk服务器与客户端心跳时间,单位毫秒
2.initLimit=10
LF初始通信时限,leader和follower初始连接时,能容忍的最多心跳数(tickTime的数量)
3.syncLimit=5
LF同步通信时限,超时就会从服务器列表中删除follower
4.dataDir
保存zk中的数据,默认tmp目录,容易被linux系统定期删除(需要修改)
5.clientPort=2181
客户端连接端口,通常不做修改
选举机制
首次
先选自己,然后把选票投给myid较大的,如果leader被选出,其它自动变为follower,再新增服务直接变为follower
sid:服务器id,用来唯一标识一台zk集群中的机器,每台机器不能重复,和myid一致
zxid:事务id,用来标识一次服务器状态的变更。在某一时刻,集群中的每台机器的zxid值不一定完全一致,这和zk服务器对于客户端”更新请求“的处理逻辑有关
epoch:每个leader任期的代号。没有leader时同一轮投票过程中的逻辑时钟值是相同的,每投完一次票这个数据就会增加。
非首次
以下两种情况,就开始leader选举:
1.服务器启动
2.运行期间无法和leader保持连接
当一台机器进入leader选举流程时,当前集群也可能处于两种状态:
1.集群中本来已经存在一个leader,只能建立连接作为follower
2.集群中确实不存在leader
选举规则:按照优先级比较epoch---zxid---sid
客服端写入流程
1.写入leader
写入follower,获得应答,超过半数写入成功,则leader发送ack给客户端
2.写入follower
转发给leader先写入,自己再写入,超过半数写入成功,则leader发送ack给接收的follower,最后follower发送ack给客户端
服务器动态上下线案例
1.服务端注册到zk集群临时节点(/servers)-e -s
2.客户端监听znode(/servers)下面子节点的增加或删除
分布式锁案例
1.接收请求后,在locks节点下建立一个临时顺序节点
2.判断自己是不是最小节点,是则获取锁,如果不是则监听前一个;
3.业务处理结束,删除顺序节点释放锁,后面的节点将收到通知,重复步骤2判断;
有现成分布式锁框架使用,curator框架
拜占庭将军问题
参考