zookeeper工作原理，选举理解

一、Zookeeper是什么？
分布、开源的应用程序协调服务,他可以用来做配置中心，注册中心，集群管理，分布式锁等。
二、Zookeeper提供什么？
（1）文件系统：zookeeper维护一个类似文件系统的数据结构：

（2）通知机制：客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

二.zookeeper 有四种节点类型：
1、PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在
2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3、EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除
4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

三、Zookeepr工作原理
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

投票机制选举：每个服务会投出出最大的事务txid持有者为leader，如果txid 相等，则会投票给最大的服务sid的服务，
同步机制：同步是根据leader最大的txid与follower中的txid 的差确定同步点,进行同步数据的

四、zookeeper怎么保证顺序一致性的：
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上 了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个 新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
例如：A提交请求，这时B也提交请求，那么A请求肯定会在B请求之前执行，leader会保存事务到队列里，并等待A请求执行完毕才会执行B的请求

zookeeper的三种服务状态：
（1）LOOKING：当前Server不知道leader是谁，正在搜寻。
（2）LEADING：当前Server即为选举出来的leader。
（3）FOLLOWING：leader已经选举出来，当前Server与之同步。

五、zookeeper是如何选取主leader的？（zookeeper选举 fast paxos算法）
1.Leader选举有如下两种
第一种：服务器初始化启动的Leader选举。
第二种：服务器运行时期的Leader选举

2.Leader选举的前提条件
只有服务器状态在LOOKING（竞选状态）状态才会去执行选举算法。
Zookeeper 的集群规模至少是2台机器，才可以选举Leader，这里以3台机器集群为例。
当一台服务器启动是不能选举的，等第二台服务器启动后，两台机器之间 可以互相通信，才可以进行Leader选举
服务器运行期间无法和Leader保持连接的时候。

3.服务器启动时期的 Leader 选举
在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动后，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下：

(1) 每个Server发出一个投票投给自己。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。

(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下

1、优先检查ZXID。ZXID比较大的服务器优先作为Leader。

2、如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。

对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。

(5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

**4.服务器运行时期的 Leader 选举 **
在Zookeeper运行期间，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器，当前Leader是Server2，若某一时刻Leader挂了，此时便开始Leader选举。选举过程如下：

(1)变更状态。Leader挂后，余下的非Observer服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举流程。

(2)每个Server会发出一个投票。在这个过程中，需要生成投票信息(myid,ZXID)每个服务器上的ZXID可能不同，我们假定Server1的ZXID为123，而Server3的ZXID为122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。

(3)接收来自各个服务器的投票。与启动时过程相同。

(4)处理投票。与启动时过程相同，此时，Server1将会成为Leader。

(5)统计投票。与启动时过程相同。

(6)改变服务器的状态。与启动时过程相同。

选举策略参考:https://www.cnblogs.com/veblen/p/10992103.html

5.zookeeper 数据同步机制：
选完Leader以后，zk就进入状态同步过程。

Leader 等待 server 连接；
Follower 连接 leader，将最大的 zxid 发送给 leader；
Leader根据follower的zxid确定同步点；
完成同步后通知follower已经成为uptodate状态；
Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

六 、一致性相关概念：
1.弱一致性：
读取的数据可能前后不一致，且过了不一致的时间范围，还会有不一致的现象
2.最终一致性：
读取的数据可能存在不一致的情况，但过了不一致的时间，读取的数据就是都一直的
3.顺序一致性：
读取的数据都是最近一次写的，所有服务读取都是一致的
4.强一致性：
每个服务读取的数据都是一致的，做写操作时，只有数据被写完成才会提供服务，降低了服务的额可用性

七、zookeeper的一致性理解：
是写操作顺序一致性，因为在写的过程中会通过leader 增加一个事务id,并通过 zab的原子广播协议，二段提交协议，保证大半节点都发送ack消息确认提交，这时leader 才会发起提交事务命令，写的过程是根据请求顺序进行执行的 ，但读不是 线性一致的，因为有个过半提交原则，半数以外的服务读取的还是旧的数据，所以zookeeper读取数据是最终一致性的

参考链接：https://blog.csdn.net/wzk646795873/article/details/79706627?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param