浅谈ZooKeeper基本原理与源码分析

@TOC

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

目录

概 述

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 除外，不参与投票）；

思考：
1.为什么需要sever?
1.zk需要保证可用性和强一致性
2.为了支持更多的客户端，需要增加更多的server.
3.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 的写数据流程主要分为以下几步：
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 数据写成功了，这时就认为整个写操作成功。

Replicated Database是包含整个数据树的内存数据库。 更新操作会记录到磁盘里以进行可恢复性，并且写操作将在放到内存数据库之前序列化到磁盘。

每个ZooKeeper服务器服务客户端。 客户端连接到一个服务器以提交irequest。 读取请求从每个服务器数据库的本地副本服务。 更改服务状态（写入请求）的请求由协议进行处理。

作为协议协议的一部分，来自客户端的所有写请求被转发到单个服务器，称为leader。 其余的ZooKeeper服务器（称为followers）从领导者接收消息提议并同意消息传递。 消息层负责在失败时替换领导者，并与leader同步followers。

三、ZooKeeper 应用场景总结
1、统一命名服务
1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。
a）类似于域名与ip之间对应关系，ip不容易记住，而域名容易记住。
b）通过名称来获取资源或服务的地址，提供者等信息。
2、按照层次结构组织服务/应用名称。
a）可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。
2、配置管理
1、分布式环境下，配置文件管理和同步是一个常见问题。
a）一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。
b）对配置文件修改后，希望能够快速同步到各个节点上。

2、配置管理可交由ZooKeeper实现。
a）可将配置信息写入ZooKeeper上的一个Znode。
b）各个节点监听这个Znode。
c）一旦Znode中的数据被修改，ZooKeeper将通知各个节点。

3、集群管理
1、分布式环境中，实时掌握每个节点的状态是必要的。
a）可根据节点实时状态做出一些调整。
2、可交由ZooKeeper实现。
a）可将节点信息写入ZooKeeper上的一个Znode。
b）监听这个Znode可获取它的实时状态变化。

4.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可掌握全局访问时序。

6、分布式队列

分布式队列分为两种：
1、当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。

a）一个job由多个task组成，只有所有任务完成后，job才运行完成。

b）可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，则表明job运行完成。

2、队列按照FIFO方式进行入队和出队操作，例如实现生产者和消费者模型

小结

参考资料和推荐阅读

1.链接: 参考资料.