深入分析Zookeeper的Leader 选举实现原理
zookeeper 的由来：
分布式系统的很多难题，都是由于缺少协调机制造成的。在分布式协调这块做得比较好的，有 Google 的 Chubby 以及 Apache 的 Zookeeper。Google Chubby 是一个分布式锁服务，通过 Google Chubby 来解决分布式协作、Master 选举等与分布式锁服务相关的问题。
Zookeeper 也是类似，因为当时在雅虎内部的很多系统都需要依赖一个系统来进行分布式协调，但是谷歌的Chubby是不开源的，所以后来雅虎基于 Chubby 的思想开发了 zookeeper，并捐赠给了 Apache。
zookeeper解决了什么问题：
-
zookeeper是一个精简的文件系统。这点它和hadoop有点像，但是zookeeper这个文件系统是管理小文件的，而hadoop是管理超大文件的。
-
zookeeper提供了丰富的“构件”，这些构件可以实现很多协调数据结构和协议的操作。例如：分布式队列、分布式锁以及一组同级节点的“领导者选举”算法。
-
zookeeper是高可用的，它本身的稳定性是相当之好，分布式集群完全可以依赖zookeeper集群的管理，利用zookeeper避免分布式系统的单点故障的问题。
-
zookeeper采用了松耦合的交互模式。这点在zookeeper提供分布式锁上表现最为明显，zookeeper可以被用作一个约会机制，让参入的进程不在了解其他进程的（或网络）的情况下能够彼此发现并进行交互，参入的各方甚至不必同时存在，只要在zookeeper留下一条消息，在该进程结束后，另外一个进程还可以读取这条信息，从而解耦了各个节点之间的关系。
-
zookeeper为集群提供了一个共享存储库，集群可以从这里集中读写共享的信息，避免了每个节点的共享操作编程，减轻了分布式系统的开发难度。
-
zookeeper的设计采用的是观察者的设计模式，zookeeper主要是负责存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式。
- 。。。。。
数据节点：
在 ZooKeeper中,每个数据节点都是有生命周期的,其生命周期的长短取决于数据节点的节点类型。在 ZooKeeper中,节点类型可以分为持久节点(PERSISTENT)、临时节点(EPHEMERAL)和顺序节点(SEQUENTIAL)三大类,具体在节点创建过程中,通过组合使用,可以生成以下四种组合型节点类型:
- 持久节点(PERSISTENT)：持久节点是 ZooKeeper中最常见的一种节点类型。所谓持久节点,是指该数据节点被创建后,就会一直存在于 ZooKeeper服务器上,直到有删除操作来主动清除这个节点。
- 持久顺序节点(PERSISTENT SEQUENTIAL)：持久顺序节点的基本特性和持久节点是一致的,额外的特性表现在顺序性上。在ZooKeeper中,每个父节点都会为它的第一级子节点维护一份顺序,用于记录下每个子节点创建的先后顺序。基于这个顺序特性,在创建子节点的时候,可以设置这个标记,那么在创建节点过程中, ZooKeeper会自动为给定节点名加上一个数字后缀,作为一个新的、完整的节点名。另外需要注意的是,这个数字后缀的上限是整型的最大值。
- 临时节点(EPHEMERAL)：和持久节点不同的是,临时节点的生命周期和客户端的会话绑定在一起,也就是说,如果客户端会话失效,那么这个节点就会被自动清理掉。注意,这里提到的是客户端会话失效,而非TCP连接断开。另外, ZooKeeper规定了不能基于临时节点来创建子节点,即临时节点只能作为叶子节点。临时节点不能存在子节点
- 临时顺序节点(EPHEMERAL SEQUENTIAL)：临时顺序节点的基本特性和临时节点也是一致的,同样是在临时节点的基础上,添加了顺序的特性。
3.6.x 版本后新增以下三个节点 ( 详见 org.apache.zookeeper.CreateMode)：
容器节点 CONTAINER：container节点是一个特殊用途的节点，它是为Leader、Lock等操作而设计的节点类 型，
它的作用是： 当容器节点的最后一个子节点被删除后，容器节点将会被标注并且在一段时间后删 除。 由于容器节点存在这个特性，所以当我们在容器节点下创建一个子节点时，需要捕获 KeeperException.NoNodeException异常，如果捕获到这个异常，就需要重新创建容器节点。
TTL节点:
如果某个节点设置为TTL节点类型，那么这个节点在指定TTL时间（单位为毫秒）段内没有修改并且没有 子节点时，该节点会在一段时间后被删除。
PERSISTENT_WITH_TTL：zookeeper的扩展类型，如果znode在给定的TTL内没有被修改，它将 在没有子节点时被删除。要想使用该类型，必须在zookeeper的bin/zkService.sh中的启动 zookeeper的java环境中设置环境变量zookeeper.extendedTypesEnabled=true（具体做法在下 边），否则KeeperErrorCode = Unimplemented for /**。
设置zookeeper.extendedTypesEnabled=true
打开zookeeper bin/zkServer.sh(win是zkService.cmd),修改启动zookeeper的命令,加上 -Dzookeeper.extendedTypesEnabled=true, 也就是设置java的一个环境变量。
PERSISTENT_SEQUENTIAL_WITH_TTL：同上，是不过是带序号的
如果自己设计一个类似 zookeeper 这个中间件，我们需要考虑到什么呢？：
1. 防止单点故障
如果要防止 zookeeper 这个中间件的单点故障，那就势必要做集群。而且这个集群如果要满足高性能要求的话，还得是一个高性能高可用的集群。高性能意味着这个集群能够分担客户端的请求流量，高可用意味着集群中的某一个节点宕机以后，不影响整个集群的数据和继续提供服务的可能性。结论： 所以这个中间件需要考虑到集群,而且这个集群还需要分摊客户端的请求流量，实现服务的高性能。
2. 接着上面那个结论再来思考，如果要满足这样的一个高性能集群，我们最直观的想法应该是，每个节点都能接收到请求，并且每个节点的数据都必须要保持一致。要实现各个节点的数据一致性，就势必要一个 leader 节点负责协调和数据同步操作。这个我想大家都知道，如果在这样一个集群中没有 leader 节点，每个节点都可以接收所有请求，那么这个集群的数据同步的复杂度是非常大。结论：所以这个集群中涉及到数据同步以及会存在leader 节点
3.继续思考，如何在这些节点中选举出 leader 节点，以及leader 挂了以后，如何恢复呢？结论：所以 zookeeper 用了基于 paxos 理论所衍生出来的 ZAB 协议
.4. leader 节点如何和其他节点保证数据一致性，并且要求是强一致的。在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，分布式事务的数据一致性协议有 2PC 协议和3PC 协议。
Zookeeper 集群角色：
Leader 角色：Leader 服务器是整个 zookeeper 集群的核心，主要的工作任务有两项1. 事务请求的唯一调度和处理者，保证集群事物处理的顺序性2. 集群内部各服务器的调度者
Follower 角色：Follower 角色的主要职责是1. 处理客户端非事务请求、转发事务请求给 leader 服务器2. 参与事物请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案，要求 Follower 投票）3. 参与 Leader 选举的投票
Observer 角色：Observer 是 zookeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当了观察者的角色。观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。Observer 的工作原理与follower 角色基本一致，而它和 follower 角色唯一的不同在于 observer 不参与任何形式的投票，包括事务请求Proposal的投票和leader选举的投票。简单来说，observer服务器只提供非事务请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事务处理的能力
zookeeper 的集群：
如上图，在 zookeeper 中，客户端会随机连接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据，如果是写请求，那么请求会被转发给 leader 提交事务，然后 leader 会广播事务，只要有超过半数节点写入成功，那么写请求就会被提交（类 2PC 事务）
通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。对于 2n+1 台 server，只要有 n+1 台（大多数）server 可用，整个系统保持可用。我们已经了解到，一个 zookeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信，基于这个特性，如果向搭建一个能够允许 F 台机器down 掉的集群，那么就要部署 2*F+1 台服务器构成的zookeeper 集群。因此 3 台机器构成的 zookeeper 集群，能够在挂掉一台机器后依然正常工作。一个 5 台机器集群的服务，能够对 2 台机器down掉的情况下进行容灾。如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此，5 台和 6 台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的 server 会选举出一台server 为 Leader，其它的就作为 follower（这里先不考虑observer 角色）。
之所以要满足这样一个等式，是因为一个节点要成为集群中的 leader，需要有超过及群众过半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票。
所有事务请求必须由一个全局唯一的服务器来协调处理，这个服务器就是 Leader 服务器，其他的服务器就是follower。leader 服务器把客户端的失去请求转化成一个事务 Proposal（提议），并把这个 Proposal 分发给集群中的所有 Follower 服务器。之后 Leader 服务器需要等待所有Follower 服务器的反馈，一旦超过半数的 Follower 服务器进行了正确的反馈，那么 Leader 就会再次向所有的Follower 服务器发送 Commit 消息，要求各个 follower 节点对前面的一个 Proposal 进行提交;
顺序一致性模型：
讲Zookeeper的数据同步时，提到zookeeper并不是强一致性服务，它是一个最终一致性模 型，具体情况如图所示。
ClientA/B/C假设只串行执行， clientA更新zookeeper上的一个值x。ClientB和clientC分别读取集群的 不同副本，返回的x的值是不一样的。clientC的读取操作是发生在clientB之后，但是却读到了过期的 值。很明显，这是一种弱一致模型。如果用它来实现锁机制是有问题的。
顺序一致性提供了更强的一致性保证，我们来观察图-5所示，从时间轴来看，B0发生在A0之前，读取 的值是0，B2发生在A0之后，读取到的x的值为1.而读操作B1/C0/C1和写操作A0在时间轴上有重叠 ，因此他们可能读到旧的值为0，也可能读到新的值1. 但是在强顺序一致性模型中，如果B1得到的x的 值为1，那么C1看到的值也一定是1。
需要注意的是：由于网络的延迟以及系统本身执行请求的不确定性，会导致请求发起的早的客户端不一 定会在服务端执行得早。最终以服务端执行的结果为准。
简单来说：顺序一致性是针对单个操作，单个数据对象。属于CAP中C这个范畴。一个数据被更新后， 能够立马被后续的读操作读到。 但是zookeeper的顺序一致性实现是缩水版的，在下面这个网页中，可以看到官网对于一致性这块做了 解释
https://zookeeper.apache.org/doc/r3.6.1/zookeeperProgrammers.html#ch_zkGuarantees
zookeeper不保证在每个实例中，两个不同的客户端具有相同的zookeeper数据视图，由于网络延迟等 因素，一个客户端可能会在另外一个客户端收到更改通知之前执行更新， 考虑到2个客户端A和B的场景，如果A把znode /a的值从0设置为1，然后告诉客户端B读取 /a， 则客户 端B可能会读取到旧的值0，具体取决于他连接到那个服务器，如果客户端A和B要读取必须要读取到相 同的值，那么client B在读取操作之前执行sync方法。 zooKeeper.sync();
除此之外，zookeeper基于zxid以及阻塞队列的方式来实现请求的顺序一致性。如果一个client连接到一 个最新的follower上，那么它read读取到了最新的数据，然后client由于网络原因重新连接到zookeeper 节点， 而这个时候连接到一个还没有完成数据同步的follower节点，那么这一次读到的数据不就是旧的数据吗？
实际上zookeeper处理了这种情况，client会记录自己已经读取到的最大的zxid，如果client重连到 server发现client的zxid比自己大，连接会失败。
zookeeper官网还说它保证了“Single System Image”，其解释为“A client will see the same view of the service regardless of the server that it connects to.”。其实由上面zxid的原理可以看出，它表达的意思是“client只要连接过一次zookeeper，就不会有历史的 倒退”。
ZAB协议：
ZAB（Zookeeper Atomic Broadcast） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。ZAB 协议包含两种基本模式，分别是
1. 崩溃恢复
2. 原子广播
当整个集群在启动时，或者当 leader 节点出现网络中断、崩溃等情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader，当 leader 服务器选举出来后，并且集群中有过半的机器和该 leader 节点完成数据同步后（同步指的是数据同步，用来保证集群中过半的机器能够和 leader 服务器的数据状态保持一致），ZAB 协议就会退出恢复模式。当集群中已经有过半的 Follower 节点完成了和 Leader 状态同步以后，那么整个集群就进入了消息广播模式。这个时候，在 Leader 节点正常工作时，启动一台新的服务器加入到集群，那这个服务器会直接进入数据恢复模式，和 leader 节点进行数据同步。同步完成后即可正常对外提供非事务请求的处理。
消息广播的实现原理 :
消息广播的过程实际上是一个简化版本的二阶段提交过程。如下图：
1. leader 接收到消息请求后，将消息赋予一个全局唯一的64 位自增 id，叫：zxid，通过 zxid 的大小比较既可以实现因果有序这个特征
2. leader 为每个 follower 准备了一个 FIFO 队列（通过 TCP协议来实现，以实现了全局有序这一个特点）将带有 zxid的消息作为一个提案（proposal）分发给所有的 follower
3. 当 follower 接收到 proposal，先把 proposal 写到磁盘，写入成功以后再向 leader 回复一个 ack
4. 当 leader 接收到合法数量（超过半数节点）的 ACK 后，leader 就会向这些 follower 发送 commit 命令，同时会在本地执行该消息
5. 当 follower 收到消息的 commit 命令以后，会提交该消息。
leader 的投票过程，不需要 Observer 的 ack，也就是Observer 不需要参与投票过程，但是 Observer 必须要同步 Leader 的数据从而在处理请求的时候保证数据的一致性
崩溃恢复(数据恢复):
ZAB 协议的这个基于原子广播协议的消息广播过程，在正常情况下是没有任何问题的，但是一旦 Leader 节点崩溃，或者由于网络问题导致 Leader 服务器失去了过半的Follower 节点的联系（leader 失去与过半 follower 节点联系，可能leader 节点和 follower 节点之间产生了网络分区，那么此时的 leader 不再是合法的 leader 了），那么就会进入到崩溃恢复模式。在 ZAB 协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的Leader为了使 leader 挂了后系统能正常工作，需要解决以下两个问题
1. 已经被处理的消息不能丢失：当 leader 收到合法数量 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 命令，同时也会在本地执行 COMMIT 并向连接的客户端返回「成功」。但是如果在各个 follower 在收到 COMMIT 命令前leader就挂了，导致剩下的服务器并没有执行都这条消息。leader 对事务消息发起 commit 操作，但是该消息在follower1 上执行了，但是 follower2 还没有收到 commit，就已经挂了，而实际上客户端已经收到该事务消息处理成功的回执了。所以在 zab 协议下需要保证所有机器都要执行这个事务消息
2. 被丢弃的消息不能再次出现：当 leader 接收到消息请求生成 proposal 后就挂了，其他 follower 并没有收到此 proposal，因此经过恢复模式重新选了 leader 后，这条消息是被跳过的。 此时，之前挂了的 leader 重新启动并注册成了follower，他保留了被跳过消息的 proposal 状态，与整个系统的状态是不一致的，需要将其删除。
ZAB 协议需要满足上面两种情况，就必须要设计一个leader 选举算法：能够确保已经被 leader 提交的事务Proposal能够提交、同时丢弃已经被跳过的事务Proposal。针对这个要求
1. 如果 leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器最高编号（ZXID 最大）的事务Proposal，那么就可以保证这个新选举出来的 Leader 一定具有已经提交的提案。因为所有提案被 COMMIT 之前必须有超过半数的 follower ACK，即必须有超过半数节点的服务器的事务日志上有该提案的 proposal，因此，只要有合法数量的节点正常工作，就必然有一个节点保存了所有被 COMMIT 消息的 proposal 状态另外一个，zxid 是 64 位，高 32 位是 epoch 编号，每经过一次 Leader 选举产生一个新的 leader，新的 leader 会将epoch 号+1，低 32 位是消息计数器，每接收到一条消息这个值+1，新 leader 选举后这个值重置为 0.这样设计的好处在于老的 leader 挂了以后重启，它不会被选举为 leader，因此此时它的 zxid 肯定小于当前新的 leader。当老的leader 作为 follower 接入新的 leader 后，新的 leader 会让它将所有的拥有旧的 epoch 号的未被 COMMIT 的proposal 清除
关于 ZXID :
zxid，也就是事务 id，为了保证事务的顺序一致性，zookeeper 采用了递增的事务 id 号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了 zxid。实现中 zxid 是一个 64 位的数字，它高 32 位是 epoch（ZAB 协议通过epoch 编号来区分 Leader 周期变化的策略）用来标识 leader 关系是否改变，每次一个 leader 被选出来，它都会有一个新的epoch=（原来的 epoch+1），标识当前属于那个 leader 的统治时期。低 32 位用于递增计数。epoch：可以理解为当前集群所处的年代或者周期，每个leader 就像皇帝，都有自己的年号，所以每次改朝换代，leader 变更之后，都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃恢复之后，也没有人听他的了，因为follower 只听从当前年代的 leader 的命令。epoch 的变化大家可以做一个简单的实验，
1. 启动一个 zookeeper 集群。
2. 在 /"dataDir"/zookeeper/VERSION-2 路 径 下 会 看 到 一 个currentEpoch 文件。文件中显示的是当前的 epoch
3. 把 leader 节点停机，这个时候在看 currentEpoch 会有变化。 随着每次选举新的 leader，epoch 都会发生变化
Zookeeper的数据是持久化在磁盘上的，默认的目录是在/tmp/zookeeper下，这个目录中会存放事务 日志和快照日志。
在该目录下可以看到有以下文件内容，在Zab协议中我们知道每当有接收到客户端的事务请求后Leader 与Follower都会将把该事务日志存入磁盘日志文件中，该日志文件就是这里所说的事务日志。
其中文件的命名是 log.zxid， 其中zxid表示当前日志文件中开始记录的第一条数据的zxid。
查看事务日志文件的命令
java -cp :/mysoft/zookeeper/lib/slf4j-api-1.7.25.jar:/mysoft/zookeeper/lib/zookeeper-jute-3.6.3.jar:/mysoft/zookeeper/lib/zookeeper-3.6.3.jar org.apache.zookeeper.server.LogFormatter log.1
查看快照文件的命令：
java -cp :/mysoft/zookeeper/lib/slf4j-api-1.7.25.jar:/mysoft/zookeeper/lib/zookeeper-jute-3.6.3.jar:/mysoft/zookeeper/lib/zookeeper-3.6.3.jar:/mysoft/zookeeper/lib/snappy-java-1.1.7.jar org.apache.zookeeper.server.SnapshotFormatter snapshot.0
leader 选举:
Leader 选举会分两个过程启动的时候的 leader 选举、 leader 崩溃的时候的的选举服务器启动时的 leader 选举每个节点启动的时候状态都是 LOOKING，处于观望状态，接下来就开始进行选主流程进行 Leader 选举，至少需要两台机器，我们选取 3 台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器 Server1 启动时，它本身是无法进行和完成 Leader 选举，当第二台服务器 Server2 启动时，这个时候两台机器可以相互通信，每台机器都试图找到 Leader，于是进入 Leader 选举过程。选举过程如下:
(1) 每个 Server 发出一个投票。由于是初始情况，Server1和 Server2 都会将自己作为 Leader 服务器来进行投票，每次投票会包含所推举的服务器的 myid 和 ZXID、epoch，使用(myid, ZXID,epoch)来表示，此时 Server1的投票为(1, 0)，Server2 的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自LOOKING状态的服务器。
(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行 PK，PK 规则如下
i. 优先检查 ZXID。ZXID 比较大的服务器优先作为Leader
ii. 如果 ZXID 相同，那么就比较 myid。myid 较大的服务器作为 Leader 服务器。
对于 Server1 而言，它的投票是(1, 0)，接收 Server2的投票为(2, 0)，首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是更新自己的投票为(2, 0)，然后重新投票，对于 Server2 而言，它不需要更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 Server1、Server2 而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了 Leader。
(5) 改变服务器状态。一旦确定了 Leader，每个服务器就会更新自己的状态，如果是 Follower，那么就变更为FOLLOWING，如果是 Leader，就变更为 LEADING。
运行过程中的 leader 选举：
当集群中的 leader 服务器出现宕机或者不可用的情况时，那么整个集群将无法对外提供服务，而是进入新一轮的Leader 选举，服务器运行期间的 Leader 选举和启动时期的 Leader 选举基本过程是一致的。
(1) 变更状态。Leader 挂后，余下的非 Observer 服务器都会将自己的服务器状态变更为 LOOKING，然后开始进入 Leader 选举过程。
(2) 每个 Server 会发出一个投票。在运行期间，每个服务器上的 ZXID 可能不同，此时假定 Server1 的 ZXID 为123，Server3的ZXID为122；在第一轮投票中，Server1和 Server3 都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。接收来自各个服务器的投票。与启动时过程相同。
(3) 处理投票。与启动时过程相同，此时，Server1 将会成为 Leader。
(4) 统计投票。与启动时过程相同。
(5) 改变服务器的状态。与启动时过程相同
Leader 选举源码分析：
有了理论基础以后，我们先读一下源码（zookeeper-3.6.3），看看他的实现逻辑。首先我们需要知道源码入口，对于zk的leader选举，并不是由客户端来触发，而是在启动的 时候会触发一次选举。因此我们可以直接去看启动脚本zkServer.sh中的运行命令
ZOOMAIN="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=$JMXLOCALONLY org.apache.zookeeper.server.quorum.QuorumPeerMain" --------------------------------------------- nohup "$JAVA" $ZOO_DATADIR_AUTOCREATE "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" \ "-Dzookeeper.log.file=${ZOO_LOG_FILE}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \ -XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p' \ -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null &
也就是Zookeeper启动的主类： QuorumPeerMain 类的 main 方法开始：
public static void main(String[] args) { QuorumPeerMain main = new QuorumPeerMain(); try {//初始化主要逻辑 main.initializeAndRun(args); } //...异常捕获 LOG.info("Exiting normally"); System.exit(0); }
进入 main.initializeAndRun(args) 可以看到：
protected void initializeAndRun(String[] args) throws ConfigException, IOException, AdminServerException { //定义一个config对象，用来解析并存储配置 QuorumPeerConfig config = new QuorumPeerConfig(); if (args.length == 1) { config.parse(args[0]); } // 启动一个线程定时进行日志清理 // Start and schedule the the purge task DatadirCleanupManager purgeMgr = new DatadirCleanupManager( config.getDataDir(), config.getDataLogDir(), config.getSnapRetainCount(), config.getPurgeInterval()); purgeMgr.start(); //如果是集群模式，调用`runFromConfig` if (args.length == 1 && config.isDistributed()) { runFromConfig(config); } else { // 单机 LOG.warn("Either no config or no quorum defined in config, running in standalone mode"); // there is only server in the quorum -- run as standalone ZooKeeperServerMain.main(args); } }
进入 runFromConfig（）：
public void runFromConfig(QuorumPeerConfig config) throws IOException, AdminServerException { try {//注册JMX,可以通过配置文件去处理 ManagedUtil.registerLog4jMBeans(); } catch (JMException e) { LOG.warn("Unable to register log4j JMX control", e); } LOG.info("Starting quorum peer, myid=" + config.getServerId()); //初始化指标数据的提供者对象。 MetricsProvider metricsProvider; try { metricsProvider = MetricsProviderBootstrap.startMetricsProvider( config.getMetricsProviderClassName(), config.getMetricsProviderConfiguration()); } catch (MetricsProviderLifeCycleException error) { throw new IOException("Cannot boot MetricsProvider " + config.getMetricsProviderClassName(), error); } try {//初始化ServerCnxnFactory，后续应该要用到。 ServerMetrics.metricsProviderInitialized(metricsProvider); ServerCnxnFactory cnxnFactory = null; ServerCnxnFactory secureCnxnFactory = null; if (config.getClientPortAddress() != null) { cnxnFactory = ServerCnxnFactory.createFactory(); cnxnFactory.configure(config.getClientPortAddress(), config.getMaxClientCnxns(), config.getClientPortListenBacklog(), false); } if (config.getSecureClientPortAddress() != null) { secureCnxnFactory = ServerCnxnFactory.createFactory(); secureCnxnFactory.configure(config.getSecureClientPortAddress(), config.getMaxClientCnxns(), config.getClientPortListenBacklog(), true); } //初始化一个QuorumPeer对象，并赋值 quorumPeer = getQuorumPeer(); quorumPeer.setTxnFactory(new FileTxnSnapLog(config.getDataLogDir(), config.getDataDir())); quorumPeer.enableLocalSessions(config.areLocalSessionsEnabled()); quorumPeer.enableLocalSessionsUpgrading(config.isLocalSessionsUpgradingEnabled()); //quorumPeer.setQuorumPeers(config.getAllMembers()); //选举算法类型 默认3 quorumPeer.setElectionType(config.getElectionAlg()); quorumPeer.setMyid(config.getServerId()); //Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。tickTime以毫秒为单 quorumPeer.setTickTime(config.getTickTime()); quorumPeer.setMinSessionTimeout(config.getMinSessionTimeout()); quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout()); quorumPeer.setInitLimit(config.getInitLimit()); quorumPeer.setSyncLimit(config.getSyncLimit()); quorumPeer.setConnectToLearnerMasterLimit(config.getConnectToLearnerMasterLimit()); quorumPeer.setObserverMasterPort(config.getObserverMasterPort()); quorumPeer.setConfigFileName(config.getConfigFilename()); quorumPeer.setClientPortListenBacklog(config.getClientPortListenBacklog()); quorumPeer.setZKDatabase(new ZKDatabase(quorumPeer.getTxnFactory())); quorumPeer.setQuorumVerifier(config.getQuorumVerifier(), false); if (config.getLastSeenQuorumVerifier() != null) { quorumPeer.setLastSeenQuorumVerifier(config.getLastSeenQuorumVerifier(), false); } quorumPeer.initConfigInZKDatabase(); quorumPeer.setCnxnFactory(cnxnFactory); quorumPeer.setSecureCnxnFactory(secureCnxnFactory); quorumPeer.setSslQuorum(config.isSslQuorum()); quorumPeer.setUsePortUnification(config.shouldUsePortUnification()); quorumPeer.setLearnerType(config.getPeerType()); quorumPeer.setSyncEnabled(config.getSyncEnabled()); quorumPeer.setQuorumListenOnAllIPs(config.getQuorumListenOnAllIPs()); if (config.sslQuorumReloadCertFiles) { quorumPeer.getX509Util().enableCertFileReloading(); } quorumPeer.setMultiAddressEnabled(config.isMultiAddressEnabled()); quorumPeer.setMultiAddressReachabilityCheckEnabled(config.isMultiAddressReachabilityCheckEnabled()); quorumPeer.setMultiAddressReachabilityCheckTimeoutMs(config.getMultiAddressReachabilityCheckTimeoutMs()); // sets quorum sasl authentication configurations quorumPeer.setQuorumSaslEnabled(config.quorumEnableSasl); if (quorumPeer.isQuorumSaslAuthEnabled()) { quorumPeer.setQuorumServerSaslRequired(config.quorumServerRequireSasl); quorumPeer.setQuorumLearnerSaslRequired(config.quorumLearnerRequireSasl); quorumPeer.setQuorumServicePrincipal(config.quorumServicePrincipal); quorumPeer.setQuorumServerLoginContext(config.quorumServerLoginContext); quorumPeer.setQuorumLearnerLoginContext(config.quorumLearnerLoginContext); } quorumPeer.setQuorumCnxnThreadsSize(config.quorumCnxnThreadsSize); quorumPeer.initialize(); if (config.jvmPauseMonitorToRun) { quorumPeer.setJvmPauseMonitor(new JvmPauseMonitor(config)); } ;//启动主线程 quorumPeer.start(); ZKAuditProvider.addZKStartStopAuditLog(); quorumPeer.join(); // 阻塞 } catch (InterruptedException e) { // warn, but generally this is ok LOG.warn("Quorum Peer interrupted", e); } finally { if (metricsProvider != null) { try { metricsProvider.stop(); } catch (Throwable error) { LOG.warn("Error while stopping metrics", error); } } } }
Zookeeper server的服务启动逻辑:
集群在触发leader选举之前，先需要启动服务。 ServerCnxnFactory从名字就可以看出其是一个工厂类，负责管理ServerCnxn，ServerCnxn这个类代 表了一个客户端与一个server的连接，每个客户端连接过来都会被封装成一个ServerCnxn实例用来维护 了服务器与客户端之间的Socket通道。
首先要有监听端口，客户端连接才能过来， ServerCnxnFactory.configure()方法的核心就是启动监听端口供客户端连接进来，端口号由配置文件中 clientPort属性进行配置，默认是2181
Zookeeper 默认使用 NIO 主从多线程多路复用机制，建议同学们先了解一下这块的知识，可以参考: https://www.cnblogs.com/wuzhenzhao/p/14089660.html
在QuorumPeerMain方法中，初始化Factory之后，会调用configure，这里面会初始化NIO Server的连 接信息。其中，ServerCnxnFactory.createFactory()，默认会返回一个 NIOServerCnxnFactory ,饭后进入 org.apache.zookeeper.server.NIOServerCnxnFactory#configure
public void configure(InetSocketAddress addr, int maxcc, int backlog, boolean secure) throws IOException { if (secure) { throw new UnsupportedOperationException("SSL isn't supported in NIOServerCnxn"); } configureSaslLogin(); maxClientCnxns = maxcc; initMaxCnxns();//初始化最大连接数 sessionlessCnxnTimeout = Integer.getInteger(ZOOKEEPER_NIO_SESSIONLESS_CNXN_TIMEOUT, 10000); // We also use the sessionlessCnxnTimeout as expiring interval for // cnxnExpiryQueue. These don't need to be the same, but the expiring // interval passed into the ExpiryQueue() constructor below should be // less than or equal to the timeout. cnxnExpiryQueue = new ExpiryQueue<NIOServerCnxn>(sessionlessCnxnTimeout); expirerThread = new ConnectionExpirerThread(); //获取cpu核心数 int numCores = Runtime.getRuntime().availableProcessors(); // 32 cores sweet spot seems to be 4 selector threads // 计算用来扫描监控selector的线程数量 32核心数 分配4个 selector 线程 numSelectorThreads = Integer.getInteger( ZOOKEEPER_NIO_NUM_SELECTOR_THREADS, Math.max((int) Math.sqrt((float) numCores / 2), 1)); if (numSelectorThreads < 1) { throw new IOException("numSelectorThreads must be at least 1"); } // 工作线程，就是主从多线程的NIO模型种的 subReactor numWorkerThreads = Integer.getInteger(ZOOKEEPER_NIO_NUM_WORKER_THREADS, 2 * numCores); workerShutdownTimeoutMS = Long.getLong(ZOOKEEPER_NIO_SHUTDOWN_TIMEOUT, 5000); String logMsg = "Configuring NIO connection handler with " + (sessionlessCnxnTimeout / 1000) + "s sessionless connection timeout, " + numSelectorThreads + " selector thread(s), " + (numWorkerThreads > 0 ? numWorkerThreads : "no") + " worker threads, and " + (directBufferBytes == 0 ? "gathered writes." : ("" + (directBufferBytes / 1024) + " kB direct buffers.")); LOG.info(logMsg); // 初始化 工作线程 for (int i = 0; i < numSelectorThreads; ++i) { selectorThreads.add(new SelectorThread(i)); } listenBacklog = backlog; this.ss = ServerSocketChannel.open();//初始化ServerSocketChannel，并设置监听 ss.socket().setReuseAddress(true); LOG.info("binding to port {}", addr); if (listenBacklog == -1) { ss.socket().bind(addr); } else { ss.socket().bind(addr, listenBacklog); } ss.configureBlocking(false); // 初始化 Accept 反应堆 acceptThread = new AcceptThread(ss, addr, selectorThreads); }
然后我们回到 runFromConfig 方法中 ，QuorumPeer.start方法，重写了Thread的start。也就是在线程启动之前，会做以下操作
- 通过loadDataBase恢复快照数据
- startServerCnxnFactory 启动zkServer，相当于用户可以通过2181这个端口进行通信了.
public synchronized void start() { if (!getView().containsKey(myid)) { throw new RuntimeException("My id " + myid + " not in the peer list"); } loadDataBase(); //启动zookeeper服务端监控，2181端口 startServerCnxnFactory(); try { adminServer.start(); } catch (AdminServerException e) { LOG.warn("Problem starting AdminServer", e); System.out.println(e); } startLeaderElection();//开启leader选举 startJvmPauseMonitor();//监控JVM暂停的时间信息，这个类在Hadoop和Hbase中都有 super.start(); }
loadDataBase() 主要是从本地文件中恢复数据，以及获取最新的 zxid。
private void loadDataBase() { try {//载入本地数据 zkDb.loadDataBase(); // load the epochs 加载ZXID // load the epochs long lastProcessedZxid = zkDb.getDataTree().lastProcessedZxid; // 根据zxid的高32位是epoch号，低32位是事务id进行抽离epoch号 long epochOfZxid = ZxidUtils.getEpochFromZxid(lastProcessedZxid); try {//从${data}/version-2/currentEpochs文件中加载当前的epoch号 currentEpoch = readLongFromFile(CURRENT_EPOCH_FILENAME); } catch (FileNotFoundException e) { // pick a reasonable epoch number // this should only happen once when moving to a // new code version currentEpoch = epochOfZxid; LOG.info( "{} not found! Creating with a reasonable default of {}. " + "This should only happen when you are upgrading your installation", CURRENT_EPOCH_FILENAME, currentEpoch); writeLongToFile(CURRENT_EPOCH_FILENAME, currentEpoch); }//从 zxid中提取的epoch比文件里的epoch要大的话，并且没有正在修改epoch if (epochOfZxid > currentEpoch) { // acceptedEpoch.tmp file in snapshot directory File currentTmp = new File(getTxnFactory().getSnapDir(), CURRENT_EPOCH_FILENAME + AtomicFileOutputStream.TMP_EXTENSION); if (currentTmp.exists()) { long epochOfTmp = readLongFromFile(currentTmp.getName()); LOG.info("{} found. Setting current epoch to {}.", currentTmp, epochOfTmp); setCurrentEpoch(epochOfTmp);//设置位大的epoch } else { throw new IOException( "The current epoch, " + ZxidUtils.zxidToString(currentEpoch) + ", is older than the last zxid, " + lastProcessedZxid); } } try { acceptedEpoch = readLongFromFile(ACCEPTED_EPOCH_FILENAME); } catch (FileNotFoundException e) { // pick a reasonable epoch number // this should only happen once when moving to a // new code version acceptedEpoch = epochOfZxid; LOG.info( "{} not found! Creating with a reasonable default of {}. " + "This should only happen when you are upgrading your installation", ACCEPTED_EPOCH_FILENAME, acceptedEpoch); writeLongToFile(ACCEPTED_EPOCH_FILENAME, acceptedEpoch); }//再比较 acceptedEpoch if (acceptedEpoch < currentEpoch) { throw new IOException("The accepted epoch, " + ZxidUtils.zxidToString(acceptedEpoch) + " is less than the current epoch, " + ZxidUtils.zxidToString(currentEpoch)); } } catch (IOException ie) { LOG.error("Unable to load database on disk", ie); throw new RuntimeException("Unable to run quorum server ", ie); } }
startServerCnxnFactory 启动zkServer :
private void startServerCnxnFactory() { //org.apache.zookeeper.server.NIOServerCnxnFactory#start // 启动服务主从多线程NIO进行事件监听 if (cnxnFactory != null) { cnxnFactory.start(); } if (secureCnxnFactory != null) { secureCnxnFactory.start(); } }
接下去就是初始化选举算法 leaderElection：
public synchronized void startLeaderElection() { try {//当前节点状态处于LOOKING状态时，会构建一个投票票据，这个票据由myid 、zxid、currentEpoch组成 if (getPeerState() == ServerState.LOOKING) { currentVote = new Vote(myid, getLastLoggedZxid(), getCurrentEpoch()); } } catch (IOException e) { RuntimeException re = new RuntimeException(e.getMessage()); re.setStackTrace(e.getStackTrace()); throw re; } //创建选举算法 默认类型是 3 this.electionAlg = createElectionAlgorithm(electionType); }
进入选举算法的初始化 createElectionAlgorithm()：配置选举算法，选举算法有 3 种，可以通过在 zoo.cfg 里面进行配置，默认是 FastLeaderElection 选举
protected Election createElectionAlgorithm(int electionAlgorithm) { Election le = null; //TODO: use a factory rather than a switch switch (electionAlgorithm) { case 1: throw new UnsupportedOperationException("Election Algorithm 1 is not supported."); case 2: throw new UnsupportedOperationException("Election Algorithm 2 is not supported."); case 3: //QuorumCnxManager是一个很核心的对象，用来实现领导选举中的网络连接管理功能 QuorumCnxManager qcm = createCnxnManager(); QuorumCnxManager oldQcm = qcmRef.getAndSet(qcm); if (oldQcm != null) {{//表示已经有在选举了，直接停止选举 LOG.warn("Clobbering already-set QuorumCnxManager (restarting leader election?)"); oldQcm.halt();//停止选举 } QuorumCnxManager.Listener listener = qcm.listener; if (listener != null) { //设置监听，这个监听器和选举有关系，基本上可以猜测到，它是和投票有关系，也许是监听票据数据做统计。 listener.start(); FastLeaderElection fle = new FastLeaderElection(this, qcm); //初始化并启动fastLeaderelection fle.start(); le = fle; } else { LOG.error("Null listener when initializing cnx manager"); } break; default: assert false; } return le; }
继续看 FastLeaderElection 的初始化动作，主要初始化了业务层的发送队列和接收队列 ：
public FastLeaderElection(QuorumPeer self, QuorumCnxManager manager){ this.stop = false; this.manager = manager; starter(self, manager); } // *********************************************** private void starter(QuorumPeer self, QuorumCnxManager manager) { this.self = self; proposedLeader = -1; proposedZxid = -1; // 投票 发送队列 阻塞 sendqueue = new LinkedBlockingQueue<ToSend>(); // 投票 接受队列 阻塞 recvqueue = new LinkedBlockingQueue<Notification>(); this.messenger = new Messenger(manager); }
然后再 Messager 的构造函数里 初始化发送和接受两个线程并且启动线程。
Messenger(QuorumCnxManager manager) {//异步决策
// 创建 vote 发送线程
this.ws = new WorkerSender(manager);
Thread t = new Thread(this.ws,"WorkerSender[myid=" + self.getId() + "]");
t.setDaemon(true);
t.start();//启动
// 创建 vote 接受线程
this.wr = new WorkerReceiver(manager);
t = new Thread(this.wr,"WorkerReceiver[myid=" + self.getId() + "]");
t.setDaemon(true);
t.start();//启动
}
到目前为止，Zookeeper 服务的 ServerCnxnFactory 通讯准备完毕，且 投票的线程也启动完毕，准备就绪，就以上的流程的流程图如下所示
前面的所有流程，只是给大家分析了Zookeeper的启动过程、以及leader选举算法的初始化过程。那么 接下来，我们去看一下leader选举的算法。
然后再回到 QuorumPeer.java。 FastLeaderElection 初始化完成以后，很明显，super.start() 表示当前类QuorumPeer继承了线程，线程必须要重写run方法，所以我们可以 在QuorumPeer中找到一个run方法
粗略看一下结构，好像也不难 PeerState有几种状态，分别是
- LOOKING，竞选状态。
- FOLLOWING，随从状态，同步leader状态，参与投票。
- OBSERVING，观察状态,同步leader状态，不参与投票。
- LEADING，领导者状态。
对于选举来说，默认都是LOOKING状态， 只有LOOKING状态才会去执行选举算法。每个服务器在启动时都会选择自己做为领导，然后将投票信 息发送出去，循环一直到选举出领导为止。
public void run() { updateThreadName(); LOG.debug("Starting quorum peer"); //省略JMX的代码 try { /* * Main loop 主循环 */ while (running) { //… 根据选举状态，选择不同的处理方式 switch (getPeerState()) { case LOOKING: // LOOKING，进入选举状态 LOG.info("LOOKING"); ServerMetrics.getMetrics().LOOKING_COUNT.add(1); if (Boolean.getBoolean("readonlymode.enabled")) { LOG.info("Attempting to start ReadOnlyZooKeeperServer"); // Create read-only server but don't start it immediately final ReadOnlyZooKeeperServer roZk = new ReadOnlyZooKeeperServer(logFactory, this, this.zkDb); // Instead of starting roZk immediately, wait some grace // period before we decide we're partitioned. // // Thread is used here because otherwise it would require // changes in each of election strategy classes which is // unnecessary code coupling.异步解耦 Thread roZkMgr = new Thread() { public void run() { try { // lower-bound grace period to 2 secs sleep(Math.max(2000, tickTime)); if (ServerState.LOOKING.equals(getPeerState())) { roZk.startup(); } } catch (InterruptedException e) { LOG.info("Interrupted while attempting to start ReadOnlyZooKeeperServer, not started"); } catch (Exception e) { LOG.error("FAILED to start ReadOnlyZooKeeperServer", e); } } }; try {// 启动 roZkMgr.start(); reconfigFlagClear(); if (shuttingDownLE) { shuttingDownLE = false; startLeaderElection(); } //设置当前的投票，通过策略模式来决定当前用哪个选举算法来进行领导选举 setCurrentVote(makeLEStrategy().lookForLeader()); } catch (Exception e) { LOG.warn("Unexpected exception", e); setPeerState(ServerState.LOOKING); } finally { // If the thread is in the the grace period, interrupt // to come out of waiting. roZkMgr.interrupt(); roZk.shutdown(); } } else { try { reconfigFlagClear(); if (shuttingDownLE) { shuttingDownLE = false; startLeaderElection(); } setCurrentVote(makeLEStrategy().lookForLeader()); } catch (Exception e) { LOG.warn("Unexpected exception", e); setPeerState(ServerState.LOOKING); } } break; //如果是Observing节点，则只监听leader的数据同步即可 case OBSERVING: try { LOG.info("OBSERVING"); setObserver(makeObserver(logFactory)); observer.observeLeader(); } catch (Exception e) { LOG.warn("Unexpected exception", e); } finally { observer.shutdown(); setObserver(null); updateServerState(); // Add delay jitter before we switch to LOOKING // state to reduce the load of ObserverMaster if (isRunning()) { Observer.waitForObserverElectionDelay(); } } break; //following，则直接查找leader case FOLLOWING: try { LOG.info("FOLLOWING"); setFollower(makeFollower(logFactory)); follower.followLeader(); } catch (Exception e) { LOG.warn("Unexpected exception", e); } finally { follower.shutdown(); setFollower(null); updateServerState(); } break; //leader case LEADING: LOG.info("LEADING"); try { setLeader(makeLeader(logFactory)); leader.lead(); setLeader(null); } catch (Exception e) { LOG.warn("Unexpected exception", e); } finally { if (leader != null) { leader.shutdown("Forcing shutdown"); setLeader(null); } updateServerState(); } break; } } } finally { LOG.warn("QuorumPeer main thread exited"); MBeanRegistry instance = MBeanRegistry.getInstance(); instance.unregister(jmxQuorumBean); instance.unregister(jmxLocalPeerBean); for (RemotePeerBean remotePeerBean : jmxRemotePeerBean.values()) { instance.unregister(remotePeerBean); } jmxQuorumBean = null; jmxLocalPeerBean = null; jmxRemotePeerBean = null; } }
由于是刚刚启动，是 LOOKING 状态。所以走第一条分支。调用 setCurrentVote(makeLEStrategy().lookForLeader());，最终根据上一步选择的策略应该运行 FastLeaderElection 中的选举算法，看一下 lookForLeader（）；
public Vote lookForLeader() throws InterruptedException { //省略部分代码... self.start_fle = Time.currentElapsedTime(); try { // 收到的投票 Map<Long, Vote> recvset = new HashMap<Long, Vote>(); // 存储选举结果 Map<Long, Vote> outofelection = new HashMap<Long, Vote>(); int notTimeout = minNotificationInterval; synchronized (this) { logicalclock.incrementAndGet();//更新逻辑时钟，用来判断是否在同一轮选举周期 //初始化选票数据：这里其实就是把当前节点的myid，zxid，epoch更新到本地的成员属性 updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch()); } LOG.info( "New election. My id = {}, proposed zxid=0x{}", self.getId(), Long.toHexString(proposedZxid)); sendNotifications();//异步发送选举消息 先投自己一票 SyncedLearnerTracker voteSet; //不断循环，根据投票信息进行leader选举 while ((self.getPeerState() == ServerState.LOOKING) && (!stop)) { /* * Remove next notification from queue, times out after 2 times * the termination time */ //从recvqueue中获取消息，也就是说recvqueue中存储了集群中其他节点的投票信息 Notification n = recvqueue.poll(notTimeout, TimeUnit.MILLISECONDS); /* * Sends more notifications if haven't received enough. * Otherwise processes new notification. */ // 如果没有获取到足够的通知久一直发送自己的选票，也就是持续进行选举 if (n == null) { if (manager.haveDelivered()) {//判断发送队列是否有数据，如果发送队列为空，再发一次自己的选票 sendNotifications(); } else {// 消息没发出去，可能其他集群没启动 继续尝试连接 manager.connectAll(); } /* * Exponential backoff *//// 延长超时时间 int tmpTimeOut = notTimeout * 2; notTimeout = Math.min(tmpTimeOut, maxNotificationInterval); LOG.info("Notification time out: {}", notTimeout); // 收到投票消息 查看是否属于本集群内的消息 } else if (validVoter(n.sid) && validVoter(n.leader)) { /* * Only proceed if the vote comes from a replica in the current or next * voting view for a replica in the current or next voting view. */////判断接收到的投票者的状态，默认是LOOKING状态,说明当前发起投票的服务器也是在找leader switch (n.state) { case LOOKING: //忽略zxid=-1的通知 if (getInitLastLoggedZxid() == -1) { LOG.debug("Ignoring notification as our zxid is -1"); break; } if (n.zxid == -1) { LOG.debug("Ignoring notification from member with -1 zxid {}", n.sid); break; } // If notification > current, replace and send messages out // 如果收到的投票的逻辑时钟大于当前的节点的逻辑时钟，那么会更新本机的logicallock // 判断epoch 是否大于 logicalclock ，如是，则是新一轮选举 if (n.electionEpoch > logicalclock.get()) { logicalclock.set(n.electionEpoch);// 更新本地logicalclock recvset.clear();// 清空接受队列 //接收到的投票和当前节点的信息进行比较，比较的顺序epoch、zxid、myid,如果返 回true，则更新当前节点的票据（sid,zxid,epoch）,那么下次再发起投票的时候，就不再是选自己了 if (totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, getInitId(), getInitLastLoggedZxid(), getPeerEpoch())) { updateProposal(n.leader, n.zxid, n.peerEpoch); } else {//否则，表示自己的票据是最新的，则更新自己的票据 updateProposal(getInitId(), getInitLastLoggedZxid(), getPeerEpoch()); }// 继续广播票据，让其他节点知道我现在的投票 sendNotifications(); } else if (n.electionEpoch < logicalclock.get()) {//如果是epoch小于当前 忽略 LOG.debug( "Notification election epoch is smaller than logicalclock. n.electionEpoch = 0x{}, logicalclock=0x{}", Long.toHexString(n.electionEpoch), Long.toHexString(logicalclock.get())); break; //这个判断表示收到的票据的epoch是相同的，那么按照epoch、zxid、myid顺序进 行比较比较成功以后，把对方的票据信息更新到自己的节点 } else if (totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, proposedLeader, proposedZxid, proposedEpoch)) { updateProposal(n.leader, n.zxid, n.peerEpoch); sendNotifications();//再次通知 } LOG.debug( "Adding vote: from={}, proposed leader={}, proposed zxid=0x{}, proposed election epoch=0x{}", n.sid, n.leader, Long.toHexString(n.zxid), Long.toHexString(n.electionEpoch)); // don't care about the version if it's in LOOKING state // //将收到的投票信息放入投票的集合 recvset 中, 用来作为最终的 "过半原则" 判断 recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch)); //获取集群内的所有投票信息 //给定一组投票，返回用于决定是否有足够的凭证宣布选举回合结束。 voteSet = getVoteTracker(recvset, new Vote(proposedLeader, proposedZxid, logicalclock.get(), proposedEpoch)); if (voteSet.hasAllQuorums()) {//是否收到所有的投票确认 // Verify if there is any change in the proposed leader // 在超时时间内等待投票 while ((n = recvqueue.poll(finalizeWait, TimeUnit.MILLISECONDS)) != null) { if (totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, proposedLeader, proposedZxid, proposedEpoch)) { recvqueue.put(n);//将收到的投票信息放入收到的投票队列中重新处理 break; } } /* * This predicate is true once we don't read any new * relevant message from the reception queue *///超时时间(200ms)内未收到新的投票，则投票结束 if (n == null) { //设置当前当前节点的状态（判断leader节点是不是我自己，如果是，直接更新 当前节点的state为LEADING） //否则，根据当前节点的特性进行判断，决定是FOLLOWING还是OBSE //判断当前服务在投票结束后 的服务状态 setPeerState(proposedLeader, voteSet); Vote endVote = new Vote(proposedLeader, proposedZxid, logicalclock.get(), proposedEpoch); leaveInstance(endVote); return endVote;;//返回并发送leanding状态的投票 } } break; case OBSERVING: LOG.debug("Notification from observer: {}", n.sid); break; case FOLLOWING: case LEADING: /* * Consider all notifications from the same epoch * together. *///如果收到的票据的节点状态已经是LEADING或者FOLLOWING（接收的投票信 息已经有leader选举出了） //判断收到的票据的epoch和当前节点是否在同一个周期（接收到消息选出了leader跟本 机是在一个选举时代） if (n.electionEpoch == logicalclock.get()) {// 判断 epoch 是否相同 recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch, n.state)); // //获取收到的投票信息，由于判断是否可以结束投票 voteSet = getVoteTracker(recvset, new Vote(n.version, n.leader, n.zxid, n.electionEpoch, n.peerEpoch, n.state)); //判断是否收到所有的投票，并且判断当前节点是否是leader，如果是，则设置状态并返回 if (voteSet.hasAllQuorums() && checkLeader(recvset, n.leader, n.electionEpoch)) { setPeerState(n.leader, voteSet); Vote endVote = new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch); leaveInstance(endVote); return endVote; } } /* * Before joining an established ensemble, verify that * a majority are following the same leader. * * Note that the outofelection map also stores votes from the current leader election. * See ZOOKEEPER-1732 for more information. *///把收到的票据，保存到outofelection集合中 outofelection.put(n.sid, new Vote(n.version, n.leader, n.zxid, n.electionEpoch, n.peerEpoch, n.state)); //收集票据并保存，用来判断投票结束 voteSet = getVoteTracker(outofelection, new Vote(n.version, n.leader, n.zxid, n.electionEpoch, n.peerEpoch, n.state)); //如果为true，则返回leader的投票信息 if (voteSet.hasAllQuorums() && checkLeader(outofelection, n.leader, n.electionEpoch)) { synchronized (this) { logicalclock.set(n.electionEpoch); setPeerState(n.leader, voteSet); } Vote endVote = new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch); leaveInstance(endVote); return endVote; } break; default: LOG.warn("Notification state unrecoginized: {} (n.state), {}(n.sid)", n.state, n.sid); break; } } else { if (!validVoter(n.leader)) { LOG.warn("Ignoring notification for non-cluster member sid {} from sid {}", n.leader, n.sid); } if (!validVoter(n.sid)) { LOG.warn("Ignoring notification for sid {} from non-quorum member sid {}", n.leader, n.sid); } } } return null; } finally { try { if (self.jmxLeaderElectionBean != null) { MBeanRegistry.getInstance().unregister(self.jmxLeaderElectionBean); } } catch (Exception e) { LOG.warn("Failed to unregister with JMX", e); } self.jmxLeaderElectionBean = null; LOG.debug("Number of connection processing threads: {}", manager.getConnectionThreadCount()); } }
以上代码就是整个选举的核心。
- 首先更新logicalclock并通过 updateProposal 修改自己的选票信息，并且通过 sendNotifications 进行发送选票。
- 进入主循环进行本轮投票。
- 从recvqueue队列中获取一个投票信息，如果没有获取到足够的选票通知一直发送自己的选票，也就是持续进行选举，否则进入步骤4。
- 判断投票信息中的选举状态：
- LOOKING状态：
- 如果对方的Epoch大于本地的logicalclock，则更新本地的logicalclock并清空本地投票信息统计箱recvset，并将自己作为候选和投票中的leader进行比较，选择大的作为新的投票，然后广播出去，否则进入下面步骤2。
- 如果对方的Epoch小于本地的logicalclock，则忽略对方的投票，重新进入下一轮选举流程，否则进入下面步骤3。
- 如果对方的Epoch等于本地的logicalclock，则比较当前本地被推选的leader和投票中的leader，选择大的作为新的投票，然后广播出去。
- 把对方的投票信息保存到本地投票统计箱recvset中，判断当前被选举的leader是否在投票中占了大多数（大于一半的server数量），如果是则需再等待finalizeWait时间（从recvqueue继续poll投票消息）看是否有人修改了leader的候选，如果有则再将该投票信息再放回recvqueue中并重新开始下一轮循环，否则确定角色，结束选举。
- OBSERVING状态：不参与选举。
- FOLLOWING/LEADING：
- 如果对方的Epoch等于本地的logicalclock，把对方的投票信息保存到本地投票统计箱recvset中，判断对方的投票信息是否在recvset中占大多数并且确认自己确实为leader，如果是则确定角色，结束选举，否则进入下面步骤2。
- 将对方的投票信息放入本地统计不参与投票信息箱outofelection中，判断对方的投票信息是否在outofelection中占大多数并且确认自己确实为leader，如果是则更新logicalclock为当前epoch，并确定角色，结束选举，否则进入下一轮选举。
- LOOKING状态：
上述选举中是通过获取到选票，其中根据选票中的3大元素跟本地进行比对。进入 totalOrderPredicate ：
protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch) { LOG.debug("id: " + newId + ", proposed id: " + curId + ", zxid: 0x" + Long.toHexString(newZxid) + ", proposed zxid: 0x" + Long.toHexString(curZxid)); if(self.getQuorumVerifier().getWeight(newId) == 0){ return false; } /*如果以下三种情况之一成立，则返回true: * 1-选票中epoch更高 * 2-选票中epoch与当前epoch相同，但新zxid更高 * 3-选票中epoch与当前epoch相同，新zxid与当前zxid相同服务器id更高。 */ //这里判断规则很明显，先比较epoch 如果相等比较 zxid 继续想等继续比较 myid 大的为leader return ((newEpoch > curEpoch) || ((newEpoch == curEpoch) && ((newZxid > curZxid) || ((newZxid == curZxid) && (newId > curId))))); }
选票方法，便利选票集合，查看是否有人选票超过一半，其实就是判断是否选出了leader：
protected boolean termPredicate(HashMap<Long, Vote> votes,Vote vote) { HashSet<Long> set = new HashSet<Long>(); /* * First make the views consistent. Sometimes peers will have * different zxids for a server depending on timing. */ // 遍历接收到的集合 把符合当前投票的 放入 Set for (Map.Entry<Long,Vote> entry : votes.entrySet()) { if (vote.equals(entry.getValue())){ set.add(entry.getKey()); } } // 统计票据，看是否过半 return self.getQuorumVerifier().containsQuorum(set); }
到这里为止，Leader选举就结束了。流程大致如下：
voteSet.hasAllQuorums() ：用来判断选举是否结束，也就是是否能够得到大于过半节点的ack反馈
public boolean hasAllQuorums() { for (QuorumVerifierAcksetPair qvAckset : qvAcksetPairs) { if (!qvAckset.getQuorumVerifier().containsQuorum(qvAckset.getAckset())) { return false; } } return true; }
投票的网络通信流程：
在QuorumPeer.createElectionAlgorithem这个方法中，在初始化leader选举算法之前，会先构建一个 监听并启动。
QuorumCnxManager.Listener listener = qcm.listener; 启动监听，用于监听每个节点发送的投票请求
Listener集成了Thread这个类，所以start方法会调用重写的run方法。
@Override public void run() { if (!shutdown) { LOG.debug("Listener thread started, myId: {}", self.getId()); Set<InetSocketAddress> addresses; //该参数设置为true，Zookeeper服务器将监听所有可用IP地址的连接。他会影响ZAB协议和快速Leader选举协议。默认是false。 if (self.getQuorumListenOnAllIPs()) { addresses = self.getElectionAddress().getWildcardAddresses(); } else {//监听和选举有关的地址。 addresses = self.getElectionAddress().getAllAddresses(); } CountDownLatch latch = new CountDownLatch(addresses.size()); //遍历所有的address，初始化一个ListenerHandler。 listenerHandlers = addresses.stream().map(address -> new ListenerHandler(address, self.shouldUsePortUnification(), self.isSslQuorum(), latch)) .collect(Collectors.toList()); ExecutorService executor = Executors.newFixedThreadPool(addresses.size()); listenerHandlers.forEach(executor::submit);//通过线程池来分别处理每一个ListenerHandler try { latch.await(); } catch (InterruptedException ie) { LOG.error("Interrupted while sleeping. Ignoring exception", ie); } finally { // 省略部分代码 }
这个时候进入 org.apache.zookeeper.server.quorum.QuorumCnxManager.Listener.ListenerHandler#run
@Override public void run() { try { Thread.currentThread().setName("ListenerHandler-" + address); acceptConnections(); try { close(); } catch (IOException e) { LOG.warn("Exception when shutting down listener: ", e); } } catch (Exception e) { // Output of unexpected exception, should never happen LOG.error("Unexpected error ", e); } finally { latch.countDown(); } }
开启ServerSocket监听，专门用来处理投票请求。 至此，我们知道每个节点在启动的时候，都会启动一个专门处理选举的ServerSocket监听。
我们再来看看消息如何广播，看 sendNotifications：
private void sendNotifications() { for (QuorumServer server : self.getVotingView().values()) {// 循环发送 long sid = server.id; // 准备发送的消息实体 ToSend notmsg = new ToSend(ToSend.mType.notification, proposedLeader, proposedZxid, logicalclock.get(), QuorumPeer.ServerState.LOOKING, sid, proposedEpoch); if(LOG.isDebugEnabled()){ LOG.debug("Sending Notification: " + proposedLeader + " (n.leader), 0x" + Long.toHexString(proposedZxid) + " (n.zxid), 0x" + Long.toHexString(logicalclock.get()) + " (n.round), " + sid + " (recipient), " + self.getId() + " (myid), 0x" + Long.toHexString(proposedEpoch) + " (n.peerEpoch)"); } sendqueue.offer(notmsg); // 使用offer 添加到队列 会被sendWorker线程消费 } }
票据的通信流程大致如下图所示：
WorkerSender 这里有一个现成，会专门从sendqueue中获取需要发送的消息，然后进行处理。 很显然，这里又是一个生产者消费者模型。
public void run() { while (!stop) { try { ToSend m = sendqueue.poll(3000, TimeUnit.MILLISECONDS); if (m == null) { continue; } process(m); // 发送票据 } catch (InterruptedException e) { break; } } LOG.info("WorkerSender is down"); }
QuorumCnxManager.toSend
public void toSend(Long sid, ByteBuffer b) { /* * If sending message to myself, then simply enqueue it (loopback). */ if (this.mySid == sid) {//如果接受者是自己，直接放置到接收队列 b.position(0); addToRecvQueue(new Message(b.duplicate(), sid)); /* * Otherwise send to the corresponding thread to send. */ } else {//否则发送到对应的发送队列上 /* * Start a new connection if doesn't have one already. *///判断sid是否已经存在于该发送队列 BlockingQueue<ByteBuffer> bq = queueSendMap.computeIfAbsent(sid, serverId -> new CircularBlockingQueue<>(SEND_CAPACITY)); addToSendQueue(bq, b);//添加到发送队列 connectOne(sid);//发起连接 } }
connectOne 首先从senderWorkerMap中获取，是否已经连接过这个id的服务
synchronized void connectOne(long sid) { if (senderWorkerMap.get(sid) != null) { {//首先从senderWorkerMap中获取sid来判断是否已经连接过这个id的服务 LOG.debug("There is a connection already for server {}", sid); if (self.isMultiAddressEnabled() && self.isMultiAddressReachabilityCheckEnabled()) { // since ZOOKEEPER-3188 we can use multiple election addresses to reach a server. It is possible, that the // one we are using is already dead and we need to clean-up, so when we will create a new connection // then we will choose an other one, which is actually reachable senderWorkerMap.get(sid).asyncValidateIfSocketIsStillReachable(); } return; }//如果没有会去调用QuorumCnxManager#connectOne(long, java.net.InetSocketAddress)方法去连接 synchronized (self.QV_LOCK) { boolean knownId = false; // Resolve hostname for the remote server before attempting to // connect in case the underlying ip address has changed. self.recreateSocketAddresses(sid); Map<Long, QuorumPeer.QuorumServer> lastCommittedView = self.getView(); QuorumVerifier lastSeenQV = self.getLastSeenQuorumVerifier(); Map<Long, QuorumPeer.QuorumServer> lastProposedView = lastSeenQV.getAllMembers(); if (lastCommittedView.containsKey(sid)) { knownId = true; LOG.debug("Server {} knows {} already, it is in the lastCommittedView", self.getId(), sid); if (connectOne(sid, lastCommittedView.get(sid).electionAddr)) { return; } } if (lastSeenQV != null && lastProposedView.containsKey(sid) && (!knownId || !lastProposedView.get(sid).electionAddr.equals(lastCommittedView.get(sid).electionAddr))) { knownId = true; LOG.debug("Server {} knows {} already, it is in the lastProposedView", self.getId(), sid); if (connectOne(sid, lastProposedView.get(sid).electionAddr)) { return; } } if (!knownId) { LOG.warn("Invalid server id: {} ", sid); } } }
调用链路， connectOne->initiateConnectionAsync->QuorumConnectionReqThread.run ->org.apache.zookeeper.server.quorum.QuorumCnxManager#startConnection
- 首先向选举地址发送自己id和消息类型
- 再判断如果选举的id比自己大，关闭不建立连接
- 否则，将sid与SendWorker放入senderWorkerMap，表示已经建立过连接了，sid和 ArrayBlockingQueue放入queueSendMap，对于要发送到该sid服务的消息，都往这 queueSendMap中放，再开启SendWorker RecvWorker线程。
private boolean startConnection(Socket sock, Long sid) throws IOException { DataOutputStream dout = null; DataInputStream din = null; LOG.debug("startConnection (myId:{} --> sid:{})", self.getId(), sid); try { // Use BufferedOutputStream to reduce the number of IP packets. This is // important for x-DC scenarios. BufferedOutputStream buf = new BufferedOutputStream(sock.getOutputStream()); dout = new DataOutputStream(buf); // Sending id and challenge // First sending the protocol version (in other words - message type). // For backward compatibility reasons we stick to the old protocol version, unless the MultiAddress // feature is enabled. During rolling upgrade, we must make sure that all the servers can // understand the protocol version we use to avoid multiple partitions. see ZOOKEEPER-3720 long protocolVersion = self.isMultiAddressEnabled() ? PROTOCOL_VERSION_V2 : PROTOCOL_VERSION_V1; dout.writeLong(protocolVersion); dout.writeLong(self.getId()); // now we send our election address. For the new protocol version, we can send multiple addresses. Collection<InetSocketAddress> addressesToSend = protocolVersion == PROTOCOL_VERSION_V2 ? self.getElectionAddress().getAllAddresses() : Arrays.asList(self.getElectionAddress().getOne()); String addr = addressesToSend.stream() .map(NetUtils::formatInetAddr).collect(Collectors.joining("|")); byte[] addr_bytes = addr.getBytes(); dout.writeInt(addr_bytes.length); dout.write(addr_bytes); dout.flush(); din = new DataInputStream(new BufferedInputStream(sock.getInputStream())); } catch (IOException e) { LOG.warn("Ignoring exception reading or writing challenge: ", e); closeSocket(sock); return false; } // authenticate learner QuorumPeer.QuorumServer qps = self.getVotingView().get(sid); if (qps != null) { // TODO - investigate why reconfig makes qps null. authLearner.authenticate(sock, qps.hostname); } // If lost the challenge, then drop the new connection // 再判断如果选举的id比自己大，关闭不建立连接 if (sid > self.getId()) { LOG.info("Have smaller server identifier, so dropping the connection: (myId:{} --> sid:{})", self.getId(), sid); closeSocket(sock); // Otherwise proceed with the connection } else { LOG.debug("Have larger server identifier, so keeping the connection: (myId:{} --> sid:{})", self.getId(), sid); //SendWorker 会监听对应sid的阻塞队列，启动的时候回如果队列为空时会重新发送一次最前最后的消息，以防上一次处理是服务器异常退出，造成上一条消息未处理成功；然后就是不停监听队里，发现有消息时调用send方法 //RecvWorker：RecvWorker不停监听socket的inputstream，读取消息放到消息接收队列中,消息放入队列中，qcm的流程就完毕了 SendWorker sw = new SendWorker(sock, sid); RecvWorker rw = new RecvWorker(sock, din, sid, sw); sw.setRecv(rw); SendWorker vsw = senderWorkerMap.get(sid); if (vsw != null) { vsw.finish(); } senderWorkerMap.put(sid, sw); queueSendMap.putIfAbsent(sid, new CircularBlockingQueue<>(SEND_CAPACITY)); sw.start(); rw.start(); return true; } return false; }
节点接收数据投票: ListenerHandler-> acceptConnections-> receiveConnection -> handleConnection
选举完成之后的处理逻辑:
通过lookForLeader方法选举完成以后，会设置当前节点的PeerState，要么为Leading、要么就是 FOLLOWING、或者OBSERVING 到这里，只是表示当前的leader选出来了，但是QuorumPeer.run方法里面还没执行完，我们再回过头 看看后续的处理过程
分别来看看case 为FOLLOWING和LEADING，会做什么事情
FOLLOWING : 构建一个FollowerZookeeperServer，表示follower节点的请求处理服务.调用 follower.followLeader();
void followLeader() throws InterruptedException { self.end_fle = Time.currentElapsedTime(); long electionTimeTaken = self.end_fle - self.start_fle; self.setElectionTimeTaken(electionTimeTaken); ServerMetrics.getMetrics().ELECTION_TIME.add(electionTimeTaken); LOG.info("FOLLOWING - LEADER ELECTION TOOK - {} {}", electionTimeTaken, QuorumPeer.FLE_TIME_UNIT); self.start_fle = 0; self.end_fle = 0; fzk.registerJMX(new FollowerBean(this, zk), self.jmxLocalPeerBean); long connectionTime = 0; boolean completedSync = false; try { self.setZabState(QuorumPeer.ZabState.DISCOVERY); //根据sid找到对应leader，拿到lead连接信息 QuorumServer leaderServer = findLeader(); try {//连接到Leader connectToLeader(leaderServer.addr, leaderServer.hostname); connectionTime = System.currentTimeMillis(); //将Follower的zxid及 myid 等信息封装好发送到Leader，同步epoch。 //也就是意味着接下来follower节点只同步新epoch的数据信息 long newEpochZxid = registerWithLeader(Leader.FOLLOWERINFO); if (self.isReconfigStateChange()) { throw new Exception("learned about role change"); } //check to see if the leader zxid is lower than ours //this should never happen but is just a safety check long newEpoch = ZxidUtils.getEpochFromZxid(newEpochZxid); //如果leader的epoch比当前follow节点的poch还小，抛异常 if (newEpoch < self.getAcceptedEpoch()) { LOG.error("Proposed leader epoch " + ZxidUtils.zxidToString(newEpochZxid) + " is less than our accepted epoch " + ZxidUtils.zxidToString(self.getAcceptedEpoch())); throw new IOException("Error: Epoch of leader is lower"); } long startTime = Time.currentElapsedTime(); try { self.setLeaderAddressAndId(leaderServer.addr, leaderServer.getId()); self.setZabState(QuorumPeer.ZabState.SYNCHRONIZATION); syncWithLeader(newEpochZxid);//和leader进行数据同步 //设置zab协议状态为原子广播 self.setZabState(QuorumPeer.ZabState.BROADCAST); completedSync = true; } // 省略。。。。。 }
LEADING : 初始化一个Leader对象，构建一个LeaderZookeeperServer，用于表示leader节点的请求处理服务.调用 leader.lead();
其实在这个投票过程中就涉及到几个类，FastLeaderElection：FastLeaderElection 实现了 Election 接口，实现各服务器之间基于 TCP 协议进行选举Notification：内部类，Notification 表示收到的选举投票信息（其他服务器发来的选举投票信息），其包含了被选举者的 id、zxid、选举周期等信息ToSend：ToSend表示发送给其他服务器的选举投票信息，也包含了被选举者的 id、zxid、选举周期等信息Messenger ： Messenger 包 含 了 WorkerReceiver 和WorkerSender 两个内部类；WorkerReceiver 实现了 Runnable 接口，是选票接收器。其会不断地从 QuorumCnxManager 中获取其他服务器发来的选举消息，并将其转换成一个选票，然后保存到recvqueue 中WorkerSender 也实现了 Runnable 接口，为选票发送器，其会不断地从 sendqueue 中获取待发送的选票，并将其传递到底层 QuorumCnxManager 中。其中 cnxnFactory.start(); 就是启动了服务端的接受请求的线程，默认实现有两个 NIO 及 Netty:
至于怎么设置请看如下代码：
//这个是我们需要配置的属性key
public static final String ZOOKEEPER_SERVER_CNXN_FACTORY = "zookeeper.serverCnxnFactory";
static public ServerCnxnFactory createFactory() throws IOException {
String serverCnxnFactoryName =
System.getProperty(ZOOKEEPER_SERVER_CNXN_FACTORY);
if (serverCnxnFactoryName == null) {//默认是NIO
serverCnxnFactoryName = NIOServerCnxnFactory.class.getName();
}
try {//这里配置的类即Netty
ServerCnxnFactory serverCnxnFactory = (ServerCnxnFactory) Class.forName(serverCnxnFactoryName)
.getDeclaredConstructor().newInstance();
LOG.info("Using {} as server connection factory", serverCnxnFactoryName);
return serverCnxnFactory;
} catch (Exception e) {
IOException ioe = new IOException("Couldn't instantiate "
+ serverCnxnFactoryName);
ioe.initCause(e);
throw ioe;
}
}
其他详细信息请参考源码。
