consistency read的实现方式

绝地灬酷狼 2022-06-05 02:59 127阅读 0赞

**consistency read的实现方式**

**1.   Raft log read**

所谓线性一致性，一个简单的例子就是在 t1 的时间我们写入了一个值，那么在 t1 之后，我们的读一定能读到这个值，不可能读到 t1 之前的值。

因为 Raft 本来就是一个为了实现分布式环境下面线性一致性的算法，所以我们可以通过 Raft 非常方便的实现线性 read，也就是将任何的读请求走一次 Raft log，等这个 log 提交之后，在 apply 的时候从状态机里面读取值，我们就一定能够保证这个读取到的值是满足线性要求的。

当然，大家知道，因为每次 read 都需要走 Raft 流程，所以性能是非常的低效的，所以大家通常都不会使用。

我们知道，在 Raft 里面，节点有三个状态，leader，candidate 和 follower，任何 Raft 的写入操作都必须经过 leader，只有 leader 将对应的 raft log 复制到 majority 的节点上面，我们才会认为这一次写入是成功的。所以我们可以认为，如果当前 leader 能确定一定是 leader，那么我们就可以直接在这个 leader 上面读取数据，因为对于 leader 来说，如果确认一个 log 已经提交到了大多数节点，在 t1 的时候 apply 写入到状态机，那么在 t1 之后后面的 read 就一定能读取到这个新写入的数据。

**2.   ****ReadIndex Read**

第一种就是 ReadIndex，当 leader 要处理一个读请求的时候：

1）将当前自己的commit index记录到一个local变量ReadIndex里面。

2）向其他节点发起一次 heartbeat，如果大多数节点返回了对应的 heartbeat response，那么 leader 就能够确定现在自己仍然是 leader。

3）Leader等待自己的状态机执行，直到apply index超过了ReadIndex，这样就能够安全的提供 linearizable read 了。

4）Leader执行read请求，将结果返回给 client。

可以看到，不同于最开始的通过 Raft log 的 read，ReadIndex read 使用了 heartbeat 的方式来让 leader 确认自己是 leader，省去了 Raft log 那一套流程。虽然仍然会有网络开销，但 heartbeat 本来就很小，所以性能还是非常好的。

**3.   Lease Read**

在 Raft 论文里面，提到了一种通过 clock + heartbeat 的 lease read 优化方法。也就是 leader 发送 heartbeat 的时候，会首先记录一个时间点 start，当系统大部分节点都回复了 heartbeat response，那么我们就可以认为 leader 的 lease 有效期可以到 `start + election timeout / clock drift bound` 这个时间点。

为什么能够这么认为呢？主要是在于 Raft 的选举机制，因为 follower 会在至少 election timeout 的时间之后，才会重新发生选举，所以下一个 leader 选出来的时间一定可以保证大于 `start + election timeout / clock drift bound`。

虽然采用 lease 的做法很高效，但仍然会面临风险问题，也就是我们有了一个预设的前提，各个服务器的 CPU clock 的时间是准的，即使有误差，也会在一个非常小的 bound 范围里面，如果各个服务器之间 clock 走的频率不一样，有些太快，有些太慢，这套 lease 机制就可能出问题。

TiKV 使用了 lease read 机制，主要是我们觉得在大多数情况下面 CPU 时钟都是正确的，当然这里会有隐患，所以我们也仍然提供了 ReadIndex 的方案。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5nbGluaHVzdA_size_16_color_FFFFFF_t_70][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5nbGluaHVzdA_size_16_color_FFFFFF_t_70]: /images/20220605/9fbfdc0abd0f464b869bcab8112c1127.png