1. ZooKeeper Internals
刘绍辉
September 21, 2016

2. 提纲
1. 数据模型
2. 架构
3. 运维和监控
4. 问题
2 / 22

3. Overview
A Distributed Coordination Service for Distributed Apps
3 / 22

4. 数据模型
数据模型：树形命名空间,
每个节点是Znode, 节点上
可以设置Watcher
ZNode：
类型：持久/临时节点
数据：value/version/zxid
Acl/Quota/时间
子节点个数/Owner等等
Watcher
None(本地事件):
SyncConnected
Disconnected/Expired/...
NodeCreated
NodeDeleted
NodeDataChanged
NodeChildrenChanged
4 / 22

5. Client API
Read
getData 获取数据
getACL 获取ACL
getChildren 获取子节点
exists 判断节点是否存在
sync 同步leader数据
Write
create 创建节点
delete 删除 checkAndDelete
setData 修改 checkAndSet
setAcl 设置ACL
multi 原子操作
5 / 22

6. 客户端模型
Socket建立之后，客户端发
送ConnectRequest，建
立session，协商session超时时
间
客户端把用户请求，封装
成Packet，发送给服务端，如
果1/3 session timeout 没有请
求，则发送一个Ping
当前连接上异常或者超过2/3
session timeout 不可用，尝试
其他IP, 尝试
续session和Watcher
客户端重新连上服务，返
回Session过期之后，客户端抛
出一个Session Expired事件
6 / 22

7. 使用场景
配置管理服务
NameService eg： thrift service
选主服务 hbase/hdfs
消息队列/事件通知 storm/hbase
文件系统: 存储meta数据 eg: kafka/yarn
7 / 22

8. 提纲
1. 数据模型
2. 架构
3. 运维和监控
4. 问题
8 / 22

9. 整体架构
一致性协议：ZAB(原子广
播协议)
QuorumPeer角色
Leader/Follower/Observer
QuorumPeer状态
LOOKING
FOLLOWING
LEADING
OBSERVING
zxid = Epoch + 自增ID
9 / 22

10. ZAB：原子广播协议
三个阶段
Leader选举
数据同步
提案广播
10 / 22

11. ZAB: 选主
FastLeaderElection： 类Gossip协议：
每次选主重新产生新的EpochID
notification(leaderID, leaderZxid)
1. 默认leaderID=myid, 向所有peer发送notification
2. 如果收到notification中leaderZxid > 当前leaderZxid， 则修
改leaderID, 继续发notification
3. 收到多数派确认自己是leader，退出选举
11 / 22

12. ZAB: 同步
1. TRUNC: peerLastZxid > LeaderMaxCommittedLog 删除多余
的提案
2. DIFF: LeaderMinCommittedLog < peerLastZxid <
LeaderMaxCommittedLog 补充穷少的提案
3. SNAP: peerLastZxid < LeaderMinCommittedLog 更
新snapshot
12 / 22

13. ZAB：广播
两阶段提交： Proposal/ACK， 受到超过半数确认则Commit
Pipeline，提案顺序执行，严格保证log顺序
13 / 22

14. Zookeeper Server
读操作: Leader/Follower: FinalRequestProcessor 实际读
取ZKDataBase
写操作: Leader/Follower: SyncRequestProcessor 请求写入日
志 FinalRequestProcessor ZKDataBase处理写请求
14 / 22

15. Local Storage
acceptedEpoch: 当前看到Epoch
currentEpoch: 当前参与Epoch
Log： log.$zxid
每zookeeper.snapCount(默认1w) *
3/4 个请求，产生一个新的log，
并尝试dump snapshot 文件初始大
小preAllocSize(默认64M) 减少写
入meta更新
Snapshot：snapshot.$zxid, 保留最
新autopurgeSnapRetainCount个
15 / 22

16. 提纲
1. 数据模型
2. 架构
3. 运维和监控
4. 问题
16 / 22

17. 开发
代码 git@git.n.xiaomi.com:infra/zookeeper.git
主版本: 3.4.5-mdh1.2
性能测试： zookeeper-benchmark
文档：http://infra.d.xiaomi.net/zookeeper
17 / 22

18. 部署
部署
一般5个节点，最少分布在三个机架/Zone
部署工具： minos https://github.com/XiaoMi/minos
配置文件：infra/deployment/xiaomi-config/conf/zookeeper
主要配置
dataDir/dataLogDir snapshot/log日志目录
maxClientCnxns 单IP最大连接数限制
min/maxSessionTimeout 最大/最小 session 超时时间
autopurgeSnapRetainCount/autopurgePurgeInterval
snapshot保留个数和清理周期
jute.maxbuffer(jvm参数 默认1M) request最大大小
18 / 22

19. 监控
4字命令: ruok/mntr/cons/wchs/...
owl-collector: 通过四字命令收集Zookeeper相关metrics, 推送
到falcon
可用性探测：zk-canary不断在/zk-canary上创建和删除节点.
Falcon搜索zookeeper-canary
19 / 22

20. 提纲
1. 数据模型
2. 架构
3. 运维和监控
4. 问题
20 / 22

21. 问题
遇到的问题
1. 存储数据量过大，Failover时间过长
2. 写操作过多，Zxid耗尽问题，发生Failover
3. multi操作数据量过大，导致失败
潜在的问题
1. 一次性Watcher丢数据问题
2. Session Expired行为
3. 弱一致性
4. 跨机房部署
5. 多租户和隔离：只有数据量的quota， 没有QPS， SLA等
21 / 22

22. 参考
ZooKeeper Administrator’s Guide
https://zookeeper.apache.org/doc/current/zookeeperAdmin.html
<<ZooKeeper: Distributed Process Coordination>>
<<ZooKeeper’s Atomic Broadcast Protocol: Theory and
Practice>>
<<从Paxos到Zookeeper>> 倪超
22 / 22