提一个问题先

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

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

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

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

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

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

2^32/(86400∗1000) ≈ 49.7

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

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

    /**
     * create a proposal and send it out to all the members
     *
     * @param request
     * @return the proposal that is queued to send to all the members
     */
    public Proposal propose(Request request) throws XidRolloverException {        /**
         * Address the rollover issue. All lower 32bits set indicate a new leader
         * election. Force a re-election instead. See ZOOKEEPER-1277
         */
        if ((request.zxid & 0xffffffffffL) == 0xffffffffffL) {
            String msg =                    "zxid lower 32 bits have rolled over, forcing re-election, and therefore new epoch start";
            shutdown(msg);            throw new XidRolloverException(msg);
        }

从上面的代码可以看到，

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

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

如何解决？

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

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

我们再来算一下：

2^40/(86400∗1000) ≈ 12725.8  即 12725.8/365 ≈ 34.9 年

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 位，可能会存在并发的问题。

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

 Iterator<Integer> iterator = servers.iterator();                  long zxid = Long.valueOf(m.group(2));                  int count = (int)zxid;// & 0xFFFFFFFFL;
                  int epoch = (int)Long.rotateRight(zxid, 32);// >> 32;

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

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

如何修改

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

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

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

 Iterator<Integer> iterator = servers.iterator();            long zxid = Long.valueOf(m.group(2));         // int count = (int)zxid;// & 0xFFFFFFFFL;
         // int epoch = (int)Long.rotateRight(zxid, 32);// >> 32;
            long count = zxid & 0xffffffffffL;            int epoch = (int)Long.rotateRight(zxid, 40);// >> 40;

后面还有多处类似的地方要修改，就不一一列出来了，有兴趣的可以看这里github

作者：大叔据
链接：https://www.jianshu.com/p/cbeaf9d0026a

zookeeper篇(7)-如何修改源码

提一个问题先

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

如何解决？

还有一个担心

如何修改