consistency read的实现方式

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 的方案。