Zookeeper leader选举机制

在Zookeeper中，分为两种选举情况，一种是初始化集群分布式的时候会进行leader选举，另外一种是在运行期间leader出现故障会进行选举，所以一般Zookeeper的服务器机器数量都会选择为奇数。在分布式CAP理论中，zookeeper属于一个CP系统，即一致性、分区容错性，它保证了集群数据的一致性，但适当舍弃了一些高可用。

zookeeper节点的4种状态:

      LEADING：说明此节点已经是leader节点，处于领导者地位的状态，差不多就是一般集群中的master。但在zookeeper中，只有leader才有写权限，其他节点（FOLLOWING）是没有写权限的，可以读

      LOOKING：选举中，正在寻找leader，即将进入leader选举流程中

      FOLLOWING：跟随者，表示当前集群中的leader已经选举出来了，主要具备以下几个功能点             

                向leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）

                接收leader消息并进行处理；

                接收client发送过来的请求，如果为写请求，会发送给Leader进行投票处理，然后返回client结果。

      OBSERVING：OBSERVING和FOLLOWING差不多，但不参加投票和选举，接受leader选举后的结果

选举过程:

假如有以下5台机器server1、server2、server3、server4、server5    图是网上扒的

每个server 自身都有一票，在初始化或者server崩溃数过半的时候，每个server都有一个自身的myid(zookeeper配置文件)，这里按1、2、3、4、5算

在选举过程中主要是依据zxid和myid来进行轮训server然后比较统计投票

zxid (ZooKeeper Transaction Id，每次请求对应一个唯一的zxid，如果zxid a < zxid b ，则可以保证a一定发生在b之前)。

选举分为两种情况，初始化和leader挂掉的时候，要进行leader选举，至少需要2台机器，集群机器台数基本是奇数

初始化

当启动初始化集群的时候，server1的myid为1，zxid为0   server2的myid为2，zxid同样是0，以此类推。此种情况下zxid都是为0。先比较zxid，再比较myid

• 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
• 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的myid大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
• 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的myid最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
• 服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的myid大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
• 服务器5启动，后面的逻辑同服务器4成为小弟

当选举机器过半的时候，已经选举出leader后，后面的就跟随已经选出的leader，所以4和5跟随成为leader的server3

所以，在初始化的时候，一般到过半的机器数的时候谁的myid最大一般就是leader

运行期间

按照上述初始化的情况，server3成为了leader，在运行期间处于leader的server3挂了，那么非Observer服务器server1、server2、server4、server5会将自己的节点状态变为LOOKING状态

1、开始进行leader选举。现在选举同样是根据myid和zxid来进行

2、首先每个server都会给自己投一票竞选leader。假设server1的zxid为123，server2的zxid为124，server4的zxid为169，server5的zxid为188

3、同样先是比较zxid再比较，server1、server2、server4比较server4根据优先条件选举为leader。然后server5还是跟随server4，即使server5的zxid最大，但是当选举到server4的时候，机器数已经过半。不再进行选举，跟随已经选举的leader

 

zookeeper集群为保证数据的一致性所有的操作都是由leader完成，之后再由leader同步给follower。重点就在这儿，zookeeper并不会确保所有节点都同步完数据，只要有大多数节点（即n/2+1）同步成功即可。

咱们假设有一个写操作成功那么现在数据只存在于节点leader，之后leader再同步给其他follower。这时候宕掉3个机器，已经过半的机器无法进行投票选举，剩余2台不足过半，无法选举=无法提供任何服务。再启动一个机器恢复服务。所以宕掉的机器不要过半，过半就会导致无法正常服务。

在leader选举的时候会有30s-120s的过程，在这期间也是无法提供服务的。如果用zookeeper要作为服务发现是个弊端，基本无法忍受，zookeeper本身是一个CP系统，保证数据的一致性，在恢复的时候再提供服务，并没有多好高可用的方案。如果leader发生故障选举时无法提供服务发现对一个大型应用来说可能是致命的。它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能）是个伟大的开源项目，很成熟