zookeeper分布式协调组件详解 -- 学习笔记

思考：

1、在分布式场景中，怎么确保一定拿到最新的准确值
2、在分布式场景中存储一个值，为了保证安全，存储了多份
NWR理论： — 抽屉原理
N：总节点数
W：写入副本数
R：读取的副本数
保证拿到最新的数据：R+W>N
至少读取N-W+1个副本才行

Zookeeper每个节点都存储了所有数据的副本，但是zk要求写入成功的节点数达到一半，就认为写入数据成功。
如果W大，这次写入成功的概率就越小，读取数据的压力就越小
如果W小，R读取的额节点就要多，读取的性能就差
所以Zookeeper查询效率高，写入效率低

读取时，读取超过一半节点的数据，就一定会拿到最新的数据，然后根据版本，就可以拿到最新的准确值。

Quorum机制：超过一半的数据写入成功就认为写成功，剩下的暂时剔除（投票机制）

CAP理论：
C：强一致性，数据副本写的越多，一致性越好
A：高可用性，
P：分区容错性，在分布式环境中，一定要保证，当出现网络分区的时候，也能使客户端拿到最新的数据
任何分布式系统，都不可能同时满足以上三个要求；满足两个即可。

BASE理论：针对CAP理论的妥协
一定是会满足P的，C和A进行权衡，就是BASE理论
可以满足，C：最终一致性
A：基本可用

Zookeeper解决问题：
分布式同步、分布式配置管理、分布式集群管理（主节点状态管理、从节点上下线管理）、分布式命名管理、分布式队列管理、分布式锁

Zookeeper底层主要依赖两个组件：

· znode文件系统（存储数据的能力）
· watch监听系统（监听数据变化的能力）

znode文件系统：

• 不同于Linux，分为文件夹和文件，znode文件系统中只有znode节点（既可以存数据，也可以当作为文件夹）。
• 但是每个节点都必须要有一个唯一的绝对路径，每个节点都可以存储数据（根节点除外，可以存但是不建议存数据），每隔节点下都可以挂载子节点
• 虽然说zookeeper每个节点都存储了一份完整数据，但是不能存储大量的数据。所以znode只适合存储非常小量数据，不能超过1M，最好小于1K。

znode的分类:

1、按照生命周期可以分为:
	· 短暂(ephemeral)(断开连接自己删除)
	· 持久(persistent)(断开连接不删除，默认情况) 
2、按照是否自带序列编号可以分为:
	· SEQUENTIAL(带自增序列编号，由父节点维护) 
	· 非SEQUENTIAL(不带自增序列编号，默认情况)

注意点:
1、创建 znode 时设置顺序标识，znode 名称后会附加一个值，顺序号是一个单调递增的计数器，由 父节点维护
2、在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序
3、EPHEMERAL 类型的节点不能有子节点，所以只能是叶子结点
4、客户端可以在 znode 上设置监听器
监听机制：
客户端注册监听它关心的目录节点，当目录节点发生变化(数据改变、节点删除、子目录节点增加删 除)时，ZooKeeper 会通知客户端。监听机制保证 ZooKeeper 保存的任何的数据的任何改变都能快速 的响应到监听了该节点的应用程序。
监听器的工作机制，其实是在客户端会专门创建一个监听线程，在本机的一个端口上等待ZooKeeper集群发送过来事件。

注意:注册的监听在事件响应之后就失效了。那么怎么做到连续监听?请思考回答。

监听工作原理:ZooKeeper 的 Watcher 机制主要包括客户端线程、客户端 WatcherManager、 Zookeeper 服务器三部分。客户端在向 ZooKeeper 服务器注册的同时，会将 Watcher 对象存储在客户 端的 WatcherManager 当中。当 ZooKeeper 服务器触发 Watcher 事件后，会向客户端发送通知，客 户端线程从 WatcherManager 中取出对应的 Watcher 对象来执行回调逻辑。

Zookeeper典型应用场景：

命名服务

命名服务是分布式系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集群中的 机器、提供的服务地址或远程对象等，通过命名服务，客户端可以根据指定名字来获取资源的实 体、服务地址和提供者的信息。ZooKeeper也可帮助应用系统通过资源引用的方式来实现对资源 的定位和使用，广义上的命名服务的资源定位都不是真正意义上的实体资源，在分布式环境中，上 层应用仅仅需要一个全局唯一的名字。ZooKeeper可以实现一套分布式全局唯一ID的分配机制。

配置管理

程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。现在把这些 配置全部放到ZooKeeper上去，保存在 ZooKeeper 的某个目录节点中，然后所有相关应用程序对 这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 ZooKeeper 的通知，然 后从 ZooKeeper 获取新的配置信息应用到系统中就好。

集群管理

