4.检查器
正确性校验
通过生成器和客户端执行一些操作，我们获取到了用于分析正确性的历史记录。Jepsen使用model代表系统的抽象行为，checker来验证历史记录是否符合该模型。我们需要knossos.model和jepsen.checker：
(ns jepsen.etcdemo
(:require [clojure.tools.logging :refer :all]
[clojure.string :as str]
[jepsen [checker :as checker]
[cli :as cli]
[client :as client]
[control :as c]
[db :as db]
[generator :as gen]
[tests :as tests]]
[jepsen.control.util :as cu]
[jepsen.os.debian :as debian]
[knossos.model :as model]
[slingshot.slingshot :refer [try+]]
[verschlimmbesserung.core :as v]))还记得我们如何构建读、写和cas操作吗？
(defn r [_ _] {:type :invoke, :f :read, :value nil})
(defn w [_ _] {:type :invoke, :f :write, :value (rand-int 5)})
(defn cas [_ _] {:type :invoke, :f :cas, :value [(rand-int 5) (rand-int 5)]})Jepsen并不知道:f :read或:f :cas的含义，就其而言,他们可以是任意值。然而，当它基于(case (:f op) :read ...)进行控制流转时，我们的client知道如何解释这些操作。现在，我们需要一个能够理解这些相同操作的系统模型。Knossos已经为我们定义好了模型数据类型，它接受一个模型或者操作作为输入进行运算，并返回该操作产生的新模型。knossos.model内部代码如下：
结果发现Knossos检查器为锁和寄存器等东西定义了一些常见的模型。下面的内容是一个cas寄存器--正是我们需要建模的数据类型
只要knossos为我们正在检测的组件提供了模型，我们就不需要在测试中写cas寄存器。这只是为了你可以看到表面上一切顺利，其实是依靠底层怎么运行的。
此defrecord定义了一个名为CASRegister的新的数据类型，它拥有唯一不变的字段，名为value。它实现了我们之前讨论的Model接口，它的step函数接收当前寄存器r和操作op作为参数。当我们需要写入新值时，只需要简单返回一个已经赋值的CASRegister。为了对两个值进行cas，我们在操作中将当前值和新值分开，如果当前值和新值相匹配，则构建一个带有新值的寄存器。如果它们不匹配，则返回带有inconsistent的特定的模型类型，它表明上一操作不能应用于寄存器。读操作也是类似，除了我们始终允许读取到nil这一点。这允许我们有从未返回过的读操作历史。
为了分析历史操作，我们需要为测试定义一个:checker，同时需要提供一个:model来指明系统应该如何运行。
checker/linearizable使用Knossos线性checker来验证每一个操作是否自动处于调用和返回之间的位。线性checker需要一个模型并指明一个特定的算法，然后在选项中将map传递给该算法。
运行测试，我们可以验证checker的结果：
历史记录中最后的操作是write 1，可以确信，checker中的最终值也是1，该历史记录是线性一致的。
多checkers
checkers能够渲染多种类型的输出--包括数据结构、图像、或者可视化交互动画。例如：如果我们安装了gnuplot，Jepsen可以帮我们生成吞吐量和延迟图。让我们使用checker/compose来进行线性分析并生成性能图吧！
我们也可以生成历史操作HTML可视化界面。我们来添加jepsen.checker.timeline命名空间吧！
给checker添加测试：
现在我们可以绘制不同流程随时间变化执行的操作图，其中包括成功的、失败的以及崩溃的操作等等。
现在我们已经通过测试，接下来详述系统中的故障引入
Last updated
Was this helpful?