TiKV内存中的latch具体是加在什么对象上的?

【 TiDB 使用环境】生产\测试环境\ POC
【 TiDB 版本】
【遇到的问题】
【复现路径】做过哪些操作出现的问题
【问题现象及影响】
【TiDB Operator 版本】:
【K8s 版本】:
【附件】:

latch不是一个对象,可以理解成一个桶。
grpc获取到请求,解析后要掉sheduler,scheduler处理前需要先同桶里面拿一个tickets,拿完了就等着。
拿到的就继续往下执行。

latch可以理解为一种资源,但是应该是被内存中某个或者某些对象所持有的吧?

tikv 中的 latch 主要用于 tikv 事务层的并发控制。具体加锁的对象是 tikv 事务请求中的 key 对象,防止多个并发同时对 同一个 key 进行操作。
想要快速了解,可以通过阅读本文件末的test 案例来对这个 latch 进行简单的了解。

tikv 本身对外支持 ACID 的事务模型,所有的事务接口,都要确保其原子性
tikv 的事务实现基于底层的 raftstore,目前 raftstore 能提供的原子性操作只有两种:

  • snapshot 级别读取
  • 批量写入

tikv 需要基于以上接口来实现事务接口的原子性,而大部分事务接口,都需要:

  • 读,检查可行性
  • 批量写入

为确保其原子性,tikv 使用内存锁 latches 来解决这个问题。

这边简单以事务模型中的一个接口为例子进行介绍:
prewrite(keys): 乐观锁的 prewrite, tikv 收到该请求后,会检查并对所有 keys 物理加锁。该请求成功后,其他 client 尝试对已经加锁的任意一个 key 加锁都会返回失败。

假设:
client1 prewrite(k1,k2,k3)
client2 prewrite(k3,k5)

为确保 prewrite 的原子性,在收到 client1 请求时,使用 latches 对 k1,k2,k3 加锁,直到处理完整个请求才返回。
在收到 client2 请求时,尝试使用 latches 对 k3,k5 进行加锁,此时发现 k3 已经有锁,则 client2 在 latches 里面对 k3 注册进行排队,直到 k3 的锁被释放后,client2 才会被重新唤醒继续往下处理。

3 个赞

哦,主要用于kv 事务层并发控制的,latch的使用情况如何查询呢?例如争用严重与否之类的

在 tikv-details 监控面板上,每个 scheduler 也就是事务层 API 的监控中,都有一个 scheduler latch wait duration 面板,这个等待时间越长,说明同 key 争用越严重。


非常感谢

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。