注意：所有文章除特别说明外，转载请注明出处.
ZooKeeper
[TOC]
概念
zookeeper是开源的分布式协调服务，其设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单的接口提供给用户使用。
原语，操作系统或计算机网络用语范畴。是由若干条指令组成的，用于完成一定功能的一个过程。具有不可分割性，即原语的执行必须是连续的，在执行过程中不允许被中断。
ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
Zookeeper 一个最常用的使用场景就是 ==用于担任服务生产者和服务消费者的注册中心(提供发布订阅服务)==。
服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。如下图所示，在 Dubbo架构中 Zookeeper 就担任了注册中心这一角色。
ZooKeeper 功能
在项目中，主要使用ZooKeeper作为Dubbo的注册中心（Dubbo官方推荐使用ZooKeeper注册中心）。
==ZooKeeper 的典型应用场景 发布订阅功能的作用==
我们知道ZK的典型应用场景之一就是“发布订阅服务”。利用“发布订阅服务”实现两种常见的功能：
1. 作为配置中心
2. 作为Dubbo的注册中心，也就是发布订阅中心
1. 作为配置中心
很多时候我们相同的程序可能部署在多台机器上提升性能，不同的程序也可能有相同的配置文件。如果我们每次修改配置文件，都要一个一个机器修改的话，那么必定非常麻烦。
我们可以考虑把应用配置放到 ZooKeeper 上去，也就是保存在 Zookeeper 的某个目录节点中，我们对指定的节点设置一个 Watcher 监听 。
这样做的好处就是：一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后可以从 Zookeeper 获取新的配置信息应用到系统中就好。
ZooKeeper 中利用 Watcher 机制实现分布式通知功能，Zookeeper 允许 ==客户端向服务端注册一个Watcher监听，当服务端的一些指定事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知==来实现分布式的通知功能。
2. 作为 Dubbo 的注册中心
Zookeeper 一个非常==常用的使用场景就是用于担任服务生产者和服务消费者的注册中心提供发布订阅服务==。
服务生产者将自己提供的服务注册到 Zookeeper 的一个或一系列节点上去，服务的消费者在进行服务调用的时候先到 Zookeeper 中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。
ZooKeeper 工作机制
ZooKeeper从设计模式角度理解是一个基于观察者模式的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦数据的状态发生变化，ZooKeeper将负责通知已经在ZooKeeper上注册的那些观察者做出相应的反应。
1. 服务端启动时去zookeeper集群注册信息（创建都是临时节点）
2. 客户端获取当前在线服务器列表，并且注册监听
3. 服务器节点下线
4. 集群通知客户端服务器节点上下线事件通知
5. 重新获取服务器列表，并注册监听
提示：ZooKeeper等于文件系统和通知机制。
ZooKeeper 特点
- 一个领导者，多个跟随者组成的集群
- 集群中只要有半数以上的节点存活，ZooKeeper就能够正常服务
- 全局数据一致，每个Server保存一份相同的数据副本，客户端无论连接到哪个Server，数据都是一致的
- 更新请求顺序进行，来自同一个客户端的更新请求按其发送顺序依次执行
- 数据更新原子性，一个数据更新要么成功，要么失败
- 实时性，在一定时间范围之内，客户端能读到最新数据
顺序一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
- 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
- 单一系统映像：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
- 可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。
ZooKeeper 数据结构
ZooKeeper数据模型的结构与Unix文件系统类似，整体可以看做是一棵树，每个节点称作ZNode。每个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。
zookeeper 数据模型和常见命令
ZNode（数据节点）是 ZooKeeper 中数据的最小单元，每个ZNode上都可以保存数据，同时还是可以有子节点（这就像树结构一样）。
节点路径标识方式和Unix文件系统路径非常相似，都是由一系列使用斜杠”/“进行分割的路径表示，开发人员可以向这个节点中写入数据，也可以在节点下面创建子节点。
在ZooKeeper数据模型中，不得不提的概念就是 ==事务ID== 。事务的ACID四大特性等。
在Zookeeper中，事务是指能够改变 ZooKeeper 服务器状态的操作，我们也称之为事务操作或更新操作，一般包括数据节点创建与删除、数据节点内容更新和客户端会话创建与失效等操作
==对于每一个事务请求，ZooKeeper 都会为其分配一个全局唯一的事务ID，用 ZXID 来表示，通常是一个64位的数字。== 每一个ZXID对应一次更新操作，==从这些 ZXID 中可以间接地识别出Zookeeper处理这些更新操作请求的全局顺序==。
ZNode（数据节点）的结构
每个ZNode节点都由两部分组成：
1. stat：状态信息
2. data：数据内容
1. stat类（状态信息的各个字段说明）
应用场景
提供的服务包括，统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。
统一命名服务
在分布式环境中，经常需要对应用/服务进行统一命名，便于识别。
软负载均衡
在ZooKeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求。
ZooKeeper 概念总结
==ZooKeeper 本身就是一个分布式程序（只要半数以上节点存活，ZooKeeper 就能正常服务）。==
==为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么 ZooKeeper 本身仍然是可用的。==
==ZooKeeper 将数据保存在内存中，这也就保证了 高吞吐量和低延迟（但是内存限制了能够存储的容量不太大，此限制也是保持znode中存储的数据量较小的进一步原因）。==
==ZooKeeper 是高性能的。 在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）==
==ZooKeeper有临时节点的概念。 当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在。而当会话终结时，瞬时节点被删除。持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上。==
ZooKeeper 底层其实只提供了两个功能：①管理（存储、读取）用户程序提交的数据；②为用户程序提供数据节点监听服务。
2. 会话（Session）
Session 指的是 ZooKeeper 服务器与客户端会话，在 在 ZooKeeper 中，一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。
==通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。 =
==Session的 sessionTimeout值 用来设置一个客户端会话的超时时间。== 当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，==只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。==
==在为客户端创建会话之前，服务端首先会为每个客户端都分配一个sessionID。由于 sessionID 是 Zookeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的，因此，无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一。==
3. ZNode
==在说分布式时候，我们通常说的节点是指组成集群的每一台机器。== 然在ZooKeeper中，==节点分为两类，1. 同样是构成集群的机器，机器节点。2. 数据模型的数据单元，数据节点ZNode。==
Zookeeper 将所有数据存储在内存中，数据模型是一棵树（Znode Tree)，由斜杠（/）的进行分割的路径，就是一个Znode，例如/foo/path1。每个上都会保存自己的数据内容，同时还会保存一系列属性信息。
在Zookeeper中，==node可以分为 持久节点 和 临时节点 两类==。所谓==持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上==。而==临时节点就不一样了，它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除==。
另外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，Zookeeper会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。
4. 版本
在之前我们知道，ZooKeeper的每个ZNode上都会存储数据，对应每个ZNode，ZooKeeper都会为其维护一个叫做Stat的数据结构，==Stat中记录了这个ZNode的三个数据版本，分别是 version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。==
5. Watcher
==Watcher（事件监听器），是ZooKeeper的重要特性。Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper实现分布式协调服务的重要特性。==
6. ACL
Zookeeper采用ACL（AccessControlLists）策略来进行权限控制，类似于 UNIX 文件系统的权限控制。Zookeeper 定义了如下5种权限。
1. CREATE 创建子节点权限
2. READ 获取节点数据和子节点列表的权限
3. WRITE 更新节点数据的权限
4. DELETE 删除子节点的权限
5. ADMIN 设置节点ACL的权限
注意：CREATE 和 DELETE 这两种权限都是针对子节点的权限控制。
ZooKeeper 设计目标
1. 简单的数据模型
ZooKeeper 允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。
名称空间由 ZooKeeper 中的数据寄存器组成 - 称为znode，这些类似于文件和目录。
与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。
2. 可构建集群
为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么zookeeper本身仍然是可用的。
客户端在使用 ZooKeeper 时，需要知道集群机器列表，通过与集群中的某一台机器建立 TCP 连接来使用服务，客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上。
提示：集群之间通过 ==Zab协议== 来保持数据的一致性。
3. 顺序访问
==对于来自客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，应用程序可以使用ZooKeeper这个特性来实现更高层次的同步原语。这个编号也叫做时间戳（zxid）。==
4. 高性能
ZooKeeper 是高性能的。 在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）
ZooKeeper 集群角色
==最典型的集群模式：Master/Slave（主备模式）==，在这种模式种，通常Master服务器作为主服务器提供写服务，其它的Slave服务器从主服务器中通过异步复制的方式获取Master服务器最新的数据提供读服务。
==在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色。==
==ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器，Leader 既可以为客户端提供写服务又能提供读服务==。
==除了 Leader 外，Follower 和 Observer 都只能提供读服务。== Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。
==当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。这个过程大致如下：==
1. Leader election（选举阶段）：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。
2. Discovery（发现阶段）：在这个阶段，followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。
3. Synchronization（同步阶段）:同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后准 leader 才会成为真正的 leader。
4. Broadcast（广播阶段）：到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。
ZooKeeper内部原理
选举机制
- 半数机制，集群中半数以上机器存活，集群可用。所以ZooKeeper适合安装奇数台服务器。
- ZooKeeper虽然在配置文件中并没有指定Master和Slave，但是ZooKeeper工作时，是由一个节点为Leader，其它为Follower，Leader是通过内部的选举机制临时产生的。
节点类型
- 持久型，客户端与服务器断开连接后，创建的节点不删除
- 短暂，客户端与服务器断开连接后，创建的节点自己删除
- 持久化目录节点，在客户端与ZooKeeper断开连接之后，该节点依旧存在。
- 持久化顺序编号目录节点，客户端与ZooKeeper断开连接后，该节点依旧存在，只是ZooKeeper给该节点名称进行顺序编号。
说明：创建ZNode时设置顺序标识，ZNode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。
注意：在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序。
- 临时目录节点，客户端与ZooKeeper断开连接后，该节点被删除
- 临时顺序编号目录节点，客户端与ZooKeeper断开连接后，该节点被删除，只是ZooKeeper给该节点名称进行顺序编号。
Zab协议 | Paxos算法
Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但 ZooKeeper 并没有完全采用 Paxos算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。
1. ZAB 协议
==ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。==
2. ZAB 协议两种基本的模式（崩溃恢复和消息广播）
在整个服务框架启动过程中或是当 Leader 服务器出现故障情况时，ZAB协议就会进入恢复模式并选举产生新的Leader服务器。
在选举产生新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成 状态同步 之后，ZAB协议就会退出恢复模式。
所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。
==当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进人消息广播模式。==
当一台服务器启动后加入集群，如果已经存在Leader服务器进行消息广播，那么新加入服务器会自觉进入数据恢复模式，找到Leader服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。
ZooKeeper设计成只允许唯一的一个Leader服务器来进行事务请求的处理。
Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议。而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。
ZooKeeper安装
本地模式安装部署
配置参数解读
ZooKeeper实战
分布式安装部署
测试 ZooKeeper 中的常见操作
1. 连接 ZooKeeper 服务
./zkCli.sh -server 127.0.0.1:2181
2. 常看常用命令（help命令）
help
3. 其它命令
1. ls
2. stat 查看节点状态
3. ls2 查看节点信息与状态
4. delete 删除节点，如果需要删除某一个节点，那么此节点必须没子节点才行
5. set 更新节点数据内容
6. get 获取指定节点的数据内容和节点的状态
