【 TiDB 使用环境】生产\测试环境\ POC
【 TiDB 版本】
【遇到的问题】
【复现路径】做过哪些操作出现的问题
【问题现象及影响】
【TiDB Operator 版本】：
【K8s 版本】：
【附件】：
- 相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/)
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 天后被自动关闭。不再允许新回复。