zookeeper 集群及其选举机制

分布式理论强一致性:强一致性也叫做线性一致性，。所谓强一致性，即复制是同步的。也就是主库修改完数据之后，从库能立刻将对应的数据修改完成。注意:在分布式领域中不可能保证强一致性。
弱一致性:弱一致性，即复制是异步的。读取数据库数据时，如果该数据正好被修改时，主库和从库的数据允许在一段时间内存在不同，也就是可能会读取到以前的数据。
最终一致性:当用户从异步从库读取时，如果此异步从库落后，他可能会看到过时的信息。这种不一致只是一个暂时的状态——如果等待一段时间，从库最终会赶上并与主库保持一致。这称为最终一致性。
zookeeper 集群 【zookeeper 集群及其选举机制】zookeeper 集群数据是如何实现同步的?
Zk集群是由多个Server节点组成了一个集群,只有一个Leader节点;其他节点类型都是为Follower类型。

每个Follower节点保存了Leader节点副本数据;
全局保证数据一致性问题,
分布式读写分开写的请求统一交给 Leader 节点实现， Follower或者是ObServer 节点主要实现读的操作:

注意:如果连接的节点类型是一个 Follower 节点或 Observer 节点的情况下做写的操作的时候直接转发到Leader实现写操作。
集群搭建搭建zk集群配置:

每个zk配置文件需要有myid.
每个zk配置文件中需要配置所有集群的节点

搭建过程:这里以三台zk服务器为例,并且部署在一台电脑上
第一步、配置每个zk节点的配置文件
第一个zk zoo.cfg配置

tickTime=2000initLimit=10syncLimit=5dataDir=D:/Dev/ZooKeeper1/datadataLogDir=D:/Dev/ZooKeeper1/logclientPort=2181// 2888表示：服务器之间的通信端口 ， 3888表示：Leader选举的端口server.1=127.0.0.1:2888:3888server.2=127.0.0.1:2889:3889server.3=127.0.0.1:2890:3890

第二个zk zoo.cfg配置

tickTime=2000initLimit=10syncLimit=5dataDir=D:/Dev/ZooKeeper2/datadataLogDir=D:/Dev/ZooKeeper2/logclientPort=2181server.1=127.0.0.1:2888:3888server.2=127.0.0.1:2889:3889server.3=127.0.0.1:2890:3890

第三个zk zoo.cfg配置

tickTime=2000initLimit=10syncLimit=5dataDir=D:/Dev/ZooKeeper3/datadataLogDir=D:/Dev/ZooKeeper3/logclientPort=2181server.1=127.0.0.1:2888:3888server.2=127.0.0.1:2889:3889server.3=127.0.0.1:2890:3890

第二步、在每个zk的数据目录新建文件 myid ，文件的值为对应的server.x对应的×值，
例如: server.1=127.0.0.1:2888:3888 zk节点的myid的值为:1
注意:每个zk节点的myid不能重复。
第三步、依次启动zk节点即可。
Java客户端连接集群将各个zk 连接信息用英文逗号分开，如下面代码所示：
private static final Stringurl="1.11.11.1:2181,1.11.11.2:2182,1.11.11.3:2183"; 集群选举策略节点状态
LOOKING:寻找Leader状态，处于该状态需要进入选举流程
LEADING:领导者状态，处于该状态的节点说明是角色已经是Leader(执行读、写的操作)
FOLLOWING︰跟随者状态，表示Leader已经选举出来，当前节点角色是follower(执行读的操作，写的操作转发给LEADER执行)
OBSERVER:观察者状态，表明当前节点角色是observer ， observer角色和Follower角色相似，只不过observer 不能够参与Leader选举。作用:主要不影响本身选举的时间效率，目的时提高客户端读的请求效率。(执行读的操作，写的操作转发给LEADER执行)
事务id (zxid)
Zookeeper状态的每次变化〔也就是写的请求）都接收一个ZXID(Zookeeper事务id)形式的标记。ZXID是一个64位的数字，由Leader统一分配，全局唯一，不断递增。
ZXID展示了所有的ZooKeeper的变更顺序。每次变更会有一个唯一的zxid ，如果zxid1小于zxid2说明zxid1在zxid2之前发生。
myid
集群中每台节点的标识， id为zookeeper 提供了一个稳定的标识符
选举原理 ZooKeeper选举实现原理

