Kafka如何使用Zookeep

Zookeeper是什么

• Zookeeper是一个高性能分布式应用协调服务
  • Naming Service【命名服务】
  • 配置管理【分布式配置管理，或者集中式配置管理】
  • Leader Election 【领导选举】
  • 服务发现
  • 同步
  • Group Service
  • Barrier【栅栏】
  • 分布式队列【使用ZooKeeper不太好】
  • 两阶段提交
• 

ZooKeeper工作方式

• Zookeeper集群包含1个Leader，多个Follower。
• 所有的Follower都可提供读服务
• 所有的写操作都会被forward到Leader【也就是说，只有Leader才能写操作】
• Client与Server通过NIO通信【同步非阻塞式IO】。
• 全局串行化所有的写操作【写操作的执行顺序，根据用户发送的顺序去执行，因为这里使用了TCP的FIFO，英文First In First Out 的缩写,是一种先进先出的数据缓存器，保证了接收与发送的顺序相同】
• 保证同一客户端的指令被FIFO执行
• 保证消息通知的FIFO
• 
• 所有的写操作，通过Follower的方式通过Leader；所有的读操作，都可以通过Follower也可以通过Leader

Zab协议 – 广播模式

• Zab：【Zookeeper Atomic Broadcast】Zookeeper原子消息广播协议
• Leader将所有更新（称为proposal【每个跟新称为提议】），顺序发送给Follower
• 当Leader收到半数以上的Follower对此proposal的ACK时，即向所有Follower发送commit消息，并在本地commit该消息。注意：发送commit的条件是超过半数以上的Follower都发送了ACK
• Follower收到Proposal后即将该Proposal写入磁盘，写入成功即返回ACK给Leader。
• 每个Proposal都有一个唯一的单调递增的proposal ID，即zxid
• 
• 读操作：直接读request、reponse
• 写操作：首先request到Follower，Follower在request到Leader，然后Leader将这个请求广播给所有的Follower，之后Follower会给Leader发送一个ACK【半数以上即可】，然后Leader会向所有的Follower发送一个commit，Follower都会被写操作写入，然后返回

Zab协议 – 恢复模式

• 进入恢复模式 当Leader宕机或者丢失大多数Follower后，即进入恢复模式
• 结束恢复模式 新领导被选举出来，且大多数Follower完成了与Leader的状态同步后，恢复模式即结束，从
  而进入广播模式
• 恢复模式的意义
  • 
  • 发现集群中被commit的proposal的最大zxid
  • 建立新的epoch【纪元】，从而保证之前的Leader不能再commit新的Proposal
  • 集群中大部分节点都commit过前一个Leader commit过的消息，而新的Leader是被大部分节点所支持的，所以被之前Leader commit过的Proposal不会丢失，至少被一个节点所保存
  • 新Leader会与所有Follower通信，从而保证大部分节点都拥有最新的
• ​​​​​​​恢复阶段的保证
  • ​​​​​​​若一条消息在一台机器上被deliver也就是commit，那么该消息必须将在每台机器上deliver也就是commit，即使那台机器故障了
  • 一个被skip【跳过】的消息，必须仍然需要被skip
  • ​​​​​​​
  • 例如：
    • Server1是Leader，它发送p1 p2给Server2、Server3，然后commit1，又发送p3，之后commit2，然后Leader挂掉了，可能Server2和Server3没有收到，但是对于Server1而言，他已经commit1和commit2，所以即使Server2和Server3没有收到commit1和commit2的这条消息，新Leader上任之后，也要保证p1和p2能被commit
    • 在Server1中，p3没有commit，也就是没有被广播出去，这个时候Server1挂了，当重新选出Leader这条消息直接被跳过。当Server1恢复过来，并且成为了新的Leader，Server1的p3应该要广播出去，这是Server2和Server3中已经被commit过的消息的zxid比p3的大，那我就拒绝p3的proposal，所以Server2和Server3都不会给Server1关于p3的ACK

Zookeeper一致性保证

• 顺序一致性 从一个客户端发出的更新操作会按发送顺序被顺序执行
• 原子性 更新操作要么成功要么失败，无中间状态
• 单一系统镜像 一个客户端只会看到同一个view，无论它连到哪台服务器
• 可靠性
  • 一旦一个更新被应用，该更新将被持久化，直到有客户端更新该结果
  • 如果一个客户端得到更新成功的状态码，则该更新一定已经生效
  • 任何一个被客户端通过读或者更新“看到”的结果，将不会被回滚，即使是从失败中恢复
• 实时性 保证客户端可在一定时间（通常是几十秒）内看到最新的视图【可能另外的客户端使用的是没有给Leader发送ACK的Follower】

ZooKeeper使用注意事项

• 只保证同一客户端的单一系统镜像，并不保证多个不同客户端在同一时刻一定看到同一系统镜像，如果要实现这种效果，需要在读取数据之前调用sync操作
• Zookeeper读性能好于写性能，因为任何Server均可提供读服务，而只有Leader可提供写服务【适用于读多写少的场景】
• 为了保证Zookeeper本身的Leader Election顺利进行，通常将Server设置为奇数
• 若需容忍f个Server的失败，必须保证有2f+1个以上的Server

Kafka如何使用Zookeeper

• 配置管理【集群】
• Leader Election【领导选举】
• 服务发现【dubbo】