Zookeeper：一个改源码的例子

本篇文章仅仅是起一个抛砖迎玉的作用，举一个如何修改源码的例子。文章的灵感来自 ZOOKEEPER-2784。

之前的文章讲过zxid的设计，我们先复习下：

zxid有64位，分成两部分： 高32位是Leader的epoch：选举时钟，每次选出新的Leader，epoch累加1 低32位是在这轮epoch内的事务id：对于用户的每一次更新操作集群都会累加1。

这么设计会存在什么问题？

Zookeeper 的事务 ID 有可能会超过 32 位。

epoch增长非常慢，超过32位需要非常久的时间，几乎可以忽略这个问题，但是事务 ID 似乎不行。我们来算下。

如果我们每秒钟操作1000次 Zookeeper ，即 1k/s ops，那么

49.7天后，事务 ID 就将溢出，那溢出会发生什么，看代码：

src/java/main/org/apache/zookeeper/server/quorum/Leader.java line1037

从上面的代码可以看到，

Zookeeper 的 Leader 节点会throw new XidRolloverException(msg) 强制进行 re-election重新选举，

即服务会停止一段时间，在一些场景下，这种情况过于频繁是不能容忍的，那我们来看看如何解决。

如何解决？

上面说了epoch增长速度慢到可以忽略它溢出的问题，那么可以重新设计 ZXID，

设计成高 24 位用于 epoch，低 40 位用于 事务 ID 增长。

我们再来算一下：

1k/s ops 的情况下， 34.9 年之后才会进行一次强制选举。

设想不错，可以解决我们的问题，那我们继续。

还有一个担心

从操作系统的底层来说，对于32位操作系统，单次操作能处理的最长长度为32bit，而long类型8字节64bit，所以对long的读写都要两条指令才能完成（即每次读写64bit中的32bit）。

为什么说这个，因为也许有人会把这个和 ZXID 的设计联想起来，上面的 ZOOKEEPER-2784里面也提到了这个问题。

However, i thought the ZXID is long type, reading and writing the long type (and double type the same) in JVM, is divided into high 32bit and low 32bit part of the operation, and because the ZXID variable is not modified with volatile and is not boxed for the corresponding reference type ( Long / Double ), so it belongs to [non-atomic operation]

我大概翻译一下：

ZXID 是 long 类型，32 bit 的 JVM 在对 long 读写时（和 double 类型一样），是分为高 32 位和 低 32 位两部分进行操作的，由于 ZXID 变量没有用 volatile 修饰，且也没有装箱为对应的引用类型（Long / Double），属于非原子操作。

这位老哥担心对 ZXID 重新设计时把高 32 位和 低 32 位改成高 24 位和 低 40 位，可能会存在并发的问题。

会不会有这个问题，我们先来看看源码：

注意这个 & 0xFFFFFFFFL ，实际上后面的代码还有很多这种 按位与 的操作，就不贴出来了。

翻了这一块的源码就可以知道，这个担心是多余的，关于ZXID的所有操作都是位操作而不是“=”的赋值操作，它不会造成JVM级别的并发问题。

如何修改

接下来我们就用源码中“位与”的方式，把 32 为改成 40 位。

即：zxid按位于（&）0xffffffffffL（40位）获得zxid的后40位。

注意要把count之前的int类型改为long类型，因为int为32bit，long为64bit，此时count有40位所以换成long。

后面还有多处类似的地方要修改，就不一一列出来了，公众号文章不支持打开外部链接，有兴趣的可以点阅读原文看完整内容。

zookeeper篇到这里就完结了，关于zookeeper大家还有什么想知道的可以留言，我觉得有价值的话会再更新些新的文章。