TiKV 源码解析系列文章（五）fail-rs 介绍

本文为 TiKV 源码解析系列的第五篇，为大家介绍 TiKV 在测试中使用的周边库 fail-rs 。

fail-rs 的设计启发于 FreeBSD 的 failpoints ，由 Rust 实现。通过代码或者环境变量，其允许程序在特定的地方动态地注入错误或者其他行为。在 TiKV 中通常在测试中使用 fail point 来构建异常的情况，是一个非常方便的测试工具。

Fail point 需求

在我们的集成测试中，都是简单的构建一个 KV 实例，然后发送请求，检查返回值和状态的改变。这样的测试可以较为完整地测试功能，但是对于一些需要精细化控制的测试就鞭长莫及了。我们当然可以通过 mock 网络层提供网络的精细模拟控制，但是对于诸如磁盘 IO、系统调度等方面的控制就没办法做到了。

同时，在分布式系统中时序的关系是非常关键的，可能两个操作的执行顺行相反，就导致了迥然不同的结果。尤其对于数据库来说，保证数据的一致性是至关重要的，因此需要去做一些相关的测试。

基于以上原因，我们就需要使用 fail point 来复现一些 corner case，比如模拟数据落盘特别慢、raftstore 繁忙、特殊的操作处理顺序、错误 panic 等等。

基本用法

示例

在详细介绍之前，先举一个简单的例子给大家一个直观的认识。

还是那个老生常谈的 Hello World：

#[macro_use]
extern crate fail;

fn say_hello() {
    fail_point!(“before_print”);
    println!(“Hello World~”);
}

fn main() {
    say_hello();
    fail::cfg("before_print", "panic");
    say_hello();
}

运行结果如下：

Hello World~
thread 'main' panicked at 'failpoint before_print panic' ...

可以看到最终只打印出一个 Hello World～，而在打印第二个之前就 panic 了。这是因为我们在第一次打印完后才指定了这个 fail point 行为是 panic，因此第一次在 fail point 不做任何事情之后正常输出，而第二次在执行