ZooKeeper集群

ZooKeeper集群

• 可靠的ZooKeeper服务
• 只要集群大多数都准备好了，就可以使用这项服务
• 容错集群设置至少需要3个服务器，强烈建议使用基数个服务器
• 建议每个服务运行在单独的服务器上

ZooKeeper集群搭建
配置

tickTime=2000
dataDir=D://tools/zookeeper-3.4.13/tmp/zookeeper
clientPort=2181
initLimit=10
syncLimit=5
server.1=zoo1.2888:3888
server.2=zoo2.2888:3888
server.3=zoo3.2888:3888

• initLimit：集群中的follower服务器（F）与leader服务器（L）之间完成初始化同步连接时能容忍的最多心跳数（tickTime的数量）。如果zk集群环境数量确实很大，同步数据的时间也会变长，因此这种情况下可以适当调大该参数
• syncLimit：集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）
• 集群节点：
  server.id=host:port:port
  id：通过在各自的dataDir目录创建一个名为myid的文件名为每台机器赋予一个服务器id
  两个端口号：第一个跟随者用来连接到领导者，第二个用来选举领导者

集群的所有节点都可以提供服务，客户端连接时，连接串可以指定多个或者全部集群节点的连接地址。当一个节点不通时，客户端讲自动切换到另一个节点

ZooKeeper集群监控

• 四字监控指令
• JMX

ZooKeeper集群-ZAB协议

• 作为重要的分布式协调服务，如何保证集群数据的一致性？
  
• ZAB协议过程说明（保证有序性）
  
  1.所有事务请求转发给leader
  2.Leader分配全局单调递增事务id(Zxid)，广播事务提议
  3.Follower处理提议，做出反馈
  4.Leader收到过半反馈，广播Commit
  5.Leader做出响应
  ZAB协议重要特性：有序性

ZAB协议-崩溃恢复

• Leader服务器出现崩溃，或者说由于网络原因导致Leader服务失去了与过半Follower的联系，那就会进入崩溃恢复模式
• ZAB协议规定如果一个事务Proposal在一台机器上被处理成功，那么应该在所有机器上都被处理功能，哪怕机器出现故障奔溃
• ZAB协议确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交
• ZAB协议确保丢弃那些只在Leader服务器上被提出的事务

ZAB协议需要设计的选举算法应该满足

• 确保提交已经被Leader提交的事务Proposal，同时丢弃已经被掉过的事务Proposal
• 如果让Leader选举算法能够确保新选举出来的Leader服务器拥有集群中所有机器最高ZXID的事务Proposal，那么就可以保证这个新选举出来的Leader一定具有所有已经提交的提案
• 如果让具有编码事务Proposal的机器成为Leader，就可以省去Leader服务器检查Proposal的提交和丢弃工作这一步操作

ZAB协议-数据同步

• Leader选举出来后，需要完成Followers与Leader的数据同步。当过半的Followers完成同步，则可以开始提供服务。
• Leader服务器会为每一个Follower服务器准备一个队列，并将那些没有被Follower服务器同步的事务以Proposal消息的形式逐步发送给Follower服务器，并在每一个Proposal消息后面紧接着在发送一个Commit消息，以表示该事务已经被提交
• Follower服务器将所有其尚未同步的事务Proposal都中Leader服务器上同步过来并成功应用到本地数据库中后，Leader服务就可以将该Follwer服务器加入到真正可以用的可用Follower列表中，并开始之后的其他流程

ZAB协议-丢弃事务Proposal处理
在ZAB协议的事务编号ZXID设计中，ZXID是一个64位的数字

• 低32位是一个简单的单调递增的计数器，针对客户端的每一个请求事务，Leader服务器在产生一个新的事务Proposal的时候，都会对该计数器进行加1操作
• 高32位代表了Leader周期纪元的编号，每当选举产生一个新的Leader服务器，就会从这个Leader服务器上去除其本地日志中最大事务的ZXID，并从该ZXID中解析对应的纪元值，然后对其进行加1操作，之后就会以此编号作为新的纪元，并将低32位置0来开始生成新的ZXID
• 基于这样子的策略，当一个包含了上一个Leader周期中尚未提交过的事务Proposal的服务器启动加入到集群中，发现此时集群中已经存在Leader，将自身以Follower角色连接上Leader服务之后，Leader服务器会根据自己服务器上最后被提交的Proposal来和Follower服务器的Proposal进行对比，发现Follower服务器中有上一个leader周期的事务Proposal时，leader会要求Follower进行一个回退操作

ZooKeeper集群Leader选举
对选举算法要求：

• 选出的Leader节点要持有最高的zxid
• 过半数节点同意

内置实现的选举算法：

• LeaderElection
• FastLeaderElection（默认）
• AuthFastLeaderElection

Leader选举机制概念

• 服务器id：myid
• 事务id，服务器中存放的最大Zxid
• 逻辑时钟，发起的投票论数计数
• 选举状态：
  Looking：竞选状态
  Following：随从状态，同步leader状态，参与投票
  Observing：观察状态，同步leader状态，不参与投票
  Leading：领导者状态

Leader选举算法

• 每一个服务器实例均发起选举自己为领导者的投票（自己投自己）
• 其他服务器实列收到投票邀请时，比较发起者的数据事务ID是否比自己最新的事务ID大，大则投它一票，小则不投票给他，相等则比较发起者的服务器ID，大则投票给它
• 发起者收到大家的投票反馈后，看投票数（含自己的）是否大于集群的半数，大于则胜出，担任领导者；未超过半数则领导者未选出，则再次发起投票
• 胜出条件：投票赞成数大于半数则胜出的逻辑