分布式系统一致性测试框架 Jepsen 在女娲的实践应用

女娲团队在过去大半年时间里持续投入女娲2.0研发，将一致性引擎和业务状态机解耦，一致性引擎可支持Paxos、Raft、EPaxos等多种一致性协议，根据业务需求支撑不同的业务状态机。其中的一致性引擎模块是关键，研发一致性引擎时，保证一致性引擎的正确性是一大挑战，所以我们用了TLA+、Jepsen等工具保证一致性引擎的正确性。这里分享一些Jepsen应用方面的体会。

目前网上已经有了对于Jepsen的介绍，比如《Jepsen测试》《当 Messaging 遇上 Jepsen》,从原理和用法都有详尽的说明，做到了致广大而尽细微。大家可以先阅读这些文章，对Jepsen有一个全面的了解，也可以在某些细节没搞懂时去看看文章中详细的阐述。本文相当于是摘要、总结和补充，一方面给大家对Jepsen的一个直观的认识，一方面通过介绍女娲在使用Jepsen时的例子，实际说明Jepsen的作用与特点，给大家实践过程中使用Jepsen一些参考。

这里我们按照本质、结构、作用 的顺序简明地描述Jepsen。

一 本质——只看Jepsen的特色

在分布式系统的测试领域，最耳熟能详的两大工具，就是TLA+和Jepsen了，其关系类似于演绎与归纳，白盒与黑盒。TLA+要求编写测试的人能够真实地抽象出需要验证的分布式系统，在每一个细微的逻辑部分做到对真实系统精炼而准确的还原，而后对这个抽象系统在各种状态空间进行遍历，如果验证抽象系统始终满足定义的规则，则可推断并保证真实系统的正确性，就好比有了一份关键信息详实的地图，在地图上画通了路线图，真实世界按路线走也可以走到终点。Jepsen则是从系统对外提供的接口入手，通过实际构建系统、进行操作、注入错误、验证结果这一系列在错误注入情况下对系统行为的演练和分析，真实地撞出不符合既定规则的情况，通过对历史记录的分析找到这些情况，好比造出了一大堆散乱的拼图，各种尝试，最后验证能不能拼成一个合理而规则的图形。

由此我们不难看出两者的难点。TLA+的难点在演绎的正确性，用TLA+写的模型，前提是抽象系统与真实系统关键部分实现都要完全符合，如果与工程实现不符，就会导致一些真实系统中可能会遇到的问题不能被验证到。而Jepsen最大的难点，则是根据搜集测试用例中的历史记录，如何归纳出系统是否出现相应的错误，而且归纳本身特点也决定，Jepsen测试不能涵盖所有异常情况。在这个归纳的过程中，线性一致性是最难归纳验证的，系统线性一致性的验证也是Jepsen最大特色。

图1. Jepsen提供的一致性验证能力

一句话总结：Jepsen ≈ 多进程测试程序 + 线性一致性验证

• 多进程测试程序是为了生成系统在各种情况下的操作记录，线性一致性验证则是对操作记录的检查。Jepsen是黑盒测试，通过在一个节点上起多个Client线程，对待测试系统发送各种请求，然后搜集请求结果，以此构建各个请求操作的记录。我们一般对系统都会有类似测试，相比而言，Jepsen增加了把操作记录组织为History供后继分析这一部分。
• 线性一致性验证是Jepsen同Failover测试最大的差异。Jepsen中虽然可以进行其他非线性一致性的验证，但这些测试相对线性一致性的验证会比较简单直观，所以这里主要详细阐述线性一致性验证，其中相关的两个关键问题：

什么是线性一致性

各种不同系统的验证如何统一为线性一致性的验证。

1 线性一致性</