在之前的文章里面，我提到我用 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。