ZooKeeper介绍
概述
ZooKeeper是一种分布式的，开放源码的分布式应用程序协调服务，提供了包括配置维护、域名服务、分布式同步等功能。
架构
ZooKeeper采用集群模式，避免ZooKeeper本身出现单点故障。集群节点为N的情况下，最多可以保证(N-1)/2个节点宕机，仍能提供服务。
图-1 ZooKeeper架构图
每个Server在内存中存储了一份数据。
ZooKeeper启动时，将从实例中选举一个Leader（Paxos协议）。
Leader负责处理数据更新等操作（Zab协议）。
一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。
ZooKeeper基本概念
集群角色
Leader（领导者）：集群中只有一个节点为Leader角色，它负责进行投票的发起和决议，更新系统状态。
Follower（跟随者）：Follower用于接收客户端请求并向客户端返回结果，在选主过程中参与投票。
Observer（观察者）：Observer可以接收客户端连接，并将请求转发给Leader节点。但Observer不参加投票过程，只同步Leader的状态，Observer的目的是为了扩展系统，提高读取速度。
Learner（学习者）：包括跟随者（follower）和观察者（observer）。
Client：请求发起方。
数据模型
ZooKeeper提供的命名空间与标准文件系统的名称空间非常相似，命名空间中的每个节点都由路径标识。与标准文件系统不同，ZooKeeper 命名空间中的每个节点都可以拥有与其关联的数据以及子节点。这就像拥有一个允许文件也成为目录的文件系统，使用标准文件系统的“数据节点“的概念，ZooKeeper 数据节点称之为Znode。
节点类型及特性
Znode都是有生命周期的，其生命周期的长短取决于Znode的节点类型，在Zookeeper中。节点类型可分为持久节点（PERSISTENT）、临时节点（EPHEMERAL）和顺序节点（SEQUENTIAL）三大类，在节点创建过程中可以使用以下四种组合型节点类型。
持久节点（PERSISTENT）： 数据节点被创建之后，会一直存在于Zookeeper服务器上，直至有删除操作来主动删除这个节点。
持久顺序节点（PERSISTENT_ SEQUENTIAL）：和持久节点的基本特性保持一致，不同之处表现在顺序上。在Zookeeper中，每一个父节点都会为它的第一级子节点维护一份顺序，在创建子节点时，Zookeeper会自动给节点名称增加一个数字后缀，作为Znode的最终名称。
临时节点（EPHEMERAL）：临时节点的生命周期和客户端的会话绑定，客户端的会话一旦失效，那么这个节点就会被自动清理掉。
临时顺序节点（EPHEMERAL_ SEQUENTIAL）：和临时节点的基本特性保持一致，不同之处表现在顺序上。
ACL权限控制
Zookeeper的ACL权限控制分为三个方面：权限模式（Scheme）、授权对象（ID）和权限（Permission），通常使用“scheme:id:permission”来标识一个有效的ACL信息。
权限模式（Scheme）
权限模式用来确定权限验证过程中使用的验证策略，在Zookeeper使用的三种权限模式：
Digest：Digest权限模式使用类似于“username:password”的形式来进行权限配置；
World：World权限模式是一种最开放的权限控制模式， 它下面只有一个anyone的ID, world:anyone代表任何人，所有用户都可以在不进行权限校验的情况下操作Zookeeper上的数据，它可以看做一个特殊的Digest权限模式。
IP：IP模式通过IP地址粒度或者IP端的粒度进行权限控制。
授权对象（ID）：
Digest: 一个自定义的用户名密码（“username:password”）。
World: 只有一个ID：“anyone”，代表任何用户。
IP：授权对象通常是一个IP地址或者IP段，与客户端主机IP向匹配。
权限（Permission）
Create（c）：允许授权对象在该数据节点下创建子节点。
Delete（d）：允许授权对象删除该数据节点的子节点。
Read（r）：允许授权对象访问该数据节点并读取其数据内容或者子节点列表。
Write（w）：允许授权对象对该数据节点进行更新。
Admin（a）：允许授权对象对该数据节点进行ACL相关的设置操作。
特点
最终一致性：为客户端展示同一视图，这是ZooKeeper最重要的功能。
可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。
实时性：ZooKeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。
原子性：更新只能成功或者失败，没有中间状态。
顺序性：所有Server，同一消息发布顺序一致。
应用场景
数据发布/订阅：发布者把数据发布到ZooKeeper的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。
分布式协调/通知：一种典型的分布式系统机器间的通信方式是心跳。心跳检测是指分布式环境中，不同机器之间需要检测彼此是否正常运行。可以基于ZooKeeper临时节点的特性，不同机器在ZooKeeper的一个指定节点下创建临时子节点，不同机器之间可以根据这个临时节点来判断客户端机器是否存活。
Master 选举：利用ZooKeeper创建节点API接口，提供了强一致性，能够很好保证在分布式高并发情况下节点的创建一定是全局唯一性。集群机器都尝试创建节点，创建成功的客户端机器就会成为 Master，失败的客户端机器就在该节点上注册一个Watcher用于监控当前Master机器是否存活，一旦发现Master宕机，其余客户端就可以进行选举了。
命名服务：ZooKeeper的命名服务即生成全局唯一的ID，通过在ZooKeepr里创建顺序节点，能够很容易创建一个全局唯一的路径，此路径就可以作为一个名字。
资源模式
在新建集群时，选择不同资源模式需要准备不同的资源类型，目前支持容器集群、虚拟机集群两种资源模式，资源类型准备说明如下：
容器集群：新建Zookeeper容器集群需要先创建KaaS集群，KaaS集群可视为容器集群的资源域。可通过[云服务/云容器引擎/集群]新建集群进入KaaS集群创建页面。
注：在云平台的[云服务/云容器引擎/集群]新建KaaS集群时要求Kubernetes版本1.15.0+。