Zookeeper—Zookeeper是什么
博客借鉴http://www.cnblogs.com/yuyijq/p/3391945.html
Google的三篇论文影响了很多很多人，也影响了很多很多系统。这三 篇论文一直是分布式领域传阅的经典。根据MapReduce，于是我们有了Hadoop；根据GFS，于是我们有了HDFS；根据BigTable，于是 我们有了HBase。而在这三篇论文里都提及Google的一个lock service—Chubby，哦，于是我们有了Zookeeper。
随着大数据的火热，Hxx们已经变得耳熟能详，现在作为一个开发人员如果都不知道这几个名词出门都好像不好意思跟人打招呼。但实际上对我们这些非大 数据开发人员而言，Zookeeper是比Hxx们可能接触到更多的一个基础服务。但是，无奈的是它一直默默的位于二线，从来没有Hxx们那么耀眼。
那么 到底什么是Zookeeper呢？Zookeeper可以用来干什么？我们将如何使用Zookeeper？Zookeeper又是怎么实现的？
伴随着Zookeeper有两篇论文：一篇是Zab，就是介绍Zookeeper背后使用的一致性协议的(Zookeeper atomic broadcast protocol)，还有一篇就是介绍Zookeeper本身的。在这两篇论文里都提到Zookeeper是一个分布式协调服务(a service for coordinating processes of distributed applications)。那分布式协调服务又是个什么东西呢？首先我们来看“协调”是什么意思。
说到协调，我首先想到的是北京很多十字路口的交通协管，他们手握着小红旗，指挥车辆和行人是不是可以通行。如果我们把车辆和行人比喻成运行在计算机 中的单元(线程)，那么这个协管是干什么的？很多人都会想到，这不就是锁么？对，在一个并发的环境里，我们为了避免多个运行单元对共享数据同时进行修改， 造成数据损坏的情况出现，我们就必须依赖像锁这样的协调机制，让有的线程可以先操作这些资源，然后其他线程等待。对于进程内的锁来讲，我们使用的各种语言 平台都已经给我们准备很多种选择。
就拿Java来说，有最普通不过的同步方法或同步块：
public synchronized void sharedMethod(){ //对共享数据进行操作}
使用了这种方式后，多个线程对sharedMethod进行操作的时候，就会协调好步骤，不会对sharedMethod里的资源进行破坏，产生不 一致的情况。这个最简单的协调方法，但有的时候我们可能需要更复杂的协调。比如我们常常为了提高性能，我们使用读写锁。因为大部分时候我们对资源是读取多 而修改少，而如果不管三七二十一全部使用排他的写锁，那么性能有可能就会受到影响。还是用java举例：
public class SharedSource{
private ReadWriteLock rwlock = new ReentrantReadWriteLock();
private Lock rlock = rwlock.readLock(); private Lock wlock =
rwlock.writeLock();
public void read(){
rlock.lock(); try{ //读取资源 }finally{ rlock.unlock(); } }
public void write(){
wlock.lock();
try{ //写资源 }
finally{
wlock.unlock(); }
}
}
我们在进程内还有各种各样的协调机制(一般我们称之为同步机制)。现在我们大概了解了什么是协调了，但是上面介绍的协调都是在进程内进行协调。在进 程内进行协调我们可以使用语言，平台，操作系统等为我们提供的机制。那么如果我们在一个分布式环境中呢？也就是我们的程序运行在不同的机器上，这些机器可 能位于同一个机架，同一个机房又或不同的数据中心。在这样的环境中，我们要实现协调该怎么办？那么这就是分布式协调服务要干的事情。
ok，可能有人会讲，这个好像也不难。无非是将原来在同一个进程内的一些原语通过网络实现在分布式环境中。是的，表面上是可以这么说。但分布式系统中，说往往比做容易得多。在分布式系统中，所有同一个进程内的任何假设都不存在：因为网络是不可靠的。
比如，在同一个进程内，你对一个方法的调用如果成功，那就是成功(当然，如果你的代码有bug那就另说了)，如果调用失败，比如抛出异常那就是调用 失败。在同一个进程内，如果这个方法先调用先执行，那就是先执行。
但是在分布式环境中呢？ 由于网络的不可靠，你对一个服务的调用失败了并不表示一定是失败的，可能是执行成功了，但是响应返回的时候失败了。
还有，A和B都去调用C服务，在时间上 A还先调用一些，B后调用，那么最后的结果是不是一定A的请求就先于B到达呢？
这些本来在同一个进程内的种种假设我们都要重新思考，我们还要思考这些问题给我们的设计和编码带来了哪些影响。还有，在分布式环境中为了提升可靠性，我们 往往会部署多套服务，但是如何在多套服务中达到一致性，这在同一个进程内很容易解决的问题，但在分布式环境中确实一个大难题。
所以分布式协调远远比同一个进程里的协调复杂得多，所以类似Zookeeper这类基础服务就应运而生。这些系统都在各个系统久经考验，它的可靠 性，可用性都是经过理论和实践的验证的。所以我们在构建一些分布式系统的时候，就可以以这类系统为起点来构建我们的系统，这将节省不少成本，而且bug也 将更少。
本篇文章试图从外围介绍一下Zookeeper是一个什么样子的服务和我们为什么需要这样一种服务。在后面的文章中会介绍Zookeeper到底能干些什么
Zookeeper–Zookeeper可以干什么
在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要 这样的服务？
我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统 中使用了。
配置管理
在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。但是当我们只有 一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动 态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得 变更。比如我们可以把配置放在数据库里，然后所有需要配置的服务都去这个数据库读取配置。但是，因为很多服务的正常运行都非常依赖这个配置，所以需要这个 集中提供配置服务的服务具备很高的可靠性。一般我们可以用一个集群来提供这个配置服务，但是用集群提升可靠性，那如何保证配置在集群中的一致性呢？ 这个时候就需要使用一种实现了一致性协议的服务了。Zookeeper就是这种服务，它使用Zab这种一致性协议来提供一致性。现在有很多开源项目使用 Zookeeper来维护配置，比如在HBase中，客户端就是连接一个Zookeeper，获得必要的HBase集群的配置信息，然后才可以进一步操 作。还有在开源的消息队列Kafka中，也使用Zookeeper来维护broker的信息。在Alibaba开源的SOA框架Dubbo中也广泛的使用 Zookeeper管理一些配置来实现服务治理。
名字服务
名字服务这个就很好理解了。比如为了通过网络访问一个系统，我们得知道对方的IP地址，但是IP地址对人非常不友好，这个时候我们就需要使用域名来 访问。但是计算机是不能是别域名的。怎么办呢？如果我们每台机器里都备有一份域名到IP地址的映射，这个倒是能解决一部分问题，但是如果域名对应的IP发 生变化了又该怎么办呢？于是我们有了DNS这个东西。我们只需要访问一个大家熟知的(known)的点，它就会告诉你这个域名对应的IP是什么。在我们的 应用中也会存在很多这类问题，特别是在我们的服务特别多的时候，如果我们在本地保存服务的地址的时候将非常不方便，但是如果我们只需要访问一个大家都熟知 的访问点，这里提供统一的入口，那么维护起来将方便得多了。
分布式锁
其实在第一篇文章中已经介绍了Zookeeper是一个分布式协调服务。这样我们就可以利用Zookeeper来协调多个分布式进程之间的活动。比 如在一个分布式环境中，为了提高可靠性，我们的集群的每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要 协调，编程起来将非常复杂。而如果我们只让一个服务进行操作，那又存在单点。通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服 务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。比如HBase的Master就是采用这种机制。但要注意的是分布式锁跟同一个进程的锁还是有区别的，所以使用的 时候要比同一个进程里的锁更谨慎的使用。
集群管理
在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个 时候，集群中其他机器需要感知到这种变化，然后根据这种变化做出对应的决策。比如我们是一个分布式存储系统，有一个中央控制节点负责存储的分配，当有新的 存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候我们就需要动态感知到集群目前的状态。还有，比如一个分布式的SOA架构中，服务是 一个集群提供的，当消费者访问某个服务时，就需要采用某种机制发现现在有哪些节点可以提供该服务(这也称之为服务发现，比如Alibaba开源的SOA框 架Dubbo就采用了Zookeeper作为服务发现的底层机制)。还有开源的Kafka队列就采用了Zookeeper作为Cosnumer的上下线管 理。
后记
在这篇文章中，列出了一些Zookeeper可以提供的服务，并给出了一些开源系统里面的实例。后面我们从Zookeeper的安装配置开始，并用示例进一步介绍Zookeeper如何使用。
Zookeeper–Zookeeper的配置
前面两篇文章介绍了Zookeeper是什么和可以干什么，那么接下来 我们就实际的接触一下Zookeeper这个东西，看看具体如何使用，有个大体的感受，后面再描述某些地方的时候也能在大脑中有具体的印象。本文只关注分 布式模式的zookeeper，因为这也是在生产环境的唯一部署方式，单机的zookeeper可以在测试和开发环境使用，但是单机环境的zookeeper就不再是zookeeper了。
安装配置很简单，官网也有介绍，这里就只对后面的文章有提到的点说明下。
配置-zoo.cfg
这是zookeeper的主要配置文件，因为Zookeeper是一个集群服务，集群的每个节点都需要这个配置文件。为了避免出差 错，zoo.cfg这个配置文件里没有跟特定节点相关的配置，所以每个节点上的这个zoo.cfg都是一模一样的配置。这样就非常便于管理了，比如我们可 以把这个文件提交到版本控制里管理起来。其实这给我们设计集群系统的时候也是个提示：集群系统一般有很多配置，应该尽量将通用的配置和特定每个服务的配置 (比如服务标识)分离，这样通用的配置在不同服务之间copy就ok了。ok，下面来介绍一些配置点：
clientPort=2181
client port，顾名思义，就是客户端连接zookeeper服务的端口。这是一个TCP port。
dataDir=/data
dataLogDir=/datalog
dataLogDir如果没提供的话使用的则是dataDir。zookeeper的持久化都存储在这两个目录里。dataLogDir里是放到的 顺序日志(WAL)。而dataDir里放的是内存数据结构的snapshot，便于快速恢复。为了达到性能最大化，一般建议把dataDir和 dataLogDir分到不同的磁盘上，这样就可以充分利用磁盘顺序写的特性。
下面是集群中服务的列表
server.1=127.0.0.1:20881:30881server.2=127.0.0.1:20882:30882server.3=127.0.0.1:20883:30883
在上面的例子中，我把三个zookeeper服务放到同一台机器上。上面的配置中有两个TCP port。后面一个是用于Zookeeper选举用的，而前一个是Leader和Follower或Observer交换数据使用的。我们还注意到 server.后面的数字。这个就是myid(关于myid是什么下一节会介绍)。
上面这几个是一些基本配置。
还有像 tickTime，这是个时间单位定量。比如tickTime=1000，这就表示在zookeeper里1 tick表示1000 ms，所有其他用到时间的地方都会用多少tick来表示。
比如 syncLimit = 2 就表示fowller与leader的心跳时间是2 tick。
maxClientCnxns — 对于一个客户端的连接数限制，默认是60，这在大部分时候是足够了。但是在我们实际使用中发现，在测试环境经常超过这个数，经过调查发现有的团队将几十个应用全部部署到一台机器上，以方便测试，于是这个数字就超过了。
minSessionTimeout, maxSessionTimeout — 一般，客户端连接zookeeper的时候，都会设置一个session timeout，如果超过这个时间client没有与zookeeper server有联系，则这个session会被设置为过期(如果这个session上有临时节点，则会被全部删除，这就是实现集群感知的基础，后面的文章 会介绍这一点)。但是这个时间不是客户端可以无限制设置的，服务器可以设置这两个参数来限制客户端设置的范围。
autopurge.snapRetainCount，autopurge.purgeInterval — 客户端在与zookeeper交互过程中会产生非常多的日志，而且zookeeper也会将内存中的数据作为snapshot保存下来，这些数据是不会被 自动删除的，这样磁盘中这样的数据就会越来越多。不过可以通过这两个参数来设置，让zookeeper自动删除数据。 autopurge.purgeInterval就是设置多少小时清理一次。而autopurge.snapRetainCount是设置保留多少个 snapshot，之前的则删除。
不过如果你的集群是一个非常繁忙的集群，然后又碰上这个删除操作，可能会影响zookeeper集群的性能，所以一般会让这个过程在访问低谷的时候 进行，但是遗憾的是zookeeper并没有设置在哪个时间点运行的设置，所以有的时候我们会禁用这个自动删除的功能，而在服务器上配置一个cron，然 后在凌晨来干这件事。
以上就是zoo.cfg里的一些配置了。下面就来介绍myid。
配置-myid
在dataDir里会放置一个myid文件，里面就一个数字，用来唯一标识这个服务。这个id是很重要的，一定要保证整个集群中唯一。 zookeeper会根据这个id来取出server.x上的配置。比如当前id为1，则对应着zoo.cfg里的server.1的配置。
- 而且在后面我们介绍leader选举的时候，这个id的大小也是有意义的。
OK，上面就是配置的讲解了，现在我们可以启动zookeeper集群了。进入到bin目录，执行 ./zkServer.sh start即可。
Zookeeper–Zookeeper启动过程
在上一篇，我们了解了zookeeper最基本的配置，也从中了解一些配置的作用，那么这篇文章中，我们将介绍Zookeeper的启动过程，我们在了解启动过程的时候还要回过头看看上一篇中各个配置参数在启动时的位置。
Zookeeper的启动入口在org.apache.zookeeper.server.quorum.QuorumPeerMain。
在这个类的main方法里进入了zookeeper的启动过程，首先我们会解析配置文件，即zoo.cfg和myid。
这样我们就知道了dataDir和dataLogDir指向哪儿了，然后就可以启动日志清理任务了(如果配置了的话)。
DatadirCleanupManager purgeMgr = new DatadirCleanupManager(config .getDataDir(), config.getDataLogDir(), config .getSnapRetainCount(), config.getPurgeInterval());purgeMgr.start();
接下来会初始化ServerCnxnFactory，这个是用来接收来自客户端的连接的，也就是这里启动的是一个tcp server。在Zookeeper里提供两种tcp server的实现，一个是使用java原生NIO的方式，另外一个是使用Netty。默认是java nio的方式，一个典型的Reactor模型。因为java nio编程并不是本文的重点，所以在这里就只是简单的介绍一下。
//首先根据配置创建对应factory的实例:NIOServerCnxnFactory 或者 NettyServerCnxnFactoryServerCnxnFactory cnxnFactory = ServerCnxnFactory.createFactory();//初始化配置cnxnFactory.configure(config.getClientPortAddress(),config.getMaxClientCnxns());
创建几个SelectorThread处理具体的数据读取和写出。
先是创建ServerSocketChannel，bind等
this.ss = ServerSocketChannel.open();ss.socket().setReuseAddress(true);ss.socket().bind(addr);ss.configureBlocking(false);
然后创建一个AcceptThread线程来接收客户端的连接。
这一部分就是处理客户端请求的模块了，如果遇到有客户端请求的问题可以看看这部分。
接下来就进入初始化的主要部分了，首先会创建一个QuorumPeer实例，这个类就是表示zookeeper集群中的一个节点。初始化QuorumPeer的时候有这么几个关键点： - 初始化FileTxnSnapLog，这个类主要管理Zookeeper中的操作日志(WAL)和snapshot。
- 初始化ZKDatabase，这个类就是Zookeeper的目录结构在内存中的表示，所有的操作最后都会映射到这个类上面来。
- 初始化决议validator(QuorumVerifier->QuorumMaj) (其实这一步，是在配置)。这一步是从zoo.cfg的server.n这一部分初始化出集群的成员出来，有哪些需要参与投票(follower)，有哪些只是observer。还有决定half是多少等，这些都是zookeeper的核心。在这一步，对于每个节点会初始化一个QuorumServer对象，并且放到allMembers，votingMembers，observingMembers这几个map里。而且这里也对参与者的个数进行了一些判断。
- leader选举 这一步非常重要，也是zookeeper里最复杂而最精华的一部分。
到这里，我们的zookeeper就启动完成了。后面我将会分三部分进一步深入理解zookeeper： - leader选举
- 存储
- 处理客户端请求
Zookeeper–Zookeeper leader选举
在上一篇文章中我们大致浏览了zookeeper的启动过程，并且提到 在Zookeeper的启动过程中leader选举是非常重要而且最复杂的一个环节。那么什么是leader选举呢？zookeeper为什么需要 leader选举呢？zookeeper的leader选举的过程又是什么样子的？本文的目的就是解决这三个问题。
首先我们来看看什么是leader选举。其实这个很好理解，leader选举就像总统选举一样，每人一票，获得多数票的人就当选为总统了。在 zookeeper集群中也是一样，每个节点都会投票，如果某个节点获得超过半数以上的节点的投票，则该节点就是leader节点了。
国家选举总统是为了选一个最高统帅，治理国家。那么zookeeper集群选举的目的又是什么呢？其实这个要清楚明白的解释还是挺复杂的。我们可以 简单点想这个问题：我们有一个zookeeper集群，有好几个节点。每个节点都可以接收请求，处理请求。那么，如果这个时候分别有两个客户端向两个节点 发起请求，请求的内容是修改同一个数据。比如客户端c1，请求节点n1，请求是set a = 1; 而客户端c2，请求节点n2，请求内容是set a = 2;
那么最后a是等于1还是等于2呢？ 这在一个分布式环境里是很难确定的。解决这个问题有很多办法，而zookeeper的办法是，我们选一个总统出来，所有的这类决策都提交给总统一个人决策，那之前的问题不就没有了么。
那我们现在的问题就是怎么来选择这个总统呢？ 在现实中，选择****总统是需要宣讲拉选票的，那么在zookeeper的世界里这又如何处理呢？我们还是show code吧。
在QuorumPeer的startLeaderElection方法里包含leader选举的逻辑。Zookeeper默认提供了4种选举方式，默认是第4种: FastLeaderElection。
我们先假设我们这是一个崭新的集群，崭新的集群的选举和之前运行过一段时间的选举是有稍许不同的，后面会提及。
节点状态： 每个集群中的节点都有一个状态 LOOKING, FOLLOWING, LEADING, OBSERVING。都属于这4种，每个节点启动的时候都是LOOKING状态，如果这个节点参与选举但最后不是leader，则状态是 FOLLOWING，如果不参与选举则是OBSERVING，leader的状态是LEADING。
开始这个选举算法前，每个节点都会在zoo.cfg上指定的监听端口启动监听(server.1=127.0.0.1:20881:20882)，这里的20882就是这里用于选举的端口。
在FastLeaderElection里有一个Manager的内部类，这个类里有启动了两个线 程：WorkerReceiver， WorkerSender。为什么说选举这部分复杂呢，我觉得就是这些线程就像左右互搏一样，非常难以理解。顾名思 义，这两个线程一个是处理从别的节点接收消息的，一个是向外发送消息的。对于外面的逻辑接收和发送的逻辑都是异步的。
这里配置好了，QuorumPeer的run方法就开始执行了，这里实现的是一个简单的状态机。因为现在是LOOKING状态，所以进入LOOKING的分支，调用选举算法开始选举了：
setCurrentVote(makeLEStrategy().lookForLeader());
而在lookForLeader里主要是干什么呢？首先我们会更新一下一个叫逻辑时钟的东西，这也是在分布式算法里很重要的一个概念，但是在这里先 不介绍，可以参考后面的论文。然后决定我要投票给谁。不过zookeeper这里的选举真直白，每个节点都选自己(汗),选我，选我，选我…… 然后向其他节点广播这个选举信息。这里实际上并没有真正的发送出去，只是将选举信息放到由WorkerSender管理的一个队列里。
synchronized(this){ //逻辑时钟 logicalclock++; //getInitLastLoggedZxid(), getPeerEpoch()这里先不关心是什么，后面会讨论 updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch());}//getInitId() 即是获取选谁，id就是myid里指定的那个数字，所以说一定要唯一private long getInitId(){ if(self.getQuorumVerifier().getVotingMembers().containsKey(self.getId())) return self.getId(); else return Long.MIN_VALUE;}//发送选举信息，异步发送sendNotifications();
现在我们去看看怎么把投票信息投递出去。这个逻辑在WorkerSender里，WorkerSender从sendqueue里取出投票，然后交 给QuorumCnxManager发送。因为前面发送投票信息的时候是向集群所有节点发送，所以当然也包括自己这个节点，所以 QuorumCnxManager的发送逻辑里会判断，如果这个要发送的投票信息是发送给自己的，则不发送了，直接进入接收队列。
public void toSend(Long sid, ByteBuffer b) { if (self.getId() == sid) { b.position(0); addToRecvQueue(new Message(b.duplicate(), sid)); } else { //发送给别的节点，判断之前是不是发送过 if (!queueSendMap.containsKey(sid)) { //这个SEND_CAPACITY的大小是1，所以如果之前已经有一个还在等待发送，则会把之前的一个删除掉，发送新的 ArrayBlockingQueue bq = new ArrayBlockingQueue(SEND_CAPACITY); queueSendMap.put(sid, bq); addToSendQueue(bq, b); } else { ArrayBlockingQueue bq = queueSendMap.get(sid); if(bq != null){ addToSendQueue(bq, b); } else { LOG.error(“No queue for server ” + sid); } } //这里是真正的发送逻辑了 connectOne(sid); } }
connectOne就是真正发送了。在发送之前会先把自己的id和选举地址发送过去。然后判断要发送节点的id是不是比自己的id大，如果大则不 发送了。如果要发送又是启动两个线程：SendWorker,RecvWorker(这种一个进程内许多不同种类的线程，各自干活的状态真的很难理解)。 发送逻辑还算简单，就是从刚才放到那个queueSendMap里取出，然后发送。并且发送的时候将发送出去的东西放到一个 lastMessageSent的map里，如果queueSendMap里是空的，就发送lastMessageSent里的东西，确保对方一定收到 了。
看完了SendWorker的逻辑，再来看看数据接收的逻辑吧。还记得前面提到的有个Listener在选举端口上启动了监听么，现在这里应该接收 到数据了。我们可以看到receiveConnection方法。在这里，如果接收到的的信息里的id比自身的id小，则断开连接，并尝试发送消息给这个 id对应的节点(当然，如果已经有SendWorker在往这个节点发送数据，则不用了)。
如果接收到的消息的id比当前的大，则会有RecvWorker接收数据，RecvWorker会将接收到的数据放到recvQueue里。
而FastLeaderElection的WorkerReceiver线程里会不断地从这个recvQueue里读取Message处理。在 WorkerReceiver会处理一些协议上的事情，比如消息格式等。除此之外还会看看接收到的消息是不是来自投票成员。如果是投票成员，则会看看这个 消息里的状态，如果是LOOKING状态并且当前的逻辑时钟比投票消息里的逻辑时钟要高，则会发个通知过去，告诉谁是leader。在这里，刚刚启动的崭 新集群，所以逻辑时钟基本上都是相同的，所以这里还没判断出谁是leader。不过在这里我们注意到如果当前节点的状态是LOOKING的话，接收逻辑会 将接收到的消息放到FastLeaderElection的recvqueue里。而在FastLeaderElection会从这个recvqueue 里读取东西。
这里就是选举的主要逻辑了：totalOrderPredicate
protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch) {return ((newEpoch > curEpoch) || ((newEpoch == curEpoch) && ((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId))))); } - 判断消息里的epoch是不是比当前的大，如果大则消息里id对应的server我就承认它是leader
- 如果epoch相等则判断zxid，如果消息里的zxid比我的大我就承认它是leader
- 如果前面两个都相等那就比较一下server id吧，如果比我的大我就承认它是leader。
关于前面两个东西暂时我们不去关心它，对于新启动的集群这两者都是相等的。
那这样看来server id的大小也是leader选举的一环啊（有的人生下来注定就不平凡，这都是命啊）。
最后我们来看看，很多文章所介绍的，如果超过一半的人说它是leader，那它就是leader的逻辑吧
private boolean termPredicate( HashMap votes, Vote vote) { HashSet set = new HashSet(); //遍历已经收到的投票集合，将等于当前投票的集合取出放到set中 for (Map.Entry entry : votes.entrySet()) { if (self.getQuorumVerifier().getVotingMembers().containsKey(entry.getKey()) && vote.equals(entry.getValue())){ set.add(entry.getKey()); } } //统计set，也就是投某个id的票数是否超过一半 return self.getQuorumVerifier().containsQuorum(set); } public boolean containsQuorum(Set ackSet) { return (ackSet.size() > half); }
最后一关：如果选的是自己，则将自己的状态更新为LEADING，否则根据type，要么是FOLLOWING，要么是OBSERVING。
到这里选举就结束了。
这里介绍的是一个新集群启动时候的选举过程，启动的时候就是根据zoo.cfg里的配置，向各个节点广播投票，一般都是选投自己。然后收到投票后就会进行进行判断。如果某个节点收到的投票数超过一半，那么它就是leader了。
了解了这个过程，我们来看看另外一个问题：
一个集群有3台机器，挂了一台后的影响是什么？挂了两台呢？
挂了一台：挂了一台后就是收不到其中一台的投票，但是有两台可以参与投票，按照上面的逻辑，它们开始都投给自己，后来按照选举的原则，两个人都投票 给其中一个，那么就有一个节点获得的票等于2，2 > (3/2)=1 的，超过了半数，这个时候是能选出leader的。
挂了两台： 挂了两台后，怎么弄也只能获得一张票， 1 不大于 (3/2)=1的，这样就无法选出一个leader了。
在前面介绍时，为了简单我假设的是这是一个崭新的刚启动的集群，这样的集群与工作一段时间后的集群有什么不同呢？不同的就是epoch和zxid这 两个参数。在新启动的集群里这两个一般是相等的，而工作一段时间后这两个参数有可能有的节点落后其他节点，至于是为什么，这个还要在后面的存储和处理额胡 断请求的文章里介绍。
- 关于逻辑时钟，我们的分布式大牛Leslie Lamport曾写过一篇论文：Time, Clocks, and the Ordering of Events in a Distributed System
Zookeeper–Zookeeper client
Zookeeper leader选举后，准备看看Zookeeper的存储和处理客户端请求的时候发现，如果能看看Zookeeper的API是不是在理解后面的过程更好些呢。
Zookeeper的client是通过Zookeeper类提供的。前面曾经说过，Zookeeper给使用者提供的是一个类似操作系统的文件结 构，只不过这个结构是分布式的。可以理解为一个分布式的文件系统。我们可以通过Zookeeper来访问这个分布式的文件系统。
Zookeeper的client api给我们提供以下这些API：
- create
在给定的path上创建节点，这个path就像文件系统的路径，比如/myapp/data/1，在创建节点的时候还可以指定节点的类型：是永久节 点，永久顺序节点，临时节点，临时顺序节点。这个节点类型是非常强大的。永久节点一经创建就永久保留了，就像我们在文件系统上创建一个普通文件，这个文件 的生命周期跟创建它的应用没有任何关系。而临时节点呢，当创建这个临时节点的应用与zookeeper之间的会话过期之后就会被zookeeper自动删 除了。这个特性是实现很多功能的关键。比如我们做集群感知，我们的应用启动的时候将自己的ip地址作为临时节点创建在某个节点下面。当我们的应用因为某些 原因，比如网络断掉或者宕机，它与zookeeper的会话就会过期了，过期后这个临时节点就删除了。这样我们就可以通过这个特性来感知到我们的服务的集 群有哪些机器是活者的。那么顺序节点又是什么呢。一般，如果我们在指定的path上创建节点，如果这个节点已经被创建了，则会抛出一个 NodeExistsException的异常。如果我们在指定的路径上创建顺序节点，则Zookeeper会自动的在我们给定的path上加上一个顺序 编号。这个特性就是实现分布式锁的关键。假设我们有几个节点共享一个资源，我们这几个节点都想争用这个资源，那我们就都向某个路径创建临时顺序节点。然后 顺序最小的那个就获得锁，然后如果某个节点释放了锁，那顺序第二小的那个就获得锁，以此类推，这样一个分布式的公平锁就实现了。
除此之外，每个节点上还可以保存一些数据。 - delete 删除给定节点。删除节点的时候还可以给定一个version，只有路径和version都匹配的时候节点才会被删除。有了这个version在分布式环境 种我们就可以用乐观锁的方式来确保一致性。比如我们先读取一下节点，获得了节点的version，然后删除，如果删除成功了则说明在这之间没有人操作过这 个节点，否则就是并发冲突了。
- exists 这个节点会返回一个Stat对象，如果给定的path不存在的话则返回null。这个方法有一个关键参数，可以提供一个Watcher对象。 Wathcer是Zookeeper强大功能的源泉。Watcher就是一个事件处理器，一个回调。比如这个exists方法，调用后，如果别人对这个 path上的节点进行操作，比如创建，删除或设置数据，这个Wather都会接收到对应的通知。
- setData/getData 设置或获取节点的数据，getData也可以设置Watcher
- getChildren 获取子节点，可以设置Watcher
- sync zookeeper是一个集群，创建节点的时候只要半数以上的节点确认就认为是创建成功了，但是如果读取的时候正好读取到一个落后的节点上，那就有可能读取到旧的数据，这个时候可以执行一个sync操作，这个操作可以确保读取到最新的数据。
zookeeper的client api基本上介绍完了。zookeeper强大的功能都是通过这些API来实现的，zookeeper通过一个简单的文件系统数据模型对外提供服务。通过临时节点，Watcher等手段我们可以实现一些在分布式环境种很难做到的事情。
