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 才会被重新唤醒继续往下处理。