Zookeeper集群

集群介绍

• 集群搭建
  配置

1. initLimit
   主从完成初始化最大容忍时间
2. syncLimit
   主从请求应答最大容忍多少心调
3. 集群节点
   server.id=host:port:port
   服务器.id=主机:和leader通信：选举通道
   id = 1-255

• 监控
  命令
  • c-nf 配置
  • c-ns 会话的详情
  • crst 重置会话统计
  • dump 未经处理会话和临时节点
  • envi 服务环境的详情
  • reqs 未经处理的请求
  • run-k 测试是否是正常状态 返回 im-k
  • srst 重置统计信息
  • srvr 列出详细信息
  • stat 列出信息和客户端信息
  • wchs wchc wchp
  • mntr 集群健康状态

Paxos算法

• 概念
  1. 基于消息传递 高度容错特定 一致性算法
  2. CAP
     • 一致性 Consistency
     • 可用性 Availability
     • 分区容错性 Paritition
  3. 一致性协议
     • 2PC
       提交事务请求
       执行事务提交
     • 3PC
       有点：减少了阻塞
• 阶段

1. 提议的发起者 发送一个带有编号n的提案预请求
2. 如果编号大于前面已经响应过的预请求编号 接受者承诺不接受比这个编号n小的提案预请求
3. 提议者 接受 大多数接受者对于n预请求的响应 接受者每个发送者发送接受请求 接受请求的的v选择接受到的最高编号对应的值 没有的话自己当前提案的值
4. 如果接受者受到一个编号为n的提案请求 就接受该提案 如果它已经准备对大于n编号的预请求作出响应 则不接受提案

• 阶段角色
  • Proposer（P）
  提议者
  提议 达成一致value
  • Acceptor（A）
  接受者
  投票 决定value
  • Learner（L）
  学习者
  只接受结果

• 流程
  1. P的特性
  P发送2类消息 prepare准备和accept
  P的请求有2部分 (n,v) n序号 v提议值

    2. 过程
    	0. 假设
    		 	PA PB AC AD AE
    		 	CD 先接受到 A  E先接受到B
     	1. prepare a(n=2,v=5)
     		 C D 会响应A (没有前置请求)
       		 E不会响应A
    		 A接受到大部分请求都是 n=2 v=5
        2. prepare b(n=4,v=8)
         	E会响应 B （没有前置请求）
    	    C D会响应 B 返回(n=2 v=5)
    	    B接受到(n=2,v=5) 找到最大的 n=4替换 发送(n=4,v=5) 
        3. accept C D 
     		A的请求 n< 4 则 忽略请求
    	    B发送请求给C D 编号大于现在的所以接受B的
        4. accept E
    		A不会确认 E 没有响应他
    		B发送请求给E
           编号等于当前的 所以接受B的
        5. 通知Learner
       
    	PB会通知所有的learn 包含accepter
    	•	问题
    	   PA PB 里面可能会不断发出提案 导致死循环
    	   优化：**选择除一个主的Proposer**  目前zk只有在选主的时候会用到ZAB算法
  

ZAB协议（Zookeeper Atomic Broadcast）

1. 数据一致性协议
   1. 过程
      • 所有的事务请求转给leader
      • leader分配全局单调递增的zxid 广播事务提议
      • Follower接受 做出反馈
      • Leader接受到过半数的 广播的Commit
      • Leader做出响应
   2. 崩溃恢复
      • 协议规定
      • leader挂了会保证此leader的所有提议在所有机器上处理成功
      • Zxid最大的leader
      • 保证leader上的所有已经提交的最终会在所有的机器同步
      • 确保丢弃只在leader上被提出的事务
   3. 数据同步
      • leader会保存一个同步的Follower的队列 发送一个提案 会紧跟一个Commit
      • Follower同步完成才会被leader加入到真的Follower列表中
2. ZXID设计
   • 64位的数字
   • 低32位是简单的递增计数器
   • 针对每个客户端的事务请求
   • 高32位是leader的周期纪元编号
   • 每次生成新的leader把高位的加1 低位的置0
   • 如果leader发现follower连接上 会进行对比 如果发现follower有上一个leader周期的 leader会要求follower 回退到有多数同意的最新的事务
3. leader选举
   1. 要求
      • leader持有最高的zxid
      • 多半数节点同意
   2. 算法
      • LeaderElection
      • FastLeaderElection 默认
      • AuthLeaderElection
   3. 选举状态
      • LOOKING 竞选状态
      • FOLLOWING 从状态参与投票
      • OBSERVING 观察者状态 不参与投票
      • LEADING 领导状态
   4. leader选择
      先比事务ID 再比服务器id myid

经典的案例

1. 读和写都是依赖大多数
   5个节点 有3个包含leader可读可写 2个可以连接不可以读写
2. 数据发布和订阅
3. 命名服务
4. Master选举
5. 集群管理
6. 分布式队列
7. 分布式锁