TiKV 悲观锁重复键问题分析与修复

问题背景

在分布式数据库TiKV中，悲观锁机制是保证事务隔离性的重要手段。近期在测试环境中发现了一个关键问题：当多个事务尝试对同一个键获取悲观锁时，系统出现了"found duplicate key in Lock CF PUT request"的致命错误，导致节点崩溃。

问题现象

错误日志显示，系统在处理悲观锁请求时，检测到对同一个键(7480000000000000FF905F728000000000FF00000F0000000000FA)的两个不同悲观锁请求被同时提交。这两个锁请求具有不同的元数据：

1. 第一个锁请求：

   • 主键：7480000000000000925F728000000000000011
   • 开始时间戳：455185382972850181
   • TTL：49658毫秒

2. 第二个锁请求：

   • 主键：7480000000000000905F72800000000000000F
   • 开始时间戳：455185385650651171
   • TTL：39928毫秒

技术分析

深入分析日志后发现，问题的根源在于一个命令中包含了两个针对相同键的ResumedPessimisticLockItem。这种设计违反了TiKV对悲观锁处理的基本假设——每个键在同一时间只能有一个有效的悲观锁。

悲观锁的工作流程通常包括：

1. 事务开始并获取开始时间戳
2. 对需要修改的数据获取悲观锁
3. 执行数据修改
4. 提交事务

在正常情况下，系统会确保对同一个键的锁请求是串行化的。但在这个案例中，两个锁请求被错误地打包在同一个命令中，绕过了常规的冲突检测机制。

影响范围

该问题会导致：

1. 节点崩溃，影响系统可用性
2. 可能造成事务不一致
3. 在重试机制下可能引发级联故障

解决方案

修复方案的核心是确保每个命令中不会包含针对同一个键的多个悲观锁请求。具体措施包括：

1. 在命令构建阶段增加重复键检查
2. 优化悲观锁请求的批处理逻辑
3. 增强错误处理机制，避免节点崩溃

经验总结

这个案例提醒我们，在分布式系统中：

1. 对共享资源的访问必须严格串行化
2. 批处理操作需要特别注意原子性和隔离性
3. 防御性编程对于系统稳定性至关重要

通过这次问题的分析和修复，TiKV的悲观锁机制得到了进一步加固，为后续版本提供了更稳定的基础。