所谓集群管理无在乎两点:是否有机器退出和加入（上下线）、选举master。
对于第一点，所有机器约定在父目录 GroupMembers 下创建临时目录节点，然后监听父目录节点 的子节点变化消息。一旦有机器挂掉，该机器与 ZooKeeper 的连接断开，其所创建的代表该节点 存活状态的临时目录节点被删除，所有其他机器都将收到通知:某个兄弟目录被删除，于是，所有 人都知道:有兄弟节点挂掉了。新机器加入也是类似，所有机器收到通知:新兄弟目录加入，又多 了个新兄弟节点。
对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器 作为 master 就好。当然，这只是其中的一种策略而已，选举策略完全可以由管理员自己制定。

分布式锁

有了 ZooKeeper 的一致性文件系统，锁的问题变得容易。
锁服务可以分为两三类
一个是写锁，对写加锁，保持独占，或者叫做排它锁，独占锁
一个是读锁，对读加锁，可共享访问，释放锁之后才可进行事务操作，也叫共享锁
一个是控制时序，叫时序锁
对于第一类，我们将 ZooKeeper 上的一个znode看作是一把锁，通过 createznode() 的方式来实 现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。 用完删除掉自己创建的 /distribute_lock 节点就释放出锁。
对于第二类，/distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点， 和选 Master 一样，编号最小的获得锁，用完删除，依次有序
队列管理
两种类型的队列:
1、同步队列:当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
2、先进先出队列:队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。

ZooKeeper的设计目的/特点：

ZooKeeper作为一个集群提供数据一致的协调服务，自然，最好的方式就是在整个集群中的各服务节点 进行数据的复制和同步。通俗的讲，就是 zookeeper 以一个集群的方式对外提供协调服务，集群内部 的所有节点都保存了一份完整的数据。其中一个主节点用来做集群管理提供写数据服务，其他的从节点 用来同步数据，提供读数据服务。这些从节点必须保持和主节点的数据状态一致。

数据复制的好处:
1、容错:一个节点出错，不至于让整个集群无法提供服务
2、扩展性:通过增加服务器节点能提高 ZooKeeper 系统的负载能力，把负载分布到多个节点上
3、高性能:客户端可访问本地 ZooKeeper 节点或者访问就近的节点，依次提高用户的访问速度

特点:

• 最终一致性
  client 不论连接到哪个 Server，展示给它都是同一个数据视图，这是 ZooKeeper 最重要的性能。
• 可靠性
  具有简单、健壮、良好的性能，如果消息 message 被到一台服务器接受，那么它将被所有的服务器接受。
• 实时性
  ZooKeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网 络延时等原因，ZooKeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据 之前调用 sync() 接口。
• 等待无关(wait-free)
  慢的或者失效的 client 不得干预快速的 client 的请求，使得每个 client 都能有效的等待。
• 原子性
  更新只能成功或者失败，没有中间状态。
• 顺序性
  包括全局有序和偏序两种:
  1、全局有序:如果在一台服务器上消息 a 在消息 b 前发布，则在所有 Server 上消息 a 都将在消息 b 前被发布;
  2、偏序:指如果一个消息 b 在消息 a 后被同一个发送者发布，a 必将排在 b 前面。

Zookeeper的三种角色：

1、leader
具有选举权利和被选举的权利，节点个数必须是基数个
2、follower
具有选举权利和被选举的权利，节点个数必须是基数个
3、observer
只是根leader同步数据，能够减轻zookeeper的服务压力（没有选举权和被选举权）
到底有多少个没有关系，但是不能太多，如果太多，zookeeper同步数据的压力就增大

Zookeeper命令和Java API：

Zookeeper原理部分：

Paxos算法和ZAB协议
Paxos算法是莱斯利•兰伯特(英语:Leslie Lamport)于1990年提出的一种基于消息传递且具有高度
容错特性的一致性算法。
分布式系统中的节点通信存在两种模型:
· 共享内存(Shared Memory)
· 消息传递(Messages Passing)

基于消息传递通信模型的分布式系统，不可避免的会发生以下错误:进程可能会慢、被杀死或者重启， 消息可能会延迟、丢失、重复，在基础Paxos场景中，先不考虑可能出现消息篡改即拜占庭错误 (Byzantine failure，即虽然有可能一个消息被传递了两次，但是绝对不会出现错误的消息)的情况。

Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发 生以上任何异常，都不会破坏决议一致性。

Paxos算法使用一个希腊故事来描述，在Paxos中，存在三种角色，分别为：
Proposer(提议者，用来发出提案proposal)，
Acceptor(接受者，可以接受或拒绝提案)，
Learner(学习者，学习被选定的提案，当提案被超过半数的Acceptor接受后为被批准)

