zk快照机制

对于客户端的请求，zk会使用链式的处理器，链式处理器中其中有一个

SyncRequestProcessor，用于将请求持久化

持久化分为两种

事务日志的追加
快照文件

每个请求都会立刻写入事务日志中，

使用的是ZKDatabase.append(Request)

但并不是所有的请求都需要记录到事务日志，例如读请求，没有事务头，则不会记录

由于生成快照耗费的资源更多，时间更久，因此快照的生成是有策略的，并不像事务日志一样，每个事务请求都立刻记录。

    private boolean shouldSnapshot() {
        int logCount = zks.getZKDatabase().getTxnCount();
        long logSize = zks.getZKDatabase().getTxnSize();
        return (logCount > (snapCount / 2 + randRoll))
               || (snapSizeInBytes > 0 && logSize > (snapSizeInBytes / 2 + randSize));
    }

是否进行快照，有两个条件，满足一个即可

事务日志的数量
事务的大小

这两个配置项，在官方文档中也有提及

zookeeper.snapCount : 默认值为100000，最小为2
zookeeper.snapSizeLimitInKb : 默认值为4194304，也就是4GB，必须大于0

但是上面的代码里，为啥判断条件的时候都增加了一个随机值呢，即randRoll和randSize，看一下它俩的来源

    
    private int randRoll;
    private long randSize;
    
    
		randRoll = ThreadLocalRandom.current().nextInt(snapCount / 2);
    randSize = Math.abs(ThreadLocalRandom.current().nextLong() % (snapSizeInBytes / 2));

看注释这两个随机数就是用来打乱快照的生成的时机的。但是为啥要这么做呢？

前面提到生成快照是个耗时的事，从下面的代码不难发现

进行快照前，会先对事务日志滚动，生成一个新的事务日志文件供后续使用
然后单独起一个线程进行快照

不论是日志滚动还是创建线程都是一个耗时耗资源的操作，试想一下，如果没有这两个随机值，在集群结构下，集群中的各个节点可能会因为某一个写请求，全部都在处理快照，一个请求就会引起整个集群压力上升，从而可能导致这个请求超时。当然可能情况也没有这么严重。

但通过加一个随机值，就可以分散集群中的各个节点的快照时机，这个优化思路还是很值得我们借鉴的。

zk的bug

不过在一次事故中，我无意发现了一个关于事务的问题（zk版本3.4.x），先看改动吧

这个方法就是zkDatabase.append，看下javadoc它的功能就是说，将事务请求追加到事务日志中，如果追加成功，返回true，否则false。

改动其实很简单，原来的逻辑忽略了请求是否成功追加到事务日志，对事务的计数直接加1了，这就有可能导致，大量的读请求也会触发快照的生成。

zk快照机制

Java相关栏目本月热门文章