zookeeper-八股文
- 什么是ZAB协议-※
- 为什么ZK可以用来做注册中心-√
- ZK的leader领导选举流程是怎样的
- ZK节点数据是如何同步的[或者说同步流程有哪些?]
- 简述ZK的命名服务、配置管理与集群管理
- ZK的watch机制
- ZK和euraka的区别
- ZK如何实现分布式锁
ZAB协议是保证ZK一致性的原子广播协议
ZK实现一致性共三个阶段:
1.选举leader:因为只有leader节点处理写操作
2.数据同步:所有follower要与leader保持数据一致性
3.请求广播:收到写请求的时候,会将写请求广播到所有follower节点,从而尽量使得所有节点的写操作是同时处理的
1. ZK可以保存对应的key-value
2. ZK的watch机制可以做服务发现
3. ZK底层用的多线程模型,性能也还行
ZK可以监控每个服务的连接情况,从而通报给监控的节点,从而更新对应的服务URL
核心是投票选举
所有follower
1.首先投票给自己
2.两两PK,赢家不做操作,输家将票改投赢家,或者赢家的赢家。
3.如果PK是平局,则票还是投给自己
4.PK结束,输家将票数情况传给下一个PK对象
5.如果有节点PK赢过一半以上的节点,则直接被选为leader
1.集群启动时,首先选举出leader节点
2.leader节点收到写请求
-------------日志持久化-----------------------
3.leader将日志发送给follower
4.follower日志持久化成功以后,返回ACK确认给leader
---------------内存更新-----------------------
5.leader收到半数以上的ACK以后,leader更新内存数据
6.将commit指令发送给从节点
---------------返回客户端------------------------------
7.leader节点返回响应成功
命名服务:通过某个名字获得对应的URL等配置,由于ZK可以保存类似的KV对,将key设为名字即可获得对应的URL
配置管理:将服务地址等多个多个配置,保存到ZK的节点中。配置改动以后,ZK通过watch机制可以通知到其他服务
集群管理:减少服务或者服务不可用时,ZK连接断开以后,watch机制也能将服务改动通知到其他服务
实体:
客户端线程
客户端watchManage
ZK
消息:
消息次数:
每个watch监听仅生效一次,每次通知过后,监听器会被移除,需要重新注册
消息内容:
仅通知事件本身,不通知事件内容
流程:
1.客户端向ZK注册watch监听器
2.ZK返回监听器相关信息,并存入客户端watchManage
3.ZK监听到变化,客户端调用watcher对象的回调方法
ZK可以通过同一级节点的唯一性实现分布式锁
思路:
1.针对每个锁都生成一个节点A
2.每个竞争线程每次竞争锁的时候,都在生成的A下面生成临时节点,A-1,A-2等等
3.排序最上面的节点获取到锁,进入实际逻辑处理
4.A下面每个节点都通过ZK的watch机制,监听前一个节点,一旦前一个节点逻辑处理完,删除节点以后,就判断前面是否还有节点,直至自己获取到锁。