详解Zookeeper选取机制

1.软文推荐

2.软文推荐

3.软文推荐

Zookeeper 是一个分布式服务框架，主要是用来解决分布式应用中遇到的一些数据管理问题如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。我们可以简单把 Zookeeper 理解为分布式家庭的大管家，那么管家团队是如何选出Leader的呢？下面为大家详细讲解一下Zookeeper选取机制。

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

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

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

当选举机器过半的时候，已经选举出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发生故障选举时无法提供服务发现对一个大型应用来说可能是致命的。它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能）是个伟大的开源项目，很成熟

本文来源：www.lxlinux.net/6674.html，若引用不当，请联系修改。