×

完善 Chaos 的线性一致性测试

96
siddontang 595a1b60 08f6 4beb 998f 2bf55e230555
2018.05.26 09:50 字数 1333

在之前的文章里面,我提到我用 Go 写了一个类似 Jepsen 的工具 - Chaos ,里面我使用的是 Porcupine 来进行的线性一致性测试,但 Porcupine 并不能长时间执行,因为它要解决的是一个 NP hard 的问题,如果要验证的 history 太多,会算不出来,在我们 128 GB 机器上面,如果 history 有 2000 条,验证线性一致性的时候就容易 OOM 了。

虽然之前看过一篇论文,Why Is Random Testing Effective for Partition Tolerance Bugs?,里面提到通过设计合理的测试用例,我们是能有很大概率去发现系统的问题的,但我仍然希望我们的测试能跑的久一点,能有更多的 history,这样没准能发现更多的 bug。

一个可能的办法就是固定一个测试场景,然后跑多次,这样比较简单,但因为每次重跑集群都是新做的,重做集群会有一部分时间开销,等的有点不爽。另外,仍然是跑的时间太短,对于 TiDB 整个集群来说,一些调度可能都还没开始就结束了,其实并不能很好的发现 bug。

于是就想到一个可行的办法,引入中间状态。怎么说呢,对于 Procupline,它的验证其实仍然是基于状态机的模型,给定一个初始状态,然后开始迭代,每次迭代会根据测试程序的输入输出来生成下一个状态,然后在验证下一个状态是不是符合预期,满足线性一致性。对于 Chaos 来说,我们是有 5 个 client 来并发的给 TiDB 发送命令测试的。那么,我们其实可以做到,先让 5 个 client 处理 1000 个请求,然后我们得到一个中间状态,生成一个新的 history,再继续。那么对于 Porcupine 来说,每一个 history 其实就是一个新的模型验证了,然后初始化的状态机就是 history 开始的中间状态。

以我们现在的转账为例子,5 个用户依次转账,最开始每人初始金额是 1000 块钱,然后执行 1000 次,这时候我们暂停测试,得到 5 个人现在的金额,当成下一次测试的初始状态,继续开始。可以看到,通过这样的方式,我们就能在测试的时候一直进行线性一致性判断了。每次跑 1000 条测试,生成一个 history,异步给 Porcupine 验证,同时继续下一次测试。

这个改动也是很容易的,在 history 的第一行记录下初始状态机,然后根据这个来创建 Porcupine 的 model 就可以了。如果你对这个感兴趣,欢迎提 PR。

当然,我们可以更进一步。这个是我在跟 FoundationDB 的 Alex 讨论的时候想到的,无论对于 Jepsen 的 Knossos 还是 Chaos 的 Porcupine,它其实是一个通用的线性一致性测试框架,是把整个测试服务当成黑盒来判断的,但实际上,我们对于自己的服务,是有着清晰的认识的,也就是,我们其实能写一个针对我们自己服务,专用的线性一致性测试框架。

对于 TiDB 来说,我们能够确定,任何的事务都是有唯一的时间戳,而这个时间戳是一定单调递增的,所以我们只要把我们的事务按照时间戳排序,然后在依次 replay,那么我们就能知道我们的系统是不是线性一致的。举个例子,譬如转账,在 T1 时候,用户 1 和 2 都是 1000 块钱,然后 1 给 2 转了 100,在 T3 的时候我们知道事务成功,那么 1 就是 900, 2 就是 1100。在 T2 (T1 < T2 < T3)的时候,我们可能会读出来 1000,也可能会读出来 1100,但一定不会读出来其他的值。如果在 T2 的时候,我们读出来是 1100 了,那么就意味着前一个转账的事务一定成功了,那么在 T2 之后,只能读出来 1100, 不能在读出来 1000 了。

因为这个线性验证是跟我们自己的实现强相关的,所以写出来就非常容易了,而且也不用处理那么多的分支情况,自然就能长时间运行跑了。当然,现在我只是简单的实现了一个 demo,算是验证了一下,还有很多东西需要完善,譬如我现在只考虑了全局的时序一致,其实也可以把单个客户端的顺序一致也考虑进来。如果你对这块感兴趣,欢迎提 PR,或者邮箱联系 tl@pingcap.com

编程之路
编程之路
20.8万字 · 39.8万阅读 · 199人关注
Web note ad 1