ZooKeeper浅析

一、ZooKeeper简介&特性
ZooKeeper是一个开源分布式协调服务系统，独特的Leader-Follower的集群结构，很好地解决了分布式单点问题。目前主要应用场景
（1）统一命名服务
（2）配置管理
（3）分布式锁服务
（4）集群管理
1. 一些基本概念
（1）角色
a. Leader
b. Follower
c. Observer
（2）数据单元：Znode(Path)
统一命名空间中的数据单元，形象点来理解的话，就是文件路径树中的一个个节点，相当于一个文件或者一个目录
（3）监听器：Watcher
2. 数据模型和层级命名空间
ZooKeeper提供的命名空间极像一个标准的文件系统，一个名字就是一个以“/”分隔的路径元素的序列，ZooKeeper命名空间的每个节点（即Znode）通过路径来标识

（1）树形结构
其中一个节点，即为一个Znode


（2）节点与临时节点
     与标准文件系统不同的是，ZooKeeper命名空间中的所有节点都可以有数据和子节点，这就好比文件系统中的一个文件可以同时是一个目录。ZooKeeper被设计用来存储管理服务的数据，如：状态信息、配置、位置信息等，所以每个节点存储的数据通常很小，几字节到几K字节不等。我们使用Znode这个术语来表示ZooKeeper中的数据节点。
     Znode上维持一个stat结构，它包含数据变化的版本号、ACL变化和时间戳，以允许cache校验和协调化的更新。每当Znode的数据变化时，版本号便递增。一个客户端收到数据时，也会同时收到数据的版本号。
      保存在每个Znode中的数据都是自动读写的，读操作获取Znode的所有数据，写操作替换掉Znode的所有数据。每个节点都有一个访问控制列表（ACL）来限制谁能做哪些操作。
     有一种特殊的Znode类型是临时节点，这些Znode只存在于创建Znode的会话中，当会话结束，这些节点也就被删除了。
（3）Znode的类型
a. 持久化节点（persistent）
b. 临时节点（ephemeral)
c. 时序节点（sequential）
（4）多维度（对比configserver和diamond）

3. ZooKeeper的设计目标
（1）简单
ZooKeeper允许分布式进行之间通过一个共享的层级命名空间来相互协作，这个命名空间以类似于文件系统的方式组织起来。命名空间中的数据单元被称为Znode，它相当于文件或者目录。与典型的文件系统不同的是，文件系统用于持久化存储，而ZooKeeper的数据则是保持在内存中的，这意味着ZooKeeper能达到很高的吞吐量和低延迟
（2）高性能和高可用
ZooKeeper的实现十分注重高性能、高可用和严格的顺序访问。高性能使得ZooKeeper能用于大规模分布式系统，高可用性能避免单点故障，严格的顺序化意味着复杂的同步操作可以在客户端实现
（3）集群化
ZooKeeper本身也是有集群化的，如下图


客户端与单个服务器相连，它们之间维持一个TCP连接，在其上发送请求，获得响应，获得监控事件和发送心跳检测。如果到服务端的TCP连接断了，客户端会连接另一个服务端。组成ZooKeeper服务的每个服务节点都知道其他服务节点的存在，它们各自维护一个服务端状态的内存镜像，连同事务日志和快照保存在持久化存储中，只要大部分服务端节点可用（通常是过半即可），ZooKeeper就可用
（4）顺序化
ZooKeeper为每个更新操作都标记一个号码（即数据版本号）以反映事务的顺序，后来的操作使用这个顺序来实现一些高度的抽象概念，比如同步原语
（5）快速
这个特性在以读操作为主的工作中尤为明显。ZooKeeper应用程序运行于数以千计的机器中，当读操作与写操作的比例为10:1时，ZooKeeper能获得最佳性能

4. 一些特性
（1）条件化更新和监控（watcher）
ZooKeeper支持监控的机制。客户端可以在指定Znode上设置一个watcher。这个watcher会在Znode发生变化时触发和移除。当watcher被触发时，客户端会收到到一条说明znode发生变化的通知消息，进而可以触发自己预先定义的逻辑，实现Znode状态的监控。如果客户端和服务端的连接断了，客户端会收到一个本地的通知。
（2）写请求严格顺序性
所有写请求都会交给leader节点来处理，包括create()、delete()、setData()等等
（3）视图唯一性
所有服务节点上所呈现给客户端的是一棵结构和数据都保持一致的树
（4）ZooKeeper所能保证的一些特性
a. 顺序一致性：来自客户端的更新操作将以它们发送的顺序来执行
b. 原子性：更新操作只有成功和失败两种结果，没有局部化结果
c. 单个系统镜像：不管客户端连接的服务节点是哪个，所有客户端看到的服务都会是一致的。当然，这里的一致是最终一致性，实际上是存在一定的延迟的，最高延迟时间是500ms
d. 可靠性：一旦更新操作被执行，它将被持久化保存直到被下次更新操作所覆盖
e. 及时性：客户端所看到的系统在一个时间范围内是最新的

