TiKV 中解决大事务阻塞 resolved-ts 问题的技术方案

背景与问题分析

在分布式数据库 TiKV 中，resolved-ts（解决时间戳）是一个关键指标，它表示所有早于该时间戳的事务都已被提交或回滚，系统可以安全地读取该时间点之前的数据。这个机制对于实现一致性读取、增量备份等核心功能至关重要。

然而，在 TiKV v8.3 及之前版本中，存在一个严重问题：大型事务（特别是采用流水线式提交的事务）可能会长时间阻塞 resolved-ts 的推进。这是因为当前 resolved-ts 的计算方式采用了过于严格的约束条件——取 PD 分配的时间戳和所有锁中最小时戳的最小值。当一个大型事务持有锁数小时时，resolved-ts 也会被阻塞数小时无法推进，导致依赖 resolved-ts 的服务不可用。

技术原理深入

resolved-ts 的原始定义

resolved-ts 的原始定义应该是：所有在该时间戳之前开始的事务都已经确定最终状态（已提交或已回滚）。这意味着：

1. 对于已提交的事务，其修改对 resolved-ts 之后的读取可见
2. 对于已回滚的事务，其修改对任何读取都不可见
3. 系统可以安全地提供该时间点的一致性快照

当前实现的缺陷

当前实现将 resolved-ts 计算为 min(pd-tso, min(lock.ts))，这实际上比原始定义更加严格。这种实现会导致：

1. 虚假阻塞：即使一个事务尚未提交但确定不会影响一致性读取（如已确定会提交的事务），仍会阻塞 resolved-ts
2. 长事务影响：执行时间长的流水线事务会直接导致 resolved-ts 停滞
3. 系统可用性下降：CDC、备份等服务因无法获取新的 resolved-ts 而停止工作

解决方案设计

核心思路

新方案的核心是区分两种不同类型的锁：

1. 活跃事务锁：事务仍在执行中，状态未确定
2. 已决事务锁：事务状态已确定（通过心跳、提交或回滚消息确认）

对于已决事务锁，即使尚未完成提交/回滚流程，也不应该阻塞 resolved-ts 的推进。

关键技术组件

1. 事务状态缓存：维护一个缓存来记录已确定状态的事务
2. 心跳机制扩展：通过心跳消息传播事务状态信息
3. 广播消息系统：快速通知各节点事务状态的变更
4. 检查事务状态协议：提供高效的事务状态查询机制

实现细节

1. 事务状态跟踪：

   • 记录事务的最后活动时间
   • 跟踪事务的提交/回滚意向
   • 维护事务的最终状态确定性

2. resolved-ts 计算优化：

   • 排除已确定提交事务的锁
   • 快速推进已知不会冲突的事务时间窗口
   • 保证计算过程的高效性

3. 故障恢复机制：

   • 处理节点宕机后的状态恢复
   • 保证网络分区情况下的正确性
   • 实现状态的持久化存储

性能与一致性保证

新方案在提升系统可用性的同时，必须保证严格的一致性：

1. 安全性：绝不会将未确定状态的事务排除在 resolved-ts 计算之外
2. 活性：确保 resolved-ts 最终能够推进，不会被无限阻塞
3. 性能：状态跟踪和 resolved-ts 计算的开销控制在合理范围内

应用场景与收益

该优化方案将显著改善以下场景的用户体验：

1. 大规模数据迁移：长时间运行的数据导入不会阻塞系统读取
2. 批量数据处理：ETL 作业不影响实时查询服务
3. 系统维护操作：后台维护任务不会导致监控和备份中断
4. 高延迟环境：跨地域部署中网络延迟不会造成 resolved-ts 停滞

未来发展方向

1. 动态调整机制：根据系统负载自动调整 resolved-ts 计算策略
2. 更细粒度控制：允许不同服务设置不同的 resolved-ts 推进策略
3. 混合事务支持：更好地处理混合长事务和短事务的场景
4. 资源隔离：确保 resolved-ts 计算不会受到用户事务的过度影响

该解决方案的实施将显著提升 TiKV 在处理大型事务时的系统可用性和用户体验，同时保持分布式系统强一致性的核心特性。