ZooKeeper与Paxos

ZooKeeper 没有采用Paxos 协议，采用的是ZAB（ZooKeeper Atomic Broadcast）

• 是一个典型的分布式数据一致性解决方案
• 分布式应用能够基于他实现：
  • 数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁、分布式队列
• 保证以下分布式一致性特性：
  • 顺序一致性
  • 原子性
    • 不会出现部分机器应用，部分没有
  • 单一视图
    • 不管看到的是ZooKeeper哪一个服务器，服务端数据都是一致的
  • 可靠性
  • 实时性
    • 仅仅保证必定时间内，客户端必定能从服务器端读到最新数据
• 高可用、高性能、严格数据顺序管控能力
• 四大设计目标：
  • 简单的数据模型（树结构，全量存储在内存中）
  • 能够构建集群
    • 只要集群中存在一半以上的机器，就能提供正常服务
  • 顺序访问
    • 客户端每一个更新请求都会配以惟一递增编号
  • 高性能
    • 全量数据存储在内存中，尤为适合以读为主的场景

ZooKeeper基本概念

• 集群角色
  • ZooKeeper没有沿用 Master/slave 模式，
  • 而是采用Leader、Follower、Observer
    • 选举产生Leader，Leader 提供读写服务
    • Follower、Observer 提供读，Observer不参与选举
• 会话
  • 客户端与服务器端创建的是TCP 长链接
  • 心跳检测保持有效的会话
  • 断开链接后，sessionTimeout 以内，再链接上任意服务器，会话依然有效
• 数据节点（Znode）
  • 节点指机器节点
  • Znode能够分为持久节点、临时节点
• 版本
  • 数据节点存储State数据结构，
  • 包括version（当前版本）、cversion（当前子节点版本）、cversion（ACL版本）
• Watcher（事件监听器）
  • 容许客户端在指定节点上注册特定Watcher，特定事件触发，服务器会通知感兴趣的客户端
• ACL （权限控制管理）
  • 相似Unix的权限控制

ZAB协议：

• 崩溃恢复模式
• 消息广播模式
• 为ZooKeeper专门设计的支持崩溃恢复原子广播协议
• 只容许惟一的一个Leader 进行事务处理
• 已经有过半数的Follower 服务器与Leader 服务器状态保持一致，进入消息广播模式模式
• 消息广播模式模式下，新加入节点会自动进入崩溃恢复模式，与Leader 同步数据后，进入消息广播模式
• 进入崩溃模式后，只要集群中过半的服务器彼此通讯正常就能够选举新的Leader 进入广播模式
  • 也就是说3台机器，1个Leader，两个Follower ，其中一个Follower 崩溃了，依然能够正常工做（Leader本身支持本身）

消息广播

• 原子广播协议
• 基于FIFO特性的TCP协议
• Leader 收到半数Proposal 就会提交
• Follower要么回应，要么抛弃Leader
• 每一个Proposal都有全局惟一递增id

崩溃恢复

基本特性

• 新Leader 选举，根据全局ZXID（64位的数字）最大的来作新Leader
• ZXID（64位的数字）
  • 低32位每次自增1
  • 高32位表明Leader周期epoch编号；
  • 若是出现新Leader，根据最大ZXID解析出epoch编号再加1，低32位从0开始生成新的ZXID

数据同步

深刻ZAB协议

事务

• 根据事务标识z=<e,c>
  • e表明主进程周期epoch（e）
    • 主进程周期 也叫主进程序列号
  • c表明主进程周期内的事务计数
• 根据e，c大小判断事务前后
• 提交排序靠后的事务以前的事务一定已经提交

消息广播和崩溃恢复，进一步细分为：

• 发现阶段
  • 选举出最大的ZXID做为新Leader
  • 启动的时候都是looking状态
• 同步阶段、
• 广播阶段