lease read的线性一致问题

🪐 TiDB 技术问题
1

【 TiDB 使用环境】 Poc
【 TiDB 版本】5.1.0
【复现路径】 -
【遇到的问题：问题现象及影响】
请问tikv实现的lease read是强一致的吗？如果按照下述执行顺序是不是有问题

  1. client put (k,v)，返回超时，(比如可能由于某些原因，apply到rocksdb过久)
  2. client get (k)，lease read直接从rocksdb里面取数据，返回不存在
  3. 完成apply，写入成功。

这种情况下tikv是定义1和2为并发读写没法确定先后关系吗？但是从客户端视角下这个1和2具有因果关系，这样是否违背了线性一致性呢？这种case是不是只能用read index来解决？

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

2

缺少不了日志的作用。

3

没有理解这个和日志有什么关系

4

TiKV 实现的 lease read 是强一致的。根据 TiKV 的官方文档，TiKV 使用 lease read 机制来保证强一致性。在 lease read 中，TiKV 会通过记录时间戳来续约 leader 的 lease，以确保数据的一致性。即使在某些情况下出现超时等问题，TiKV 也会保证数据的一致性[1]。

在您描述的情况下，如果客户端执行了以下操作：

  1. 客户端执行 put (k,v) 操作，但返回超时。
  2. 客户端执行 get (k) 操作，lease read 直接从 rocksdb 中取数据，但返回不存在。
  3. 最终完成 apply，写入成功。

从 TiKV 的角度来看，这种情况下确实存在并发读写的情况，因为在第 2 步中，数据可能尚未被成功写入，导致读取不到数据。但是从客户端的视角来看，这两个操作具有因果关系，客户端期望在写入成功后能够读取到相应的数据。

为了解决这种情况，TiKV 提供了 ReadIndex 的方案。通过使用 ReadIndex，客户端可以确保在读取数据时，已经考虑到了最新的写入操作，从而避免类似的并发读写问题。因此，如果您关注线性一致性，可以考虑使用 ReadIndex 来解决这种情况。

这个是投喂了 tidb 材料的 AI 回答 :point_up_2:t2:

1 个赞
5

一定是强一致的，具体看第一条的回答

6

强一致性

7

强一致性