一、Zookeeper是什么?
- Naming Service
- 配置管理
- Leader Election
- 服务发现
- 同步
- Group Service
- Barrier
- 分布式队列
- 两阶段提交
二、Zookeeper工作方式
- Zookeeper集群包含1个Leader,多个Follower。
- 所有的Follower都可提供读服务
- 所有的写操作都会被forward到Leader
- Client与Server通过NIO通信。
- 全局串行化所有的写操作
- 保证同一客户端的指令被FIFO执行
- 保证消息通知的FIFO
三、Zookeeper (Zab协议 – 广播模式)
- Leader将所有更新(称为proposal),顺序发送给Follower
- 当Leader收到半数以上的Follower对此proposal的ACK时,即向所有Follower发送 commit消息,并在本地commit该消息
- Follower收到Proposal后即将该Proposal写入磁盘,写入成功即返回ACK给Leader
- 每个Proposal都有一个唯一的单调递增的proposal ID,即zxid
四、Zookeeper (Zab协议 – 恢复模式)
- 进入恢复模式 当Leader宕机或者丢失大多数Follower后,即进入恢复模式
- 结束恢复模式 新领导被选举出来,且大多数Follower完成了与Leader的状态同步后,恢复模式即结束,从 而进入广播模式
- 恢复模式的意义
»发现集群中被commit的proposal的最大zxid
»建立新的epoch,从而保证之前的Leader不能再commit新的Proposal
»集群中大部分节点都commit过前一个Leader commit过的消息,而新的Leader是被大部分节点所支持的,所以被之前Leader commit过的Proposal不会丢失,至少被一个节点所保存
»新Leader会与所有Follower通信,从而保证大部分节点都拥有最新的数据 - 恢复阶段的保证
»若一条消息在一台机器上被commit,那么该消息必须将在每台机器上commit,即使那台机器故障了
»一个被skip的消息,必须仍然需要被skip
五、Zookeeper一致性保证
顺序一致性 从一个客户端发出的更新操作会按发送顺序被顺序执行
原子性 更新操作要么成功要么失败,无中间状态
单一系统镜像 一个客户端只会看到同一个view,无论它连到哪台服务器
可靠性
一旦一个更新被应用,该更新将被持久化,直到有客户端更新该结果
如果一个客户端得到更新成功的状态码,则该更新一定已经生效
任何一个被客户端通过读或者更新“看到”的结果,将不会被回滚,即使是从失败中恢复
实时性
六、Zookeeper使用注意事项
- 只保证同一客户端的单一系统镜像,并不保证多个不同客户端在同一时刻一定看到同一系统镜像,如果要实现这种 效果,需要在读取数据之前调用sync操作
- Zookeeper读性能好于写性能,因为任何Server均可提供读服务,而只有Leader可提供写服务
- 为了保证Zookeeper本身的Leader Election顺利进行,通常将Server设置为奇数
- 若需容忍f个Server的失败,必须保证有2f+1个以上的Server
六、Kafka如何使用Zookeeper
- 配置管理
- Leader Election
- 服务发现