前言
相信大家对zookeeper并不陌生，但是你真的了解Zookeeper 是个什么东西嘛？如果别人让你给他讲讲，你能说出个什么东西？
通过本文，希望带大家稍微了解一下Zookeeper。如果没有学习Zookeeper，本文将是你的垫脚石。
本文只涉及到Zookeeper的一些概念。
Zookeeper的由来
最早起源于雅虎研究院的一个研究小组，在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点的问题。所以，雅虎人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员精力集中在处理业务逻辑上。
Zookeeper概览
Zookeeper是一个开源的分布式协调服务，Apache Zookeeper成为Hadoop，HBase和其他分布式框架使用的有组织的服务标准。Apache HBase 使用 Zookeeper跟踪分布式数据状态。Zookeeper的设计目标就是将那些复杂且容易出错的分布式一致性服务封装起来，构建一个高效可靠的原语集，并以一系列简单易用的接口提供给用户。
原语：操作系统或者计算机网络用语范畴。是由若干条指令组成，用于完成一定功能的一个过程。具有不可分割性，即原语的执行必须是连续的，在执行过程中不允许被中断。有点 原子语句的意思，不可分割执行的语句。
Zookeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于Zookeeper 实现诸如数据发布\订阅、负载均衡、命名服务、分布式协调\通知、集群管理、Master选举、分布式锁和分布式队列。
Zookeeper一个最常用的场景就是担任服务生产者和消费者的注册中心，服务生产者将自己的服务注册到Zookeeper中心，服务的消费者进行服务调用的时候，先到Zookeeper中查找服务，获取服务生产者的详细信息后，再去调用服务生产者的内容与数据。如下图所示，在 Dubbo中，Zookeeper 就担任了注册中心这一角色。
Zookeeper的使用
为什么最好使用奇数台服务器构成Zookeeper集群？
我们知道，在Zookeeper的leader选举算法中采用了zab协议，zab的核心思想是当多数server写成功，则任务数据写成功。
- 如果有3个server则最多有一个，则最多有一个server挂掉。
- 如果有四个server则最多允许1个server挂掉。
既然他们的可靠性一样，当然选择3台服务器了。
关于Zookeeper 的一些重要概念
- Zookeeper本身就是一个分布式程序，只要半数以上节点存活，Zookeeper就能提供服务。
- 为了保障高可用，最好集群方式部署Zookeeper，那么只要保证集群中大部分机器是可用的，则Zookeeper集群仍能提供服务。
- Zookeeper的数据保存在内存中，这也就保证了高吞吐量和低延迟。（但是内存的存储量不能太大，这也是znode中保存较少数据量的原因）
- Zookeeper是高性能的，在读多于写的应用程序中尤其高性能。因为写会导致所有服务器间同步状态。（读多于写是协调服务的典型场景）
- Zookeeper有临时节点的概念，当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在，而当会话终结时，瞬时节点被删除。持久节点是指一旦这个znode 被创建，除非主动进行移除操作，否则这个节点一直保存在Zookeeper上。
- Zookeeper底层只提供了两个功能：1、管理用户程序提交数据 2、为用户程序提供数据节点监听服务
会话（session）
Session 指的是Zookeeper服务端与客户端的会话。在Zookeeper中，一个客户端链接是指客户端与服务端的一个TCP长连接。客户端启动的时候，首先会与服务器建立一个TCP链接，从第一次建立连接开始，客户端会话的生命周期也开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接收响应。同时还能通过该连接接收来自服务器端的Watch事件通知。Session 的sessionTimeout值用来设置一个客户端会话的超时事件。由于服务器压力太大，网络故障或者客户端主动断开连接等各种原因，导致客户端连接断开时，只要在规定的sessionTimeout时间内，重新连上集群内任意一台机器，那么之前创建的会话仍然有效。
在客户端创建会话之前，服务器端会首先为每个客户端分配一个sessionId，由于sessionId是Zookeeper会话的一个重要标识，许多与会话相关的运行机制，都是基于这个sessionId，因为无论哪台服务器为客户端分配的sessionId，都务必保证全局唯一。
Zookeeper的节点
在谈到分布式的时候，我们通常所说的节点是指集群中的每一台机器。然后在Zookeeper中，节点分为两类：
第一类同样构成集群的机器，我们称之为机器节点。
第二类是指数据模型中的数据单元，我们称之为数据节点 Znode.
Zookeeper将所有数据存储在内存中，数据模型是一棵树，（Znode tree）,由 / 进行分割，每个Znode上都保存自己的数据内容，同时还会保存一系列属性信息。
在Zookeeper中 node 可以分为持久节点和临时节点两类。所谓持久节点就是一旦 这个Znode被创建，除非进行主动移除操作，否则这个Znode会一直保存在Zookeeper上，而临时节点就不同了，他的生命周期和客户端会话保持一致，一旦客户端会话失效，那么这个客户端创建的所有临时节点将被移除。另外，Zookeeper还为每个节点添加一个SEQUENTIAL 属性，那么这个节点被创建的时候 ，Zookeeper会自动在其节点名称后面追加一个整型数字，这个整型数字是一个由父节点维护的自增数字。
Zookeeper的watcher
watcher 事件监听器，是Zookeeper的一个很重要的额特性，Zookeeper允许客户端在指定节点上注册一些watcher，并且在一些特定事件出发的时候，Zookeeper服务端会将事件通知到感兴趣的客户端上。该机制是Zookeeper实现分布式协调的重要特性。
Zookeeper的ACL
Zookeeper 采用ACL(acccess control list)策略进行控制。类似于UNIX 系统的权限控制，Zookeeper 定义了一下五种权限。
[图片上传失败...(image-9643d7-1572493283710)]
其中需要注意的是 create delete 是针对子节点的权限控制。
Zookeeper的特点
- 顺序一致性：同以客户端发起的事物请求，最终会严格的按照顺序应用到Zookeeper中去
- 原子性：所有的事物请求结果在整个集群所有机器上应用情况都是一样的，即 要么都成功，要么都失败
- 单一系统镜像：无论客户端连接那一台服务器，看到服务端的模型都是一致的
- 可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖
可构建集群
为了保证高可用，最好以集群形态来部署Zookeeper，这样只要集群中大多数机器是可用的，那么分布式协调服务仍可用。客户端在使用Zookeeper时，需要知道机器列表，通过与集群中的某一台机器建立TCP连接来使用服务。客户端使用这个TCP连接来发送请求，获取结果，获取监听事件，及发送心跳包。如果这个连接异常了，客户端可用连接到另外的机器上。
Zookeeper集群角色介绍
最典型的模式：Master/Slave模式，在这种模式中，通常Master服务器作为主服务器提供写服务。其他的Slave服务器从主服务器通过异步复制的方式获取Master服务器最新的数据提供读服务。
但是在Zookeeper中没有引入传统的Master/Slave概念，而是引入了Leader\Follower\Observer三种角色，如下图所示：
[图片上传失败...(image-92cd12-1572493283710)]
ZooKeeper 集群中所有机器通过一个Leader选举过程来选定一台为 Leader 机器，Leader 既可以提供读服务，也可用提供写服务，出了 Leader 外，Follower和Observer都只能提供读服务。Follower和Observer的区别就是，Observer机器不参与Leader 的选举过程，也不参与写操作的 “过半写成功”策略，因为Observer机器可用在不影响写性能的情况下提升集群的读性能。
ZAB 协议&Paxos算法
Paxos 算法应该可以说是ZooKeeper 的灵魂了，但是，ZooKeeper 并没有完全采用Paxos 算法，而是使用ZAB 协议作为其保证数据一致性的核心算法。另外，ZAB协议并不像 Paxos 算法那样 ，是一种通用的分布式一致性算法，它是一种特别为Zookeeper 设计的崩溃可恢复的原子信息广播算法。
ZAB 协议介绍
ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务ZooKeeper 专门设计的一种支持崩溃恢复的的原子广播协议，在ZooKeeper 中，主要依赖ZAB协议来实现分布式数据的一致性，基于该协议，，ZooKeeper 实现了，一种主备模式的系统架构来保证集群中各个副本数据的一致性。
ZAB 协议两种基本的模式：崩溃恢复和消息广播
ZAB 协议包括两种基本的模式，崩溃恢复和消息广播。当整个服务框架在启动的过程中，或是leader 服务器出现了网络中断 崩溃退出与重启等异常情况，ZAB 协议就会进去恢复模式，并选举产生新的Leader 服务器，当选举产生了新的Leader 服务器，同时集群中，已经有过半的机器与该Leader 服务器完成了状态同步后，ZAB 协议就会退出恢复模式。其中的状态同步是指数据同步，用来保证集群中存在过半的机器能够与Leader 服务器状态保持一致。
当集群中已经有过半的Follower 服务器完成了和Leader 服务器的同步后，那么整个服务框架就可以进入消息广播模式了。当一台同样遵守ZAB 协议的服务器加入到集群中时，如果此时已经存在一个Leader 服务器在负责进行消息广播时，那么新加入的机器就会自觉的进入数据恢复模式，找到Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息的广播流程中去。
ZooKeeper 只允许一个Leader 服务器参与到客户端的事务性请求中去。其他的节点接收到事务性请求只能转发给Leader 。
文章参考：
图解 Paxos 一致性协议
Zookeeper ZAB 协议分析
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ProjectDescription
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index
https://zhuanlan.zhihu.com/p/30024403