Zookeeper(二)—集群

一、集群中的角色

• Leader:

处理所有的事务请求（写请求），可以处理读请求，集群中只能有一个Leader

• Follower：

只能处理读请求，同时作为 Leader的候选节点，即如果Leader宕机，Follower节点
要参与到新的Leader选举中，有可能成为新的Leader节点。

• Observer：

只能处理读请求。不能参与选举.

leader负责读和写，follower只负责读，写请求直接转发给leader。如果读请求很大，可以加入observer，它也只负责读。不负责写，而且它不参与投票选举。这样做的好处就是leader不会管observer的节点是否存活，不会等observer节点的反馈结果，只会管follower的反馈。这样，observer挂了也无所谓，不挂正好分担读请求。

二、集群选举机制

第一次启动选举机制

服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票)，选举无法完成，服务器1状态保持为LOOKING;

服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息:此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1)大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING

服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果:服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING;

服务器4启动，发起一次选举。此时服务器1，2，3已经不是LooKING状态，不会更改选票信息。交换选票信息结果:服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLOWING;

以后的服务器，都和服务器4的情况一致。

非第一次启动

1. 当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举:
   (1)服务器初始化启动。
   (2)服务器运行期间无法和Leader保持连接。

2. 而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态:
   (1)集群中本来就己经存在一个Leader。
   对于已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
   (2)集群中确实不存在Leader。
   假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、，并且此时sID为3的服务器是。一时刻，3和5服务器出现故障，因此开始进行Leader选举。

选举Leader规则:
1.EPOCH大的直接胜出
2.EPOCH相同，事务id大的胜出
3.事务id相同，服务器id大的胜出

SID:服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID:事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的zxID值不一定完全一致，这和ZooKeeper服务器对于客户端"更新请求"的处理逻辑速度有关。
Bpoch:每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加

三、集群经典问题

脑裂问题
在"双机热备"高可用（HA）系统中，当联系两个节点的"心跳线"断开时(即两个节点断开联系时)，本来为一个整体、动作协调的HA系统，就分裂成为两个独立的节点(即两个独立的个体)。由于相互失去了联系，都以为是对方出了故障，两个节点上的HA软件像"裂脑人"一样，“本能"地争抢"共享资源”、争起"应用服务"。就会发生严重后果：1）或者共享资源被瓜分、两边"服务"都起不来了；2）或者两边"服务"都起来了，但同时读写"共享存储"，导致数据损坏（常见如数据库轮询着的联机日志出错）。

Zookeeper 集群节点为什么要部署成奇数

zookeeper容错指的是：当宕掉几个zookeeper节点服务器之后，剩下的个数必须大于宕掉的个数，也就是剩下的节点服务数必须大于n/2，这样zookeeper集群才可以继续使用，无论奇偶数都可以选举leader。例如5台zookeeper节点机器最多宕掉2台，还可以继续使用，因为剩下3台大于5/2。至于为什么最好为奇数个节点？这样是为了以最大容错服务器个数的条件下，能节省资源。比如，最大容错为2的情况下，对应的zookeeper服务数，奇数为5，而偶数为6，也就是6个zookeeper服务的情况下最多能宕掉2个服务，所以从节约资源的角度看，没必要部署6（偶数）个zookeeper服务节点。

zookeeper集群有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。也就是说如果有2个zookeeper节点，那么只要有1个zookeeper节点死了，那么zookeeper服务就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；同理也可以多列举几个：2->0; 3->1; 4->1; 5->2; 6->2 就会发现一个规律，2n和2n-1的容忍度是一样的，都是n-1，所以为了更加高效，何必增加那一个不必要的zookeeper呢。所以说，根据以上可以得出结论：从资源节省的角度来考虑，zookeeper集群的节点最好要部署成奇数个！

zookeeper是如何解决"脑裂"问题的？

要解决Split-Brain脑裂的问题，一般有下面几种种方法：
Quorums (法定人数) 方式: 比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个lead，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的。这是zookeeper防止"脑裂"默认采用的方法。
采用Redundant communications (冗余通信)方式：集群中采用多种通信方式，防止一种通信方式失效导致集群中的节点无法通信。
Fencing (共享资源) 方式：比如能看到共享资源就表示在集群中，能够获得共享资源的锁的就是Leader，看不到共享资源的，就不在集群中。
仲裁机制方式。
启动磁盘锁定方式。
 要想避免zookeeper"脑裂"情况其实也很简单，在follower节点切换的时候不在检查到老的leader节点出现问题后马上切换，而是在休眠一段足够的时间，确保老的leader已经获知变更并且做了相关的shutdown清理工作了然后再注册成为master就能避免这类问题了，这个休眠时间一般定义为与zookeeper定义的超时时间就够了，但是这段时间内系统可能是不可用的，但是相对于数据不一致的后果来说还是值得的
PS：过半选举和集群服务个数为奇数其实就是为了避免脑裂问题。

四、一致性算法

上述的选举机制，以及集群保证数据的一致性，zk中采用的是ZAB协议，这个协议是Paxos算法的一个变种。一致性算法有Paxos算法、Raft算法和ZAB协议等。具体的算法讲解这里不再记录，推荐一个不错的视频:一致性算法