请问下各位老师，当事务异常中断时，肯定有锁遗留在tikv中，那么这些锁的过期机制是怎样的？不懂其中的过期机制，能麻烦各位老师说下嘛？
1 个赞
锁和 TSO 还有关系，所有提交的数据都会带上 TSO，相当于目前这份数据的版本号
TSO 调单递增，自带时间顺序（因为有时间顺序，很容易进行比较了）
然后有个很重要的知识点，GC 的时候就会对 锁进行扫描了，发现有过期的，就会进行清理
Resolve Locks 有两种执行模式：
-
LEGACY（默认模式）：由 GC leader 对所有的 Region 发送请求扫描过期的锁，并对扫到的锁查询 Primary 的状态，再发送请求对其进行提交或回滚。 -
PHYSICAL：TiDB 绕过 Raft 层直接扫描每个 TiKV 节点上的数据。
如果 锁 有残留，基本上就两种处理方式：
- rollback
- cleanLock
两种处理都是为了保证数据版本的一致性
具体参考这个文档
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview#resolve-locks清理锁
请问锁的过期的时间是多长呢？
锁信息了有ttl,根据ttl时间判断，ttl时间会根据事务大小进行计算
ttl是悲观锁的机制吧，那乐观锁呢？
乐观锁的锁过期时间怎么判断呢？
乐观锁也有ttl
1 个赞
请问，那这3秒包括异步清理seconary 锁的时间嘛，毕竟事务提交，把primary lock 清理就算提交了，清理seconary 锁 是一个异步的过程，谢谢
锁的清理是个原子操作，primary lock 如果被清理掉了，seconary lock 就没 primary lock 做为指引，说明锁已经失效了，就可以被清理掉了
确实是个异步的过程，因为没必要同步…
seconary 锁的清理肯定是一个异步过程，但我的疑问是，0.25MB以内的小事务，TTL默认为3秒，这3秒包括异步清理seconary 锁 的机制嘛
应该不包括，secondary 锁，在其他事物访问到时，根据 cf 中存在的锁信息判断 commit 还是 rollback。
在事务执行的2PC阶段
应该包括，secondary 锁的能否被清楚取决于主锁的状态，如果主锁一直没被清理（有可能是事务中断，也有可能是到达了ttl），那么如果有事务读到secondary 锁的时候，就会去根据主锁的状态去清理锁