ZooKeeper☆

分布式应用程序协调服务

端口

2181/2888 follower和leader交换信息端口/3888重新选举端口

客户端

• maven api
• curator

  特点

  高可靠，但是性能不行，只能应用在一般的并发场景下

  场景

  服务注册发现中心
  数据发布订阅（配置中心）
  负载均衡
  命名服务
  分布式协调/通知
  集群管理，主备切换（临时节点监控宕机）
  分布式锁（临时节点-e）
  分布式队列
  全局唯一的分布式ID（顺序节点-s）
  同步等待队列（临时顺序节点-s）
  master-slave维护和选举
  条件更新 -c（set -s -v 0 /c 1）

每个节点最多存1M数据（不适合用于存储大量数据）

数据结构

KEY-VALUE：树型
class DataTree {ConcurrentHashMap nodes…}
class DataNode {
byte data[];
long acl;
public StatPersisted stat;
private Set children = null;
}
stat中重要字段

• cZxid：Znode创建的事务ID
• ctime：节点创建的时间戳
• mZxid：Znode被修改的事务ID
• pZxid：该子节点列表最后一次修改的事务ID（只有列表更新才变化，数据更新不变化）
• mtime：节点最新一次修改的时间
• cversion：子节点的版本号
• dataVersion：每次set一下+1
• ephemeralOwner：临时节点会有的session id，持久节点是0
• dataLength：数据长度
• numChildren：直接子节点数量

zookeeper与客户端是长连接

监听（watcher）通知机制

命令：ls -w path（增减）；get -w path（数据）；stat -w path（状态数据）；
特性：一次性触发（3.6以上版本有addWatch [-m mode] path改为持久watcher）；客户端顺序回调；轻量级；时效性
性质：发布/订阅（分布式场景下的观察者模式）（推拉结合）
过程：客户端向服务端注册watcher，服务端事件触发watcher，客户端回调watcher得到触发事件情况
种类：Node连接建立事件；NodeCreated节点创建；NodeDeleted节点删除；NodeDataChanged节点数据变化；NodeChildrenChanged子节点列表变化；DataWatchRemoved节点监听被移除；ChildWatchRemoved子节点监听被移除

节点种类

• 持久节点（默认）
• 临时节点（-e）
• 持久顺序节点（-s）
• 临时顺序节点 （-e -s）
• 容器节点（线程扫描，没有子节点自动干掉父节点）（-c）

• TTL节点（带过期时间节点，不能用于临时节点，默认是禁用的）（-t 时间）

  节点特性

• 同一级节点Key名称是唯一的

• 创建节点时，必须带上全路径
• session关闭时，临时节点清除
• 自动创建顺序节点
• watcher机制，临时节点变化

• delete命令只能一层一层删 deleteall可以

  ACL权限

• scheme：授权模式（world,ip,auth,digest）

• id：授权对象

• permissions：cdrwa

  一致性

  写：强一致性；读：基于版本的顺序一致性

  集群架构

• leader 领导者（读写）

• follower 读请求（非事务），直接响应，写转leader
• observer 观察者，读请求，不参与事务和选举->提供读性能，异地容灾

一致性保证：保证全局可线性化、客户端FIFO顺序（版本号）
修改zoo.cfg server.A.B.C.D
在每台主机里的dataDir/myid存储A
检测：zookeeper四字命令（echo xxxx | nc ip port）

选举机制

服务启动时/leader宕机选举

• 服务器ID（myid）：编号越大选举算法中权重越大
• 事务ID（zxid）：值越大数据越新，权重越大
• 逻辑时钟（epoch）

四个阶段

• LOOKING：竞选状态
• FOLLOWING：随从状态，同步leader状态，参与投票
• OBSERVING：观察状态，同步leader状态，不参与投票（顺序：epoch>zxid>myid）

• LEADING：领导者状态

  数据同步

  ZAB来保证数据一致性

  消息广播

  
  leader往follower写：2PC事务提交

  崩溃恢复

  leader崩溃或者网络导致失去了过半Follower通信进入崩溃恢复（脑裂）

• leader提交commit后立即崩溃

• leader刚提出proposal后立即崩溃

策略

• zxid最大的节点作为新的leader
• 新leader将事务日志中尚未提交的消息进行处理

避免偶数节点

过半机制

预提交

• ack
• 2pc

  ZAB协议

zk节点宕机如何处理

如何实现分布式一致性