Overview_java

版本特征

• 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  

more http://zookeeper.apache.org/releases.html#news

设计目标

• 简单设计模型。

  • 共享、树形结构的名字空间

    

• 可以构建集群

  • (扩容、缩容 支持不好 需要全部重启 ,或一台台重启rolling update 、3.5版本解决了该问题)

    

• 顺序访问

• 高性能

  • 内存,直接服务所有非事务请求,适合读多写少( it performs best where reads are more common than writes, at ratios of around 10:1)

    

基本概念

集群角色

​ 传统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服务器数据状态的事务请求的处理方式:

1. 所有事务请求由一个全局唯一服务器处理 Leader
2. Leader 负责将客户端事务请求转换成一个事务Proposal .分发给集群中的所有Follower
3. 等待所有服务器反馈,一旦超过半数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是一种用于分布式应用程序的分布式开源协调服务。它公开了一组简单的原语，分布式应用程序可以构建这些原语，以实现更高级别的服务，以实现同步，配置维护以及组和命名。

• 提供比较底层的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