5. 性能
测试条件：CPU: dual 2Ghz DISK: sata15K RPM drives

根据性能测试，可得出如下结论
（1）ZooKeeper适用于以读为主的应用场景
（2）集群规模增大，写性能降低
（3）一个集群包含5个服务节点时，性能最为理想


6. 简单API
ZooKeeper的一个设计目标是：易于编程。所以，它只支持如下这些简单的操作
（1）create：在命名空间的某个位置创建一个节点
（2）delete：删除一个节点
（3）exists：测试某位置的节点是否存在
（4）get data：从一个指定节点读取数据
（5）set data：往一个指定节点写数据
（6）get children：获取一个节点的子节点列表
（7）sync：强制同步数据

二、ZooKeeper的实现原理
我们先从较高层次来看下ZooKeeper的实现架构

     其中，集群数据库是存在于内存中的数据库，保存命名空间的所有数据。更新操作会被记录到硬盘中以便恢复数据，写操作会先被持久化到硬盘中，再应用到内存数据库中。
     每个ZooKeeper服务端为一个或多个客户端服务。客户端连接一个服务端来提交请求。读操作请求由每个服务端数据库的本地副本提供服务。能够改变服务状态的请求、写操作请求，按协议处理。
     作为协议的一部分，来自各个客户端的所有写操作请求会导向同一个服务节点，叫做leader。其他服务节点叫做follower，所有follower从leader接收数据同步消息并进行数据同步。
     ZooKeeper使用自定义的原子性消息协议。由于消息传送层是原子性的，所以ZooKeeper能够保证本地副本不会产生分歧当leader收到一个写请求，它会计算出当写操作完成后系统将会是什么状态，接着将之转变为一个事务。

三、ZooKeeper的使用场景
发布&订阅系统(配置管理)
名字服务
分布式通知/协调
分布式锁
Barriers
队列
集群管理

1. 发布&订阅系统（配置管理）
（1）配置集中化管理
（2）Push/Pull
这个场景和Diamond/ConfigServer比没有明显的优势，所以建议使用Diamond/CS/CatServer. （方便/稳定）
2. 名字服务
（1）全局唯一：API: create
（2）DNS
（3）案例（一淘-问天3-DDNS:动态DNS）
提供方便的name ==> (ip,port) 映射管理以及访问
支持快速更新name ==> (ip, port), 秒级别生效
支持服务级别的负载均衡调度
3. 分布式通知/协调

（1）watcher
（2）解耦/异构
（3）案例
a. 案例1：心跳检测
b. 案例2：愚公移山，任务的调度与机器管理
c. 案例3：millau（原forest），监控平台与管理平台，任务触发
d. 案例4：zeus+treasure，通过ZK将两个不同的系统协调起来

4. 分布式锁
（1）唯一性
（2）时序性
（3）读写锁
（4）分布式锁进阶
a. 刚才的问题（域账号密码修改通知问题）的实现方法是否有问题？是否通知了真正需要修改密码的小二？是否找准了订阅者真正关心的问题？
Client处理无用通知。
Server发送无用通知。

b. 问题核心：Watcher注册点
c. 解决方案：
缩小锁粒度
缩小订阅者的订阅范围
（5）案例
a. 终搜：竞争Dump任务的执行权，动态master选丼
b. 一淘DUMP中心：定时脚本执行+手动修复
c. 淘宝SNS：任务执行权
d. 淘宝交易-Honey：任务执行权
e. 聚划算-SNS-JU-TASK

5. 集群管理
（1）master选举
（2）动态调整集群拓扑结构
（3）案例
a. TAE：一旦某个机器A挂了，马上能够通知到一个Manager，然后Manager将A机器上的东西（看作是正常运行的最后状态）迁移到新的机器中。这个场景用Zookeeper可以管理。
b. 精卫：主备切换

6. 负载均衡
（1）案例
a. 消息中间件meta：生产者负载均衡，消费者的负载均衡，meta中的分区和消费都数据紧密联系。