一、Zookeeper简介
Zookeeper是一个开源的分布式应用程序协调服务器，为分布式系统提供一致性服务，通过采用基于paxos算法的ZAB协议完成。他提供的主要功能包括配置服务、域名服务（服务注册发现）、分布式同步、集群管理功能
1、 功能简介
配置服务：基于发布订阅的模式，维护应用的配置文件
域名服务：服务的注册和发现，维护服务和主机的映射关系
分布式同步：erver监听znode只有znode的值为它希望的值才做相应的操作，并该znode值为新值给下一个server处理
集群管理：感知节点的故障并修复，如果修复不了爆出故障点
2、 一致性要求
顺序一致性
原子性
可靠性
单一试图：所有客户端看到的node节点的数据时一样的
实时性：一段时间内是实时的
二、Zookeeper中的重要概念
1、 session
session指的是Zookeeper与客户端的会话，是一个长连接的会话，zk对外提供服务的默认端口号是2181。客户端启动时会先与zk服务器建立一个TCP的长连接。从第一次连接建立开始，客户端会话的生命周期也开始了，通过此长连接，客户端可以通过心跳检测来保持与服务器的有效会话，也能像zk服务器发送请求并接受响应，同时也能通过该长连接接受来自服务器的watcher时间通知。
session的sessionTimeOut值来设置一个客户端会话的超时时间。当服务器压力太大、网络故障或者客户端主动断开连接等导致连接断开时，只要在sessionTimeout规定的之内客户端能够重新连上zk集群中的任意一台服务器，那么值钱创建的会话依然有效。
2、 znode
zookeeper的文件系统采用属性层次化的目录结构，与Unix的文件系统非常相似，每个目录在Zookeeper中叫做一个znode，每个znode拥有一个唯有的路径表示，即名称，znode可以包含数据和子znode（临时节点不能有子znode）。znode中的数据可以有多个版本，所以查询某路径下的数据 的时候需要带上版本号。
客户端可以在znode上设置监视器watcher。
3、 watcher机制
zk通过watcher机制实现了发布订阅模式，zk提供了分布式数据的发布订阅功能，一个发布者能够同时让多个订阅者同时监听某一个主题的对象，当这个主题对象状态发生变化时，会通知所有的订阅者，使他们能够做出相应的处理。zk引入了watcher机制来事项这种分布式的通知功能。zk允许客户端向服务器注册一个watcher监听，当服务端的一些指定时间出发这个watcher，那么就会向客户端发送一个时间通知，而这个事件通知则是通过Tcp长连接的session完成的。
4、 ACL
acl全称为access control list 访问控制列表，用于控住资源的访问权限，是zk数据的安全保障，zk利用acl策略控制znode的访问全向，如节点数据的读写、节点创建、删除、读取子节点列表、设置节点权限。
在传统的文件系统中，acl分为两个维度：组与权限，一个属组可以包含多种权限，一个文件或者目录拥有了某个组的权限即拥有了组里所有的权限。文件或者子目录会默认继承其父目录的acl。
然而在zk中，znode的acl是没有继承关系的，每个znode的权限都是独立控制的，只有客户端满足znode设置的权限要求是，才能完成相应的操作。zk的acl分为三个维度：授权策略scheme、用户id、用户权限permission
三、Paxos算法
1、 算法简介
paxos算法是莱斯兰伯特1990年提出的一种基于消息传递的、具有高容错性的一致性算法。谷歌chubby（分布式锁服务）的作者说过，世界上只有一种一致性性算法那就是paxos，所有其他一致性算法都是paxos算法的不完整版，paxos算法式一种公认的晦涩难懂的算法，工程实现上具有很大的难度。比较知名的paxos工程实现有google chubby、ZAB、微信的phxpaxos等。
paxos算法主要用于解决分布式系统中如何就某个决议达成一致的问题。
2、 paxos与拜占庭将军问题
拜占庭将军问题是由paxos作者提出的点对点通信中的基本问题。该问题说明想要在一个存在消息丢失或者被篡改的不可靠信道上试图通过消息传递的方式达到一致性是不可能的。paxos算法的前提条件是不存在拜占庭将军问题，即信道是安全的可靠的，集群节点间传递的消息不会被篡改
一般情况下，分布式系统中各个节点之间采用的通信模式有两种：
内存共享：都把消息传给一个地方统一收集整理
消息传递：将军之间相互通信通过传信兵传递消息。
paxos是基于消息传递的通讯模型。
3、 算法描述
【1】三种角色
在paxos算法中存在三种角色，分别具有三种不同的行为。很多时候，一个应用可能同时充当着多种角色。
proposer：提议者
acceptor：提案的表决者，即是否accept该提案，只有半数以上的acceptor接受了某提案时，那么该提案者被认定为“选定”
learner：提案的学习者。当提案被选定时，其要执行提案的内容。
一个提案的表决者acceptor会存在多个，但在一个集群中，提议者也可能存在多个，不同的提议者会提出不同的提案，一致性算法则可以保证如下几点：
a ：没有填提出则不会有提案被选定
b ：每个提议者在提出提案时都会首先获取到一个具有全局唯一性的递增的提案编号N，即在整个集群中是唯一的编号N，然后将该编号赋予其要提出的提案。
c ：每个表决者在accept某个填后，会将该提案的编号N记录在本地，这样每个表决中中保存的已经被accept的提案中会存在一个编号最大的提案，其编号假设为maxN，每个表决者仅会accept编号大于自己本地maxN的提案。
d ：在众多的提案中最终只能有一个提案被选定。
f ：一旦一个提案选定，则其他服务器会主动同步learn该提案到本地。
【2】算法过程描述
paxos算法执行过程分为两个阶段：准备阶段prepare、接受阶段accept
A、prepare
1） 提议者准备提交一个编号为N的提议，于是其首先向所有的表决者发送prepare（N）请求，用于试探集群是否支持该编号的提议
2）每个表决者中毒保存着自己曾经accept过的提议中的最大编号maxN。当一个表决者接受到其他主机发送来的prepare（N）请求时，其会比较N与maxN的值，有如下几种情况：
N < maxN, 则说明该提案已经过时，当前表决者采取不回应或者回应error的方式来拒绝该prepare请求
N > maxN, 说明该提案时可以接受的，当前表决者会先将N记录下来，并将其曾经accept的编码最大的天proposal（myid，maxN，value）反馈给提议者，表示自己支持该提案。其中myid表示表决者acceptor的标识id，maxN表示曾经接受过的最大提案的编号，value表示该提案的内容，如果该表决者曾经未曾接受过任何提案，则会将proposal（myid，null，null）反馈给提案者。
N不可能等于maxN，这是由N的生成机制决定的，要获取N的值，必须在原来的值的基础上采用同步锁的方式+1.
B、accept阶段
1）当提议者发出prepare（N）请求后，若收到超过半数的表决者accept的反馈，那么该提议者就会将真正的提案proposal（N，Value）发送给所有的表决者
2）当表决者accept接收到提案者发送的proposal（N，value）提案后，会再次拿出自己曾经accept过的提案中的最大编码maxN，及其曾经记录下的prepare的最大编码，对N和maxN、prepareN进行比较，若N大于等于这两个编号，则当前表决者accept该提案，并反馈给提案者，若N小于这两个编号，则表决者采取不回应或者回应error的方式来拒绝该proposal请求。
3）若提议者没有收到超过半数的表决者的accept反馈，则重新进入prepare阶段，递增提案号N，重新提出prepare请求。若提议者收到的accept反馈数量超过半数，则会向外广播两类消息：
a）向曾accept其提案的表决者发送“可执行数据同步信号”，让他们执行其曾接收到的提案。
b）向未曾向其发送accept反馈的表决者发送“提案+可执行数据同步信号”，让他们接收到该提案后马上执行。
【3】 paxos算法的活锁问题
前面所述的paxos算法在实际工程应用过程中，根据不同的实际需求存在诸多不便之处，所以也就出现了许多对于基本paxos算法的优化算法，以对paxos算法进行改进，例如：multi paxos、fast paxos、epaxos。
什么是活锁问题？生成提案编号N 的时候存在的同步锁会影响提案的效率。获取N是排他的，N成为了竞争资源，如果一个进程为了提交提案，一致在不停的申请资源N，但是每一次都没有分配给他，那么该进程就处于活锁的状态。
例如，对于paxos算法存在的活锁问题，fast paxos算法对其做了如下改进：只允许一个进程处理写请求，即只允许一个进程发起提案，因此只有一个进程对N进行操作，因此解决了活锁问题。
死锁：进程处于阻塞状态；
活锁：进程处于允许或者就绪状态；
四、ZAB协议
1、 ZAB协议简介
ZAB协议是fast paxos算法的一种工业算法实现。
ZAB， Zookeeper atomic broadcast，zk原子消息广播协议，是专门为zk设计的一种支持崩溃恢复的原子广播协议，在zk中主要依赖ZAB协议来实现分布式数据的一致性。
ZK使用一个主server来接收兵处理客户端的所有事物请求（写请求、提案）、当服务器数据的状态发生变更后，集群采用ZAB原子广播协议，以事务提案proposal的形式广播到其他副server上，ZAB协议能够保证一个全局的变更序列，即为每一个事务分配一个全局的递增的编号xid。
当zk客户端连接到zk集群中任意一个zk server节点后，若客户端提交的是读请求，那么当前节点直接从自己保存的数据中获取数据并响应客户端请求；如果当前client提交的是写请求，并且该server节点不是leader节点，那么将该写请求转发给leader，leader会以提案广播的方式将该写请求给follower，只有超过半数的follower节点同意该写操作，该写操作请求才会在leader节点被提交生效，然后leader会再次广播给所有订阅者observer，通知他们同步数据。
总结：读直接读，写转给leader，leader开启事务，半数通过才提交，提交完后广播的形式告诉所有observer同步数据。
2、 三种角色
为了避免zk中的单点问题，zk也是以集群的形式出现的。zk集群中的主要角色包括以下三类：
leader ： zk集群中写请求的唯一处理者，负责进行投票的发起和决议，更新系统状态，leader不是说收到写请求后立马提交修改数据，而是先生成一个提案，让follower进行投票，只有半数同意修改才进行提交修改。
follower ：接收客户端读写请求，处理读请求，写请求转给leader，在选leader和提案表决时进行投票。
observer ：接收客户端读写请求，处理读请求，写请求转给leader，不参与投票；之所以不参与投票是为了提交投票的效率，因为follower数量越少提案表决越快，同时能够负载读请求，协助follower处理更多的读请求。
这三类角色在不同的情况下又有一些不同的叫法：
learner：学习者，要从leader中同步数据的server，在集群处于正常服务状态时，follower与observer相对于leader都是learner。
quorum server：法定服务器，即具有投票权的主机，不包括observer，故障时从中选出一台作为新的leader，其他成为follower。
ZAB广播必须保证所有的follower都收到且成功，数据在更新过程中zookeeper集群是不对外提供服务的
增加follower会增加投票选项的延时，因此通过增加observe来协助follower处理读请求。
3、 三种模式
ZAB协议中对zkserver的状态描述有三种模式：恢复模式、广播模式、同步模式。这三种模式并没有十分明显的分界线，相互交织在一起。
恢复模式：在服务重启过程中，或者在leader崩溃后，就进入到恢复模式，恢复模式主要包含两个阶段：leader选举阶段和初始化同步阶段。这两个阶段完成后zk集群恢复到正常的服务状态。
广播模式：广播模式分为两类，初始化广播与更新广播，当leader被选举出来后，leader需要将自己拥有但其他server可能没有的事务及自己的epoch广播给所有的learner，这就是初始化广播。在集群正常服务时，当leader的事务被大多数的follower同意后，leader会修改自身数据，然后将修改后的数据广播给其他的learner，这就是更新广播。
同步模式：与广播模式向对应，同步模式也分为两类，初始化同步和更新同步，当leader选举出来并发布过其初始化广播后，所有的learner需要将leader广播的事务及epoch同步到本地，这成为初始化同步。在集群正常服务时，当leader发布了更新广播后，learner需要将leader广播的事务同步到本地，这成为更新同步。
4、 三个数据
在zk中有三个重要的数据：zxid、epoch和xid。
zxid是写消息事务的唯一标识N
zxid是64位长度的long类型，其中高32表示纪元epoch，低32位表示事务表示xid；即zxid由两部分组成epoch和xid。
每个leader都会具有一个不同的epoch值，表示一个时期、时代。每一次新的选举开启时都会生成一个新的epoch，新的leader产生，则会更新所有zkserver的zxid中的epoch。
5、 同步模式和广播模式
【1】初始化同步
当完成leader选举后，就要进入到恢复模式下的初始化同步阶段。leader服务器会给每一个follower准备一个队列，并将哪些没有被各个follower服务器同步的事务以proposal的形式发给各个follower，并在每一个proposal后面都紧跟一个commit消息，表示该事务已经被提交，follower可以直接接收并执行。当follower将所有未同步的事务proposal都从leader服务器同步过来并执行成功后，回想准leader发送ack消息。leader收到ack后就会将该follower加入到真正可用的follower列表中。
【2】消息广播算法
当集群中有半数以上的learner完成了初始化状态同步后，那么整个zk集群就可以进入消息广播模式了。
如果集群中的其他节点收到客户端的事务请求，这些learner会先将这个事务请求转发给leader服务器。leader服务器为其生成提案proposal，并将proposal发送给所有的follower，收集他们的选票，在选票超过半数后进行事务提交。具体过程如下：
a） leader收到写消息，将给写消息赋予一个全局唯一的64位自增id即zxid，通过zxid的大小比较即可实现事务的有序性管理。
b）为了保证leader向follower发送的提案proposal有序，leader会为每个follower创建一个FIFO队列，并将提案副本写入到各个队列，然后在通过队列将提案发送给各个follower。
c）当follower收到提案后，会先比较提案的zxid和本地记录的事务日志中最大的zxid大小。若收到的提案大于等于maxzxid，则将当前提案记录到本地事务日志中并向leader发送一个ack返回。
d）当leader收到过半的acks后，leader会向所有的follower发送commit消息，批准各个follower在本地执行该proposal消息。当follower收到commit消息后就会执行该消息。
【3】恢复模式的两个原则
主要针对两类问题：prepare阶段leader挂了–要保证此被丢弃的消息不能再现，commit阶段leader挂了—要保证已被处理的消息不能丢失。因为commit的阶段是所有follower投票通过的。
a）已被处理过的消息不能丢失
当leader收到超过半数的follower的acks后，就会向所有的follower广播commit消息，批准各个server执行写操作失误，当各个server在接收到leader的commit消息后就会在本地执行写操作，然后向客户端响应写操作成功。
如果在非全部的follower收到commit消息之前leader就挂了，这将导致部分server已经执行了该事务，部分server未执行该事务，当心的leader被选举出来后，集群经过恢复模式后需要保证所有的server上都执行了哪些已经被部分server执行过的事务。也就是选举出来的leader必须在执行过该事务的follower中选出，它成为新的leader后通过初始化同步让为执行之前事务的server继续执行之前的事务。
b）被丢弃的消息不能再现
当leader接收到事务请求并生成了proposal，但还未向follower发送时就挂了，由于其他follower并没有收到该proposal，即并不知道该proposal的存在，因此在经过恢复模式重新选举出新的leader后，该写事务被跳过。在整个集群尚未进入正常服务状态时。之前挂了的leader重新启动并注册成follower，但是由于它保留了被跳过的proposal，所以其与整个系统的状态不一致，需要将该proposal删除。。
那么如何能够将其删除呢？根据epoch的生成规则，当新的leader选举出来后，它的epoch一定大于当前集群中任何server中记录事务的zxid值，因为epoch是zxid中的高32位值加1后的值。leader会将它的epoch广播给所有的learner，并且将所有的learner中所有旧的未被commit的proposal清除。
五、leader选举机制
ZAB协议是专门为zookeeper设计的一种支持崩溃恢复的原子广播协议，那么什么是zookeeper的奔溃呢？就是在zk集群中leader宕机后的重新选举过程，当然，在集群启动过程中也需要leader选举。
当集群正在启动过程中，或leader与超过半数的主机断连后，集群就进入新的恢复模式，而恢复模式中最重要的阶段就是leader选举。
1、leader选举中的基本概念
【1】myid
这是zk集群中服务器的唯一表示，称为myid，例如有3个zk服务器，那么编号分别是1，2，3；在zoo.cfg配置中dataDir目录下需要配置myid文件，里面配置该zkServer的表示。
【2】逻辑时钟
逻辑时钟，logiclock，是一个整型数，在选举的时候称为logiclock，在选举结束后叫epoch纪元，是zxid中的高32位。因此epoch和logiclock是同一个值，只是在不同情况下的不同名称。
【3】zk状态
zk集群中的每一台主机，在不同的阶段处于不同的状态，每一台主机具有四种状态
Looking 选举状态，即查找leader的状态
Following，跟随状态，同步leader状态，处于该状态的服务器称为follower
Observing，观察状态，同步leader状态，处于该状态的服务器称为observer
leadding，领导状态，leader
2、leader选举算法
在集群启动过程中的leader选举算法与leader断联后的leader算法稍微有一些区别
【1】集群启动中的leader选举
若进行leader选举，则至少需要两台主机，这里以三台主机组成的集群为例。
在集群初始化阶段，当第一台server1启动时，会给自己投票，然后广播发布自己的投票结果，投票结果包含推举的服务器的myid和zxid，使用（myid，zxid）表示，此时server1的投票结果为（1，0），由于其他服务器还没有启动server1收不到别人的反馈信息，server1的状态一直处于looking状态，即非服务状态。
当第二台server2启动时，server1和server2可以相互通信，每台机器都试图找到leader，选举过程如下：
每个server发出一个投票，此时server1的投票为（1，0），server2的投票为（2，0），然后将各自的投票广播发给集群中其他服务器。
接受来自其他服务器的投票，集群中每个服务器收到他人的投票后，先判断投票的有效性，即判断投票是否来自looking状态的服务器，是才进行投票pk比较，否则直接更新自己本地的zxid。
pk是将别人的投票和自己的投票比较，优先检查zxid，zxid大的作为leader，zxid一样则比较myid，myid大的作为leader。
因此对于server1，他的投票是（1，0）收到server2的投票（2，0）后zxid一样，server2的myid大，则server1更新它自己的投票为（2，0）并再次广播出去，server2收到（2，0）投票后判断出超过半数选择server2作为leader，则server2变成leader。
改变服务器状态，一旦确定了leader，每个服务器会更新自己的状态，如果是follower，则状态给为following，leader改为leading。
添加主机，在新的leader选举出来后，server3启动，其想发新一轮的选举，但是集群中各个主机的状态不是looking，而是各司其职正常服务，则server3只能以follower的身份加入集群中。
【2】断连后的leader选举
在zookeeper运行期间，leader与非leader服务器各司其职，即便当非leader服务器宕机或者新的机器加入时，不会影响leader，但是leader如果挂了，那么整个集群将暂停对外服务，进入新一轮的leader选举，其过程和启动时间的leader选举基本一致，选举过程大概30s到60s。
假设正在运行的服务器有server1，server2，server3，server2是leader，若某一时刻leader2挂了，此时开始新一轮选举，过程如下：
先变更状态，follower将自己的状态从following改为looking，然后进入选举过程。
每个服务器发一个投票，仍然先投自己。不过每个server的zxid可能是不同的。
与启动过程一样，先检查投票的有效性，如判断选票的轮次，选票是否来自looking状态的服务器。
投票处理，与启动一样，同样的方法进行pk。
统计投票，与气动一样，如果半数以上的投票选择了同一个server，则该server成为新的leader，即server3.
改变服务器的状态，与启动一样，更改各服务器的状态。
六、CAP原则
1、 CAP简介
CAP定理指在一个分布式系统中，一致性、可用性、分区容错性三者不可兼得。
C （consistency）：一致性，指的是写操作后的读操作必须返回写操作的值。
A （availablity）：可用性，可用性指的是数据能否及时响应返回，而不是指的系统可用。即服务器收到请求后必须给出返回不论对错。
P（partition）：分区容错性，分区容错性是一个分布式系统的基本能力，指的是区间通信可能失败，例如一台服务器在北京，一台在上海可能网络通信失败。尽管网络或者消息失败，系统依然按照预期的进行执行。一台主机可以称为一个分区，分区容错性指分布式系统应该包容不一致性和非实时可用性。
2、 三二原则
对于分布式系统，在CAP原则中的分区容错性P是必须保证的，但不能同时保证一致性和可用性，一致性和可用性二者不可兼得，对于分布式系统要么满足AP要么满足CP，这就是CAP的二三原则。
3、 ZK与CP
ZK遵循的是CP原则，即保证了一致性但是牺牲了可用性。体现在哪里呢？
当leader宕机后，zk几圈会马上进行新的leader选举，但选举时长在30-120秒之间，整个选举期间zk集群是不接受客户端的读写操作的，即zk集群在这段时间内是处于瘫痪状态的。所以其不满足可用性。
为什么leader选举要这么长时间呢？为了保证zk集群各个节点中数据的一致性，zk做了两类数据同步：初始化同步和更新同步；当新的leader被选举出来后，各个follower需要将新leader的数据同步到自己本地，者就是初始化同步；当leader的数据被客户端修改后，其会向所有的follower广播，然后follower主动同步leader更新的数据，者是更新同步。无论是初始化或者更新同步，zk集群为了保证数据的一致性，若发现超过半数的follower同步超时，再回再次进行通过不，这整个过程中zk对外是处于不可用状态的。
由于zk采用了cp原则，导致其可用性降低，这是其只要的问题，因此spring cloud的eureka采用了ap原则，在分布式系统中的作用类似于zk，牺牲了一致性但是保证了可用性。
什么是服务降级？关闭一些非核心的功能，保证核心的服务不受影响，如双11期间不能修改收货地址、查看历史订单
七、回答如下几个问题
1、Zookeeper是什么？
zk是分布式协调服务器，主要是保证分布式环境下事务的一致性。它能保证同一个时刻不同的client从zk集群获取的数据都是一致性的。
2、Zookeeper用来解决什么问题？什么场景下需要会用到Zookeeper？有没有什么替代产品？
解决分布式环境下事务的一致性，配置管理、域名服务（服务注册发现）、分布式同步、集群管理（故障恢复）
替代产品：Spring cloud eureka
3、Zookeeper是怎么保证数据的一致性的？
基于fast paxos实现的ZAB协议，即zk 的原子广播协议实现，zab协议包括三种角色leader、follower、observer；只有一个leader，它能发起提案处理写操作，收集投票结果；follower可以进行投票，不能处理写操作，写操作需要转发给leader处理；observer只能处理读请求，写请求也需要转发给leader，同时也不参与投票。包括3中模式，故障恢复模式（选leader+初始化同步），消息广播模式（初始化广播+更新广播），数据同步模式（初始化同步+更新同步）
4、为什么分布式锁可以用zk实现？
因为只有一个leader可以生成proposal
5、为什么要加observer不能直接加follower？
因为直接增加follower会增加选举和投票的时长，但是为了提高集群读的能力，因此通过增加observer来实现读负载能力的提升。
6、假死和脑裂问题？
脑裂是指处于不同网络分区中的机器之间连接出现问题，例如华东集群的服务器和华北集群的服务器之间网络连接出现故障，但是华东和华北内部之间的服务器网络通信没有问题，假如leader之前在华北，华东网络会重新选举出一个新的leader，应此可能存在两个leader，即出现脑裂。
要解决Split-Brain的问题，一般有3种方式:
Quorums（ˈkwôrəm 法定人数） ：比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个lead，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的
Redundant communications：冗余通信的方式，集群中采用多种通信方式，防止一种通信方式失效导致集群中的节点无法通信。
Fencing, 共享资源的方式：比如能看到共享资源就表示在集群中，能够获得共享资源的锁的就是Leader，看不到共享资源的，就不在集群中。
ZooKeeper默认采用了Quorums这种方式，即只有集群中超过半数节点投票才能选举出Leader。这样的方式可以确保leader的唯一性,要么选出唯一的一个leader,要么选举失败
现脑裂。
要解决Split-Brain的问题，一般有3种方式:
Quorums（ˈkwôrəm 法定人数） ：比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个lead，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的
Redundant communications：冗余通信的方式，集群中采用多种通信方式，防止一种通信方式失效导致集群中的节点无法通信。
Fencing, 共享资源的方式：比如能看到共享资源就表示在集群中，能够获得共享资源的锁的就是Leader，看不到共享资源的，就不在集群中。
ZooKeeper默认采用了Quorums这种方式，即只有集群中超过半数节点投票才能选举出Leader。这样的方式可以确保leader的唯一性,要么选出唯一的一个leader,要么选举失败