下面更精确的定义Paxos要解决的问题:
决议(value)只有在被proposer提出后才能被批准
在一次Paxos算法的执行实例中，只批准(chose)一个value
learner只能获得被批准(chosen)的value

ZooKeeper的选举算法有两种:一种是基于 Basic Paxos(Google Chubby采用)实现的，一种是基于 Fast Paxos(ZooKeeper采用)算法实现的。ZooKeeper 默认的选举算法为 Fast Paxos，并且 ZooKeeper在3.4.0 版本后只保留了 FastLeaderElection 算法。

ZooKeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做 ZAB协议(Zookeeper Atomic BroadCast)。
ZAB协议有两种模式，它们分别是:

• 崩溃恢复模式(选主)
  当服务启动或者在领导者崩溃后，ZAB就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和follower之间具有相同的系统状 态。
• 原子广播模式(同步)
  当ZooKeeper集群选举出leader同步完状态退出恢复模式之后，便进入了原子广播模式。所有的写请求都被 转发给leader，再由leader将更新proposal广播给follower

为了保证事务的顺序一致性，zookeeper 采用了递增的事务 id 号(zxid)来标识事务。所有的提议 (proposal)都在被提出的时候加上了 zxid。实现中 zxid 是一个 64 位的数字，它高32位是 epoch 用 来标识 leader 关系是否改变，每次一个 leader 被选出来，它都会有一个新的 epoch，标识当前属于那 个 leader 的统治时期。低 32 位用于递增计数。

Basic Paxos流程:
1、选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server
2、选举线程首先向所有Server发起一次询问(包括自己)
3、选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的 serverid(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息 (serverid,zxid)，并将这些信息存储到当次选举的投票记录表中
4、收到所有Server回复以后，就计算出id最大的那个Server，并将这个Server相关信息设置成下一次要 投票的Server
5、线程将当前id最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数， 设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状 态，否则，继续这个过程，直到leader被选举出来。

通过流程分析我们可以得出:
1、要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1
2、且存活的Server的数目不得少于n+1
每个 Server 启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的 server 还会从磁盘快照中恢复数据和会话信息，zookeeper 会记录事务日志并定期进行快照，方便在 恢复时进行状态恢复。
Fast Paxos 流程是在选举过程中，某Server首先向所有 Server 提议自己要成为 leader，当其它 Server 收到提议以后，解决 epoch 和 zxid 的冲突，并接受对方的提议，然后向对方发送接受提议完成的消 息，重复这个流程，最后一定能选举出 Leader

全新集群选主
以一个简单的例子来说明整个选举的过程:假设有五台服务器组成的 zookeeper 集群，它们的 serverid 从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样 的。假设这些服务器依序启动，来看看会发生什么:
1、服务器1启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的选举状态一直是 LOOKING状态
2、服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数 据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数 以上是3)，所以服务器1、2还是继续保持LOOKING状态
3、服务器3启动，根据前面的理论分析，服务器3成为服务器1,2,3中的老大，而与上面不同的是，此时有三 台服务器(超过半数)选举了它，所以它成为了这次选举的leader
4、服务器4启动，根据前面的分析，理论上服务器4应该是服务器1,2,3,4中最大的，但是由于前面已经有半 数以上的服务器选举了服务器3，所以它只能接收当小弟的命了
5、服务器5启动，同4一样，当小弟

• 总结:zookeeper server的三种工作状态
  LOOKING:当前Server不知道leader是谁，正在搜寻，正在选举
  LEADING:当前Server即为选举出来的leader，负责协调事务
  FOLLOWING:leader已经选举出来，当前Server与之同步，服从leader的命令

非全新集群选主
那么，初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down 掉，重新选举时，选举过程就相对复杂了。

需要加入数据 version、serverid 和 逻辑时钟。
逻辑时钟:这个值从0开始递增，每次选举对应一个值，也就是说:如果在同一次选举中，那么这个值 应该是一致的;逻辑时钟值越大，说明这一次选举 leader 的进程更新，也就是每次选举拥有一个 zxid，投票结果只取 zxid 最新的
数据 version:数据新的 version 就大，数据每次更新都会更新 version
server id:就是我们配置的 myid 中的值，每个机器一个

选举的标准就变成:
1、逻辑时钟小的选举结果被忽略，重新投票
2、统一逻辑时钟后，数据version大的胜出
3、数据version相同的情况下，server id大的胜出
根据这个规则选出 leader。

数据同步

选完 leader 以后，zk就进入状态同步过程。
详细步骤:
1、leader等待server连接;
2、follower连接leader，将最大的zxid发送给leader;
3、leader根据follower的zxid确定同步点;
4、完成同步后通知follower 已经成为uptodate状态;
5、follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

案例：
1、使用ZooKeeper实现服务器动态上下线感知
2、使用ZooKeeper实现分布式共享锁