zookeeper集群角色
- leader:负责事务操作,负责数据同步
- follower:负责数据读取
- observer:只从leader节点同步数据,但不参与投票选举
集群搭建
准备至少3个服务器:192.168.221.128、192.168.221.129、192.168.221.130
在dataDir目录(可在配置文件查看目录)下创建myid文件,文件内容是id号
修改zoo.cfg
# server.id=ip:port1:port2,第一个端口是数据同步,第二个端口是leader选举
server.1=192.168.221.128:2888:3888
server.2=192.168.221.129:2888:3888
server.3=192.168.221.130:2888:3888
server.4=192.168.221.131:2888:3888:observer
开放防火墙端口2181(client连接端口)、2888(数据同步端口)、3888(leader选举端口)
针对observer节点,还需要在zoo.cfg中单独加上标记
peerType=observer
可以通过zkServer.sh status命令查看节点状态
zookeeper弱一致性
zookeeper是弱一致性的,只要过半数据同步成功即代表提交成功,所以有可能有些节点数据还没有同步完成,这时客户端请求获取数据将会读取到不是最新的数据,针对这种情况,zookeeper请求时会携带zxid,对比server上的zxid,如果发现不是最新的zxid,那么请求就会失败,从而保证能够获取到最新的数据
如果想要实现强一致性,可以在获取数据之前,先调用sync()方法对数据进行同步,保证获取到最新数据
顺序一致性模型
leader选举
zab协议
Zookeeper Atomic Broadcast(原子广播协议),基于paxos算法衍生而来
- 崩溃恢复:leader挂了(心跳监测),需要选举新的leader
- 原子广播:数据同步
leader节点算法设计
确保leader已经提交的事务被提交,丢弃已经跳过的事务
- zxid最高,保证新leader具有已经提交的最新提案
- epoch,每次发出leader选举投票,epoch会递增
leader选举参数顺序
- epoch:优先比较epoch,类似选举轮数,以epoch最大的票数为准
- zxid:其次比较zxid,优先选择拥有最新事务id的节点
- myid:如果前两个参数都相同,那么比较myid,节点id最大的优先
数据存储
log存储事务数据,snapshot存储快照数据