4. zookeeper 基本原理
一、ZooKeeper 基本概念
1. zookeeper 是什么？
ZooKeeper 是一个针对大型分布式系统的可靠协调系统, 是Hadoop下的一个子项目; 它提供的功能包括：注册中心、集群管理、统一配置管理、名字服务、分布式同步、发布与订阅等； 它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
Zookeeper通常用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再与生产者建立连接，调用生产者服务的内容与数据，简单示例图如下：
1
2、ZooKeeper设计目标：
ZooKeeper允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。
名称空间由ZooKeeper中的数据寄存器组成 - 称为znode，这些类似于文件和目录。 与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。
znode
通过这种树图结构的数据模型，很容易的查找到具体的某一个服务。
3、ZooKeeper主要特点：
1)、最终一致性：为客户端展示同一视图，这是 ZooKeeper 最重要的性能。
2)、可靠性：如果消息被一台服务器接受，那么它将被所有的服务器接受。
3)、实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4)、等待无关（wait-free）：慢的或者失效的 client 不干预快速的client的请求。
5)、原子性：更新只能成功或者失败，没有中间其它状态。
6)、顺序性：对于所有Server，同一消息发布顺序一致。
二、ZooKeeper 基本原理
1、ZooKeeper 系统架构
首先看一下 ZooKeeper 的架构图。
server
ZooKeeper 的架构图中我们需要了解和掌握的主要有：
（1）ZooKeeper分为服务器端（Server） 和客户端（Client），客户端可以连接到整个 ZooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不允许接受客户端连接）。
（2）客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断，客户端将自动尝试连接到另外的 ZooKeeper服务器。客户端第一次连接到 ZooKeeper服务时，接受这个连接的 ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。
（3）上图中每一个Server代表一个安装Zookeeper服务的机器，即是整个提供Zookeeper服务的集群（或者是由伪集群组成）；
（4）组成ZooKeeper服务的服务器必须彼此了解。 它们维护一个内存中的状态图像，以及持久存储中的事务日志和快照， 只要大多数服务器可用，ZooKeeper服务就可用；
（5）ZooKeeper 启动时，将从实例中选举一个 leader，Leader 负责处理数据更新等操作，一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。每个Server 在内存中存储了一份数据。
（6）Zookeeper是可以集群复制的，集群间通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性；
（7）Zab协议包含两个阶段：leader election阶段和Atomic Brodcast阶段。
- a) 集群中将选举出一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过brodcast将所有的更新告诉给follower。
- b) 当leader崩溃或者leader失去大多数的follower时，需要重新选举出一个新的leader，让所有的服务器都恢复到一个正确的状态。
- c) 当leader被选举出来，且大多数服务器完成了 和leader的状态同步后，leadder election 的过程就结束了，就将会进入到Atomic brodcast的过程。
- d) Atomic Brodcast同步leader和follower之间的信息，保证leader和follower具有形同的系统状态。
2、Zookeeper 角色
启动 Zookeeper 服务器集群环境后，多个 Zookeeper 服务器在工作前会选举出一个 Leader。选举出 leader 前，所有 server 不区分角色，都需要平等参与投票（ obServer 除外，不参与投票）；
选主过程完成后，存在以下几种角色：
leader
思考：
1、为什么需要server?
①ZooKeeper 需保证高可用和强一致性;
②为了支持更多的客户端，需要增加更多的Server;
③Follower增多会导致投票阶段延迟增大，影响性能。
２、在Zookeeper 中ObServer 起到什么作用？
①ObServer 不参与投票过程，只同步 leader的状态 ;
②Observers 接受客户端的连接，并将写请求转发给 leader节点 ;
③加入更多ObServer 节点，提高伸缩性，同时还不影响吞吐率。
３、为什么在Zookeeper中Server 数目一般为奇数？
我们知道在Zookeeper中 Leader 选举算法采用了Zab协议。Zab核心思想是当多数 Server 写成功，则任务数据写成功。
①如果有3个Server，则最多允许1个Server 挂掉。
②如果有4个Server，则同样最多允许1个Server挂掉。
既然3个或者4个Server，同样最多允许1个Server挂掉，那么它们的可靠性是一样的，所以选择奇数个ZooKeeper Server即可，这里选择3个Server。
3、ZooKeeper 写数据流程
ZooKeeper 写数据的流程图如下所示。
writer
ZooKeeper 的写数据流程主要分为以下几步：
- a)、比如 Client 向 ZooKeeper 的 Server1 上写数据，发送一个写请求。
- b)、如果Server1不是Leader，那么Server1 会把接受到的请求进一步转发给Leader，因为每个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server，比如Server1和Server2， 各个Server写成功后就会通知Leader。
- c)、当Leader收到大多数 Server 数据写成功了，那么就说明数据写成功了。如果这里三个节点的话，只要有两个节点数据写成功了，那么就认为数据写成功了。写成功之后，Leader会告诉Server1数据写成功了。
- d)、Server1会进一步通知 Client 数据写成功了，这时就认为整个写操作成功。
4. 读数据流程
相比写数据流程，读数据流程就简单得多；因为每台server中数据一致性都一样，所以随便访问哪台server读数据就行；
没有写数据流程中请求转发、数据同步、成功通知这些步骤。
5、ZooKeeper 组件
ZooKeeper组件显示了ZooKeeper服务的高级组件。 除了请求处理器，组成ZooKeeper服务的每个服务器复制其自己的每个组件的副本。
read
Replicated Database是包含整个数据树的内存数据库。 更新操作会记录到磁盘里以进行可恢复性，并且写操作将在放到内存数据库之前序列化到磁盘。
每个ZooKeeper服务器服务客户端。 客户端连接到一个服务器以提交irequest。 读取请求从每个服务器数据库的本地副本服务。 更改服务状态（写入请求）的请求由协议进行处理。
作为协议协议的一部分，来自客户端的所有写请求被转发到单个服务器，称为leader。 其余的ZooKeeper服务器（称为followers）从领导者接收消息提议并同意消息传递。 消息层负责在失败时替换领导者，并与leader同步followers。
三、ZooKeeper 应用场景总结
1、统一命名服务
统一命名服务的命名结构图如下所示：
jdni
1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。
- a）类似于域名与ip之间对应关系，ip不容易记住，而域名容易记住。
- b）通过名称来获取资源或服务的地址，提供者等信息。
2、按照层次结构组织服务/应用名称。
- a）可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。
2、配置管理
配置管理结构图如下所示：
manage
1、分布式环境下，配置文件管理和同步是一个常见问题。
- a）一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。
- b）对配置文件修改后，希望能够快速同步到各个节点上。
2、配置管理可交由ZooKeeper实现。
- a）可将配置信息写入ZooKeeper上的一个Znode。
- b）各个节点监听这个Znode。
- c）一旦Znode中的数据被修改，ZooKeeper将通知各个节点。
3、集群管理
集群管理结构图如下所示：
1
1、分布式环境中，实时掌握每个节点的状态是必要的。
- a）可根据节点实时状态做出一些调整。
2、可交由ZooKeeper实现。
- a）可将节点信息写入ZooKeeper上的一个Znode。
- b）监听这个Znode可获取它的实时状态变化。
3、典型应用
- a）Hbase中Master状态监控与选举。
4、分布式通知与协调
1、分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。
- a）NameNode需知道各个Datanode的状态。
- b）JobTracker需知道各个TaskTracker的状态。
2、心跳检测机制可通过ZooKeeper来实现。
3、信息推送可由ZooKeeper来实现，ZooKeeper相当于一个发布/订阅系统。
5、分布式锁
处于不同节点上不同的服务，它们可能需要顺序的访问一些资源，这里需要一把分布式的锁。
分布式锁具有以下特性：
- 1、ZooKeeper是强一致的。比如各个节点上运行一个ZooKeeper客户端，它们同时创建相同的Znode，但是只有一个客户端创建成功。
- 2、实现锁的独占性。创建Znode成功的那个客户端才能得到锁，其它客户端只能等待。当前客户端用完这个锁后，会删除这个Znode，其它客户端再尝试创建Znode，获取分布式锁。
- 3、控制锁的时序。各个客户端在某个Znode下创建临时Znode，这个类型必须为CreateMode.EPHEMERAL_SEQUENTIAL，这样该Znode可掌握全局访问时序。
实现原理
下面描述使用zookeeper实现分布式锁的算法流程，假设锁空间的根节点为/lock：
-
客户端连接zookeeper，并在/lock下创建临时的且有序的子节点，第一个客户端对应的子节点为/lock/lock-0000000000，第二个为/lock/lock-0000000001，以此类推；
-
客户端获取/lock下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁，否则监听刚好在自己之前一位的子节点删除消息，获得子节点变更通知后重复此步骤直至获得锁；
-
执行业务代码；
-
完成业务流程后，删除对应的子节点释放锁。
一句话： 连接zk, 在/lock目录下创建有序子节点， 判断序号是否是最小，不是，监听序号的上一级所对应的目录，直到上级释放删除节点，释放锁之后再获取锁。
6、分布式队列
分布式队列分为两种：
1、当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。
- a）一个job由多个task组成，只有所有任务完成后，job才运行完成。
- b）可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，则表明job运行完成。
2、队列按照FIFO方式进行入队和出队操作，例如实现生产者和消费者模型。
7. .ZAB 协议 & Paxos 算法
Paxos 算法是一种通用的分布式一致性算法.
ZAB 协议，是一种支持崩溃恢复的原子广播协议。
ZAB 协议两种基本的模式：
分别是崩溃恢复和消息广播。
当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。
当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。
其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。
当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。
当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播。
那么新加入的服务器就会自觉地进人数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。
正如上文介绍中所说的，ZooKeeper 设计成只允许唯一的一个 Leader 服务器来进行事务请求的处理。
Leader 服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议。
而如果集群中的其他机器接收到客户端的事务请求，那么这些非 Leader 服务器会首先将这个事务请求转发给 Leader 服务器。
产生的问题：
- 在Zookeeper 中ObServer 是如何设置？
解： 在配置中设置observer 关键字即可，
server.4=192.168.30.104:2182:2183:observer
PS: 若你觉得可以、还行、过得去、甚至不太差的话，可以“关注”或者“点赞”一下，就此谢过!
来源:
