Zookeeper---概念性认知

一、什么是Zookeeper

Zookeeper是一个，分布式应用程序协调服务。为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

官网：http://zookeeper.apache.org/

源码：https://github.com/apache/zookeeper

二、zookeeper的特性

• 顺序一致性：从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到Zookeeper中去。

• 原子性：整个集群要么都成功应用了某个事务，要么都没有应用。

• 单一视图：无论客户端连接的是哪个 Zookeeper 服务器，其看到的服务端数据模型（有节点的树）都是一致的。

• 可靠性：事务应用成功后，服务端将一直保留事务对服务端的修改状态，直到下一次修改。

• 实时性：Zookeeper 保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

三、zookeeper重要概念

1.Zookeeper 集群：

Zookeeper 是一个由多个 server 组成的集群,一个 leader，多个 follower。（这个不同于我们常见的Master/Slave模式）leader 为客户端服务器提供读写服务，除了leader外其他的机器只能提供读服务。

每个 server 保存一份数据副本全数据一致，分布式读 follower，写由 leader 实施更新请求转发，由 leader 实施更新请求顺序进行，来自同一个 client 的更新请求按其发送顺序依次执行数据更新原子性，一次数据更新要么成功，要么失败。全局唯一数据视图，client 无论连接到哪个 server，数据视图都是一致的实时性，在一定事件范围内，client 能读到最新数据。

1.1集群角色

Leader：是整个 Zookeeper 集群工作机制中的核心 。Leader 作为整个 ZooKeeper 集群的主节点，负责响应所有对 ZooKeeper 状态变更的请求（写请求）。
主要工作：
事务请求的唯一调度和处理，保障集群处理事务的顺序性。
集群内各服务器的调度者。

Leader 选举是 Zookeeper 最重要的技术之一，也是保障分布式数据一致性的关键所在。我们以三台机器为例，在服务器集群初始化阶段，当有一台服务器Server1启动时候是无法完成选举的，当第二台机器 Server2 启动后两台机器能互相通信，每台机器都试图找到一个leader，于是便进入了 leader 选举流程：

1.每个 server 发出一个投票

投票的最基本元素是（SID-服务器id,ZXID-事物id）

2.接受来自各个服务器的投票

3.处理投票

优先检查 ZXID(数据越新ZXID越大),ZXID比较大的作为leader，ZXID一样的情况下比较SID

4.统计投票

统计有个过半的概念，大于集群机器数量的一半，即大于或等于（n/2+1）,我们这里的由三台，大于等于2即为达到“过半”的要求。
这里也有引申到为什么 Zookeeper 集群推荐是单数。

5.改变服务器状态

一旦确定了 leader，服务器就会更改自己的状态，且一半不会再发生变化，比如新机器加入集群、非 leader 挂掉一台。

Follower ：是 Zookeeper 集群状态的跟随者。他的逻辑就比较简单。除了响应本服务器上的读请求外，follower 还要处理leader 的提议，并在 leader 提交该提议时在本地也进行提交。另外需要注意的是，leader 和 follower 构成ZooKeeper 集群的法定人数，也就是说，只有他们才参与新 leader的选举、响应 leader 的提议。

Observer ：服务器充当一个观察者的角色。如果 ZooKeeper 集群的读取负载很高，或者客户端多到跨机房，可以设置一些 observer 服务器，以提高读取的吞吐量。Observer 和 Follower 比较相似，只有一些小区别：首先 observer 不属于法定人数，即不参加选举也不响应提议，也不参与写操作的“过半写成功”策略；其次是 observer 不需要将事务持久化到磁盘，一旦 observer 被重启，需要从 leader 重新同步整个名字空间。

2.会话（Session）

Session 指的是 ZooKeeper 服务器与客户端会话。在 ZooKeeper 中，一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。客户端启动的时候，首先会与服务器建立一个 TCP 连接，从第一次连接建立开始，客户端会话的生命周期也开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper 服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。 Session 的 sessionTimeout 值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。在为客户端创建会话之前，服务端首先会为每个客户端都分配一个sessionID。由于 sessionID 是 Zookeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的，因此，无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一。

2.1会话（Session）

在Zookeeper客户端与服务端成功完成连接创建后，就创建了一个会话。
Zookeeper会话在整个运行期间的生命周期中，会在不同的会话状态中之间进行切换，这些状态可以分为CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE等。

