zookeeper

Zookeeper的工作原理是什么?[面试7.0]

Zookeeper的ZAB协议

Zookeeper使用ZAB协议保证数据的一致性,ZAB协议是一种支持崩溃恢复的原子广播协议,它包括两种模式:
广播模式(同步):
客户端的事务请求到达Leader时,首先生成事务提案(Proposal),每一个Proposal有一个ZXID
向所有Follower发起事务提案广播并等待Follower的ack确认,若有过半ack已经确认,就可以向所有Follower发起Commit事务(2PC必须要等到所有的参与者反馈ack)
恢复模式(选主): 若Leader挂了或过半的Follower连不上Leader了就会执行崩溃恢复,ZAB则通过崩溃恢复来保证数据一致性问题,崩溃恢复的关键是选一个具有最大ZXID值的事务提案的Follower为Leader,因为这样可以确保新的Leader一定是有之前所有已经提交的事务提案

zookeeper怎么保证事务的顺序一致性的?
每一个Proposal有一个ZXID,ZXID的高32位是Leader的周期epoch编号,低32位是一个单调递增计数器,每次选了一个新得Leader出来后,高32位epoch会根据ZXID解析出来并加1,低32位则从0开始,这样做保证了事务提案的顺序性
ZAB向所有Follower广播时,采用TCP协议,保证了传输的可靠性和顺序性
ZAB向所有Follower广播时,会对每一个Follower都分配一个独立的队列,然后会将事务提案(Proposal)放入队列,这样做保证了Follower接收的顺序性

什么是Zookeeper脑裂?Zookeeper脑裂会产生什么问题?怎么解决?[面试7.0]

脑裂:
若两个机房A和B都有Zookeeper,A里面有一个leader,其他都是follower,突然一个follower由于网络原因发现leader连接不上了,便认为它挂了,就会重新选举一个新的leader出来,然而实际上A里面的原leader并没有挂,现在集群中出现了两个leader,这就是Zookeeper脑裂
脑裂带来的问题:
产生脑裂后会出现两个集群对外提供服务的情况,数据会冲突
脑裂问题的解决:
实现一个QuorumVerifier接口然后验证是否符合过半机制
过半机制: 选举Leader时超过半数投票才满足条件即num>total/2
为啥不能等于半数呢: 为了避免再次脑裂,要的是A和B两个Zk服务器实例数不能自己选举为leader,必须至少有一个对方服务器的实例也同意,这样就能避免再次出现两个Leader的情况

Zookeeper有哪几种节点类型?[面试7.0]

持久化节点(PERSISTENT)
持久化顺序节点(PERSISTENT_SEQUENTIAL)
临时节点(EPHEMERAL)
临时顺序节点(EPHEMERAL_SEQUENTIAL)
Zookeeper作为注册中心和分布式锁时都是创建的临时顺序节点

Zookeeper有哪些角色?[面试7.0]

Leader: 服务的协调者,保证集群事务处理的顺序性
Follower: 处理客户端的非事务请求,转发事务请求给Leader服务器,参与Proposal投票选举和Leader投票选举
Observer:
处理客户端的非事务请求,不参与任何形式的投票,跟Follwer是样的,只是不参与投票
可以配置该Zookeeper为观察者,可以动态扩展Observer来解决由于多个Follower选举产生的写性能问题
也可以用Observer来实现不同Zookeeper集群之间的通信,来解决集群之间网络延迟带来的故障检测,误报或集群分区问题

Zookeeper怎么实现注册中心的?[面试7.0]

zookeeper利用了临时顺序节点和节点watch事件机制实现注册中心
服务提供者会向zookeeper的某一个节点(比如/registry)下写入一个子节点(临时有序子节点),节点的值就是自己服务的IP和端口
服务消费者启动时向zookeeper的/registry节点注册一个子节点变更事件,同时从该节点拉取所有子节点,获得服务提供者的地址
当某个服务提供者与zookeeper断开后,临时节点会自动删除
客户端收到zookeeper的节点变更通知后,重新拉取子节点信息

Zookeeper怎么实现分布式锁?[面试7.0]

获取锁时创建一个locks根节点
然后在根节点下创建临时顺序节点,排列序号最小的获得锁,其他节点按顺序监听前一个节点的状态
获得锁的节点执行任务,执行完后释放锁并删除节点,这时候通知监听者,然后监听者取消监听并尝试获取锁

Zookeeper的Leader选举机制是怎么样的?[面试7.0]

服务启动时的选举:
发起投票: 每个Server都会发出一个投票,且每个Server都会给自己投票,投票的信息包含(myid(唯一标识Id),ZXID(本次投票事务提案Id)),由于是启动的时候投票,所有ZXID都是0,投票后将信息发给所有Server
接收投票: 每个Server都会接收到其他Server的投票信息,接收到后对票进行合法性检查,主要是检查是否是本轮投票以及是否是LOOKING状态
处理投票: 优先比较自己和接收到的ZXID,选ZXID大的为Leader,若ZXID相同就比较myid并选择myid大的为Leader
统计投票: 若集群中超过半数的投票都相同了,就认为Leader已经选好了
改变状态: 若Leader选好了,就将Leader状态修改为LEADING,将Follwer状态修改为FOLLWERING

服务运行时的选举:
改变状态: Leader挂了后,其他机器状态修改为LOOKING状态
发起投票: 由于是运行期间,所以ZXID可能是不同的,选举算法还是跟服务启动时的发起投票时是一样的
接下来的: 接收投票,处理投票,统计投票,改变状态和服务启动时也是一样的