TiDB中的混沌测试实践

什么是混沌

\\

在分布式计算领域，我们无法预测集群将会发生什么，一切皆有可能。在里约热内卢飘舞的蝴蝶可能会改变芝加哥的气候，甚至摧毁位于开罗的数据中心。网络时间协议（NTP）可能出现不同步，CPU可能会无缘无故地爆表，或更糟糕的是，勤劳的DBA可能会在半夜意外地删除数据。

\\

TiDB是一款开源的分布式NewSQL混合事务/分析处理（HTAP）数据库，其中保存了客户最重要的数据资产。对于我们的系统来说，容错是最基本和最重要的需求之一。但如何保证分布式数据库的容错？在本文中，我将介绍混沌工程的故障注入工具和技术，以及我们在TiDB中的混沌实践。

\\

为什么我们需要混沌

\\

自从2011年Netflix开发了Chaos Monkey以来，这款软件变得越来越流行。如果想要构建一个分布式系统，就让Chaos Monkey来“糟蹋”这个集群，这样有助于构建出一个更具容错性、弹性和可靠性的系统。

\\

通常情况下，我们会尽可能多地编写单元测试，确保能够覆盖所有的代码逻辑，也会进行足够多的集成测试，确保我们的系统可以与其他组件一起工作，还会执行性能测试，用以改进处理数百万次请求的性能。

\\

然而，这些对于分布式系统来说还远远不够。无论我们做了多少单元测试、集成测试或性能测试，仍然无法保证我们的系统能够应对生产环境的各种不可预测性。我们可能会遇到磁盘故障、机器断电、网络隔离，而这些只是冰山一角。为了让分布式系统（如TiDB）更加健壮，我们需要一种方法来模拟不可预知的故障，并测试我们对这些故障的反应。这就是为什么我们需要Chaos Monkey。

\\

制造“混沌”

\\

Netflix不仅发明了混沌，而且还引入了“混沌工程”的概念，这是一种用于揭示系统缺陷的系统性方法。混沌工程有它自己的核心原则，市面上还有一本关于混沌工程的书：《Building Confidence in System Behavior through Experiments》。

\\

在TiDB中，我们应用混沌工程来观察系统的状态、做出假设、进行实验，并用真实结果验证这些假设。除了遵循混沌原则，我们也会加入自己的想法。这是我们的五步混沌法：

\\

1. 使用Prometheus作为监控工具来观察TiDB集群的状态和行为，并收集集群的度量指标，用以确定一个稳定的系统应该是什么样的。\\t
2. 列出一些失败性的假设以及我们的预期。以TiDB为例：如果我们从集群中分离出一个TiKV（TiDB的分布式键值存储层）节点，那么QPS（每秒查询次数）应该会下降，但很快会恢复到另一个稳定状态。\\t
3. 从列表中选择一个假设。\\t
4. 通过注入故障和分析结果对所选的假设进行实验。如果结果与我们的假设不同，则可能（或必然）出现错误或遗漏。\\t
5. 从列表中选择另一个假设进行实验，并重复及自动化这一过程。\

在生产环境中运行实验是混沌工程的原则之一。在为我们的用户部署TiDB之前，我们必须确保它已经经过了严格的测试。不过，我们不能在客户的生产环境中运行这些实验，因为他们把最关键的数据放在TiDB中，表示他们对TiDB的信任，所以我们不能破坏这种来自不易的信任。 我们能做的是建立我们自己的“战场”——一个内部生产环境。

\\

目前，我们使用Jira进行内部问题跟踪和项目管理，同时使用了TiDB作为数据存储，可以说，我们是在自食其力。我们可以在Jira上运行混沌实验。当我们的员工在日常工作中使用Jira时，在没有事先发出任何警告的情况下，向Jira系统注入各种故障，用以模拟一系列级联“事故”来识别可能的系统漏洞。我们称这种做法为“军事演习”，并且经常在我们的日常运维中做这样的事情。在下面的章节中，我将介绍我们如何进行故障注入并自动化这一过程。

\\

TiDB如何进行故障注入

\\

故障注入是一种通过引入故障来测试代码路径（尤其是处理错误的代码路径ÿ