一旦客户端开始创建Zookeeper对象，那么客户端状态就会变成CONNECTING状态，同时客户端开始尝试连接服务端，连接成功后，客户端状态变为CONNECTED，通常情况下，由于断网或其他原因，客户端与服务端之间会出现断开情况，一旦碰到这种情况，Zookeeper客户端会自动进行重连服务，同时客户端状态再次变成CONNCTING，直到重新连上服务端后，状态又变为CONNECTED，在通常情况下，客户端的状态总是介于CONNECTING 和CONNECTED 之间。但是，如果出现诸如会话超时、权限检查或是客户端主动退出程序等情况，客户端的状态就会直接变更为CLOSE状态。

2.1会话属性

Session是Zookeeper中的会话实体，代表了一个客户端会话，其包含了如下四个属性：
sessionID。会话ID，唯一标识一个会话，每次客户端创建新的会话时，Zookeeper都会为其分配一个全局唯一的sessionID。
TimeOut。会话超时时间，客户端在构造Zookeeper实例时，会配置sessionTimeout参数用于指定会话的超时时间，Zookeeper客户端向服务端发送这个超时时间后，服务端会根据自己的超时时间限制最终确定会话的超时时间。
TickTime。下次会话超时时间点，为了便于Zookeeper对会话实行”分桶策略”管理，同时为了高效低耗地实现会话的超时检查与清理，Zookeeper会为每个会话标记一个下次会话超时时间点，其值大致等于当前时间加上TimeOut。
isClosing。标记一个会话是否已经被关闭，当服务端检测到会话已经超时失效时，会将该会话的isClosing标记为”已关闭”，这样就能确保不再处理来自该会话的心情求了。

3. 数据节点 Znode

在Zookeeper中，“节点"分为两类，第一类同样是指构成集群的机器，我们称之为机器节点；第二类则是指数据模型中的数据单元，我们称之为数据节点一一ZNode。
Zookeeper将所有数据存储在内存中，数据模型是一棵树（Znode Tree)，由斜杠（/）的进行分割的路径，就是一个Znode，例如/foo/path1。每个上都会保存自己的数据内容，同时还会保存一系列属性信息。

3.1 节点类型

在Zookeeper中，node可以分为持久节点和临时节点和顺序节点三大类。
可以通过组合生成如下四种类型节点

1. PERSISTENT

持久节点,节点创建后便一直存在于Zookeeper服务器上，直到有删除操作来主动清楚该节点。

2. PERSISTENT_SEQUENTIAL

持久顺序节点,相比持久节点，其新增了顺序特性，每个父节点都会为它的第一级子节点维护一份顺序，用于记录每个子节点创建的先后顺序。在创建节点时，会自动添加一个数字后缀，作为新的节点名，该数字后缀的上限是整形的最大值。

3.EPEMERAL

临时节点，临时节点的生命周期与客户端会话绑定，客户端失效，节点会被自动清理。同时，Zookeeper规定不能基于临时节点来创建子节点，即临时节点只能作为叶子节点。

4.EPEMERAL_SEQUENTIAL

临时顺序节点,在临时节点的基础添加了顺序特性。

4. 版本号——保证分布式数据原子性操作

每个数据节点都具有三种类型的版本信息，对数据节点的任何更新操作都会引起版本号的变化。

version– 当前数据节点数据内容的版本号
cversion– 当前数据子节点的版本号
aversion– 当前数据节点ACL变更版本号

上述各版本号都是表示修改次数，如version为1表示对数据节点的内容变更了一次。即使前后两次变更并没有改变数据内容，version的值仍然会改变。

四、zookeeper应用场景

1.分布式服务注册与订阅（dubbo）

在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，比较典型的服务注册与订阅，代表：dubbo。

2.分布式配置中心

发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者获取数据，实现配置信息的集中式管理和动态更新。代表：百度的disconf。
github：https://github.com/knightliao/disconf

3.分布式锁

分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。
控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute_lock 已预先存在，客户端在它下面创建临时有序节点。从而也形成了每个客户端的全局时序

zk分布式锁，其实可以做的比较简单，就是某个节点尝试创建临时znode，此时创建成功了就获取了这个锁；这个时候别的客户端来创建锁会失败，只能注册个监听器监听这个锁。释放锁就是删除这个znode，一旦释放掉就会通知客户端，然后有一个等待着的客户端就可以再次重新加锁。