状态变更服务器启动的时候每个Server的状态都是为“选举状态” ，如果当前的leader 的角色宕机之后，非 obServer 角色的节点都会会从新进入到选举。
发起投票的时候,每个Server端都会产生(myid,zxid)投票选举，系统默认初始化的时候zxid为0 ，如果在运行期间每个Server的zxid 可能不会不同，这取决于最后一次做更新的操作。
接受自己投票实现投票pk
1.先检查zxid ，谁最大谁就是为leader.
2.如果zxid都是一样的情况下时候， myid谁最大谁就是为leader.
3.如果有过半机制已经选举出了leader,.之后启动的节点不会加入选举,

zk集群初始化启动期间Leader选举如果选举的zk节点超过一半之后，已经满足过半机制leader已经选举出来了，后面启动的zk节点不需要重新进行选举的。
在集群初始化阶段，当有一台服务器ZK1启动时，其单独无法进行和完成Leader选举，当第二台服务器ZK2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader ，于是进入Leader选举过程。选举过程开始，过程如下:
(1)、每个Server发出一个投票。由于是初始情况， ZK1和ZK2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID ，使用(myid,ZXID)来表示，此时ZK1的投票为(1,0) ， ZK2的投票为(2,0) ，然后各自将这个投票发给集群中其他机器。
(2）、接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。
(3)、处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行比较，规则如下

优先检查ZXID 。ZXID比较大的服务器优先作为Leader 。
如果ZXID相同，那么就比较myid 。myid较大的服务器作为Leader服务器。
对于ZK1而言，它的投票是(1, 0) ，接收ZK2的投票为(2,0) ，首先会比较两者的ZXID ，均为0 ，再比较myid ，此时ZK2的myid最大，于是ZK2胜。ZK1更新自己的投票为(2 ， O) ，并将投票重新发送给ZK2 。

(4)、统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于ZK1、ZK2而言，都统计出集群中已经有两台机器接受了(2,0)的投票信息，此时便认为已经选出ZK2作为Leader 。
(5)、改变服务器状态。一旦确定了Leader ，每个服务器就会更新自己的状态，如果是Follower ，那么就变更为FOLLOWING ，如果是Leader ，就变更为LEADING 。当新的Zookeeper节点ZK3启动时，发现已经有Leader了，不再选举，直接将直接的状态从LOOKING 改为 FOLLOWING 。
Zookeeper集群运行期间Leader重新选在Zookeeper运行期间，如果Leader节点挂了，那么整个Zookeeper集群将暂停对外服务，进入新一轮Leader选举。假设正在运行的有ZK1、ZK2、ZK3三台服务器，当前Leader是ZK2 ，若某一时刻Leader挂了，此时便开始Leader选举。
(1）、变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING ，然后开始进入Leader选举过程。
(2）、每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定ZK1的ZXID为124 ， ZK3的ZXID为123;在第一轮投票中， ZK1和ZK3都会投自己，产生投票(1,124) ， (3,123) ，然后各自将投票发送给集群中所有机器。
(3）、接收来自各个服务器的投票。与启动时过程相同。
(4）、处理投票。与启动时过程相同，由于ZK1事务ID大， ZK1将会成为Leadero
如何保证zk 集群可用?
答：必须保证过半原则，所以推荐zk 集群节点数量为奇数。
zk集群使用Observer 实现实现扩展怎么添加observer类型的zk节点?
在配置信息后面添加
server.3=127.0.0.1:2890:3890:observer
有什么作用?
主要不影响zk集群的leader选举时间的效率，目的是提高客户端查询的效率。observer类型的节点不参与 leader 选举。