版本特征
25 March, 2010: release 3.3.0 available 添加Observer、四字命令功能、JMX管理
22 Nov, 2011: release 3.4.0 available。3.4 引入Netty 做为NIO框架处理客户端连接 , 废弃两种选举算法
6 August, 2014: release 3.5.0-alpha available 。 ZooKeeper Dynamic Reconfiguration ,3.5.3中默认关闭
最新的版本为 20 May, 2019: release 3.5.5 available
- 1
more http://zookeeper.apache.org/releases.html#news
设计目标
简单设计模型。
共享、树形结构的名字空间
ZooKeeper's Hierarchical Namespace
可以构建集群
(扩容、缩容 支持不好 需要全部重启 ,或一台台重启rolling update 、3.5版本解决了该问题)
ZooKeeper Service
顺序访问
高性能
内存,直接服务所有非事务请求,适合读多写少( it performs best where reads are more common than writes, at ratios of around 10:1)
ZooKeeper Throughput as the Read-Write Ratio Varies
基本概念
集群角色
传统Master/Slave ( redis/es )
引入 Leader 、Follower 和 Observer( 不参与投票、不写事务日志 )角色
会话(Session)
TCP长连接 、Watch、SessionTimeout
数据节点(Znode)
持久节点和临时节点( 与Session有关)、顺序节点
版本(保证分布式数据原子性操作、乐观锁)
Znode会有一个Stat 分别是 version、cversion 、aversion( ACL )
Watcher(客户端线程、客户端WatchManager和服务器)
允许用户在指定节点注册一些Watcher,并且在特定事件触发,服务端会进行通知.但具体的内容还需要客户端自己去拉取.
- 客户端注册Watcher
- 服务端Watcher处理
- ServerCnxn 是客户端和服务端的连接接口( NIOServerCnxn和NettyServerCnxn )
- 客户端回调Watcher
特性
- 一次性( 需要重复注册 )
- 客户端串行执行
- 轻量
通知状态、事件类型、节点路径
ACL( Access Control Lists 类似UNIX文件系统的权限控制 )
- 权限模式( Scheme )
- 授权对象( ID )
- 权限( permission )
CREATE、READ、WRITE、DELETE、ADMIN
应用场景
- 数据发布/订阅
- 分布式协调/通知
- 集群管理
- Master选举
- 分布式锁(羊群效应,Watcher只关注比自己低的)
- 分布式队列
一般用于服务注册中心,如下图的Dubbo 中的Registry ,或者配置推送 ( 配置中心 规模不大的 )
ZAB协议
核心是定义了对于那些会改变ZooKeeper服务器数据状态的事务请求的处理方式:
- 所有事务请求由一个全局唯一服务器处理 Leader
- Leader 负责将客户端事务请求转换成一个事务Proposal .分发给集群中的所有Follower
- 等待所有服务器反馈,一旦超过半数Follower服务器正确反馈 Leader 会再次向所有Follower服务器分发commit
两个过程
奔溃恢复(初始化和选举)
- 基本特征
- 确保那些已经在Leader服务器上提交的事务最终被所有服务器提交
- 确保丢弃那些只在Leader服务器上提出的事务
- 数据同步
- 直接差异化同步
- 先回滚再差异化同步
- 仅回滚同步
- 全量同步 (优先)
ZKDatabase会定时向磁盘dump快照数据,再ZooKeeper服务器启动的时候,会通过磁盘上的事务日志(事务操作时间、客户端会话ID、CXID 客户端操作ID、ZXID、操作类型、节点路径、节点数据内容、节点的ACL信息、是否临时节点和父节点的子节点版本号)和快照数据文件恢复成一个完整的内存数据库
消息广播
事务全局单调递增唯一ID (事务ID :包含epoch 选举周期) 和myid(机器序号唯一id) ,为每个Follower分配一个FIFO队列 ,Follower接收后回写入事务日志,本地磁盘(基于FIFO 特性的TCP协议。保证消息广播过程中消息接收与发送的顺序性)
四个阶段
- 选举
- 根据Vote(zxid,myid). electionEpoch当前选举周期。 state LOOKING
- 发现
- Follower将最后epoch发送给准Leader
- 收到过半Quorum 生成新epoch 给这些过半Follower
- 反馈ACK和历史Proposal集合 , Leader 从中选择事务集合
- 同步
- Leader 将事务集合 发给所有Quorum
- 广播
- 开始接收客户端请求,并进行消息广播流程
节点状态
LOOKING
FOLLOWING
LEADING
ZAB和Paxos区别
- ZAB协议主要用于构建一个高可用的分布式数据主备系统
- Paxos算法用于构建一个分布式的一致性状态机系统
缺陷和不足
官网的介绍中
ZooKeeper is a distributed, open-source coordination service for distributed applications. It exposes a simple set of primitives that distributed applications can build upon to implement higher level services for synchronization, configuration maintenance, and groups and naming.
翻译如下
ZooKeeper是一种用于分布式应用程序的分布式开源协调服务。它公开了一组简单的原语，分布式应用程序可以构建这些原语，以实现更高级别的服务，以实现同步，配置维护以及组和命名。
- 1
- 提供比较底层的API, 具体由使用方实现(这个类似于J.U.C 提供了validate 和 CAS )
- java原生客户端使用繁琐复杂,如Watcher需要反复注册 ,推荐使用Curator
- 数据模型为CP, 所以在可用性方面会有所不足,例如选举期间服务不可用(因为可用性问题,所以客户端不应该强依赖zookeeper ,一般的做法是客户端需要本地缓存)
- zookeeper的选举过程速度很慢，zookeeper的选举流程通常耗时30到120秒，期间zookeeper由于没有master，都是不可用的。(官网中提到 To show the behavior of the system over time as failures are injected we ran a ZooKeeper service made up of 7 machines.In our observations, ZooKeeper takes less than 200ms to elect a new leader.)
- Zookeeper树形文件结构、数据存储在内存, 但 snapshot（即数据量）不建议超过 1G,否则容易出现选主失败，导致整个集群不可用
- Zookeeper不能保证跨session的强一致性
- Scalability很弱，3.5.0之前的版本修改任何配置还得要rolling update；3.5.0之后新增支持动态reconfiguration
- 其他 监控完善、不提供RESTful API、社区活跃度
参考:
官方链接: http://zookeeper.apache.org/doc/r3.5.5/zookeeperOver.html
Zookeeper缺点 :https://www.zhihu.com/question/42931473
从Paxos到Zooke分布式一致性原理与实践
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 951488791@qq.com