redis分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能
zk分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小
另外一点就是，如果是redis获取锁的那个客户端bug了或者挂了，那么只能等待超时时间之后才能释放锁；而zk的话，因为创建的是临时znode，只要客户端挂了，znode就没了，此时就自动释放锁

实际场景：如果有一把锁，被多个人给竞争，此时多个人会排队，第一个拿到锁的人会执行，然后释放锁，后面的每个人都会去监听排在自己前面的那个人创建的node上，一旦某个人释放了锁，排在自己后面的人就会被zookeeper给通知，一旦被通知了之后，就ok了，自己就获取到了锁，就可以执行代码了

ZooKeeper的脑裂的出现和解决方案

出现：
在一个大的集群中往往会有一个master的存在，在长期运行过程中不可避免会出现宕机等等的问题导致master不可用，在出现这样的情况以后往往会对系统产生很大的影响，所以一般的分布式集群中的master都采用了高可用的解决方案来避免这样的情况发生。
master-slaver方式，存在一个master的节点，平时对外服务，同时有一个slaver节点来监控master，监控的同时有某种方式来进行数据同步。假如现在master挂掉了，slaver能很快获知并且迅速切换为新的master。但是在这种方式中，监控切换是一个很大的难题，但是现在Zookeeper的watch和分布式锁机制能比较好的解决这个问题。虽然Zookeeper很好的解决了这个问题，但是它的使用也存在其他的问题，比如脑裂。
在搭建hadoop的HA集群环境后，由于两个namenode的状态不一，当active的namenode由于网络等原因出现假死状态，standby接收不到active的心跳，因此判断active的namenode宕机，但实际上active并没有死亡。此时standby的namenode就会切换成active的状态，保证服务能够正常使用。若原来的namenode复活，此时在整个集群中就出现2个active状态的namenode，该状态成为脑裂。脑裂现象可能导致这2个namenode争抢资源，从节点不知道该连接哪一台namenode，导致节点的数据不统一，这在企业生产中是不可以容忍的。

解决方案：
1、添加心跳线。
原来两个namenode之间只有一条心跳线路，此时若断开，则接收不到心跳报告，判断对方已经死亡。此时若有2条心跳线路，一条断开，另一条仍然能够接收心跳报告，能保证集群服务正常运行。2条心跳线路同时断开的可能性比1条心跳线路断开的小得多。再有，心跳线路之间也可以HA（高可用），这两条心跳线路之间也可以互相检测，若一条断开，则另一条马上起作用。正常情况下，则不起作用，节约资源。

2、启用磁盘锁。
由于两个active会争抢资源，导致从节点不知道该连接哪一台namenode，可以使用磁盘锁的形式，保证集群中只能有一台namenode获取磁盘锁，对外提供服务，避免数据错乱的情况发生。但是，也会存在一个问题，若该namenode节点宕机，则不能主动释放锁，那么其他的namenode就永远获取不了共享资源。因此，在HA上使用"智能锁"就成为了必要措施。"智能锁"是指active的namenode检测到了心跳线全部断开时才启动磁盘锁，正常情况下不上锁。保证了假死状态下，仍然只有一台namenode的节点提供服务。

3、设置仲裁机制
脑裂导致的后果最主要的原因就是从节点不知道该连接哪一台namenode，此时如果有一方来决定谁留下，谁放弃就最好了。因此出现了仲裁机制，比如提供一个参考的IP地址，当出现脑裂现象时，双方接收不到对方的心跳机制，但是能同时ping参考IP，如果有一方ping不通，那么表示该节点网络已经出现问题，则该节点需要自行退出争抢资源的行列，或者更好的方法是直接强制重启，这样能更好的释放曾经占有的共享资源，将服务的提供功能让给功能更全面的namenode节点。

以上的3种方式可以同时使用，这样更能减少集群中脑裂情况的发生。但是还是不能保证完全不出现，如果仲裁机制中2台机器同时宕机，那么此时集群中没有namenode可以使用。此时需要运维人员人工的抢修，或者提供一台新的机器作为namenode，这个时间是不可避免的。希望未来能有更好的解决办法，能彻底杜绝这类情况的发生吧~