1. zookeeper应用场景
- 数据发布/订阅:配置中心
- 负载均衡:提供服务者列表
- 命名服务:提供服务名到地址的映射
- 分布式协调/通知: watch机制和临时节点,获取各节点的进度,通过修改节点通知
- 集群管理:是否有机器退出或加入、选举master
- 分布式锁
- 分布式队列
2. zab协议核心
paxos变体,保证了提交的有序性
基于崩溃恢复的原子广播协议
2.1 崩溃
集群启动或leader服务器出现网路中断、异常退出时、不存在超过半数的follower节点通信
2.2 恢复的两个原则
- 已处理的消息不能丢失
follower接收到leader节点的commit指令已经执行写操作 - 被丢弃的消息不能再现
未收到commit指令的消息需要丢弃
恢复过程
Master选举>半数follower完成数据同步
2.3 原子广播
- 所有的写请求由一个全局的服务器协调处理,这样的服务器叫做leader,协调的服务器叫做follower。
- leader将客户端的写请求封装成一个事物并广播给所有的follower(同步)。
- leader接受到半数follower的ack,广播commit(异步)并进行本地提交。
3. 事物的有序性
leader为每个事物附一个全局唯一的64位自增id即zxid,通过对比zxid的大小实现事物的有序性
4. 三类角色
- leader
- follower
- observer 避免follower节点过多导致半数节点数量上升,影响事物提交性能
别名
learner = follower+observer
quorumServer = follower+leader
5. 三个数据
- zxid 64位long,高32表示epoch,低32位表示xid
- epoch leader任期
- xid 自增id
6.三种状态
- looking 选举状态
- following
- leading
7.四个阶段
- 选举阶段
- 发现阶段
- 同步阶段
- 广播阶段