TiKV悲观锁重复请求导致Panic问题分析

在TiKV分布式存储系统中，近期发现了一个由于悲观锁重复请求导致的严重问题。该问题会导致TiKV节点发生panic，影响系统稳定性。本文将深入分析该问题的技术背景、产生原因以及解决方案。

问题现象

在TiKV的运行日志中，可以观察到如下关键错误信息：

found duplicate key in Lock CF PUT request

该错误发生在raftkv模块处理写入请求时，具体位置为src/server/raftkv/mod.rs的第517行。错误发生时，系统尝试对同一个键(7480000000000000FF905F728000000000FF00000F0000000000FA)写入两个不同的悲观锁记录。

技术背景

TiKV使用多版本并发控制(MVCC)机制来实现事务处理。悲观锁是TiKV支持的一种并发控制方式，它通过在数据写入前先获取锁来避免写写冲突。在实现上，悲观锁信息存储在专门的Lock CF(Column Family)中。

当多个事务同时尝试修改相同数据时，TiKV会通过锁机制来协调这些操作。正常情况下，一个键在同一时间只能有一个有效的悲观锁记录。

问题原因分析

通过分析日志和代码，我们发现问题的根本原因是：

1. 系统收到了一个包含两个ResumedPessimisticLockItem的命令请求
2. 这两个锁项针对的是完全相同的键(7480000000000000FF905F728000000000FF00000F0000000000FA)
3. 但它们的元数据不同，包括：
   • 不同的事务开始时间戳(StartTs)
   • 不同的主键(Primary Key)
   • 不同的锁TTL值

这种重复的锁请求会导致TiKV尝试在Lock CF中为同一个键写入两个不同的锁记录，违反了"一个键同一时间只能有一个锁"的基本约束，从而触发了系统的panic保护机制。

问题影响

该问题会导致以下影响：

1. TiKV节点崩溃：触发panic会导致节点重启，影响服务可用性
2. 事务失败：正在进行的事务可能会被中断
3. 系统稳定性下降：频繁的节点重启会影响集群整体稳定性

解决方案

该问题已被修复，主要解决思路是：

1. 在命令处理层增加对重复锁请求的检测
2. 对于包含相同键的多个锁请求，进行适当的合并或拒绝处理
3. 增加更完善的错误处理机制，避免直接panic

最佳实践建议

对于TiKV用户，建议：

1. 及时升级到包含该修复的版本
2. 监控系统中锁冲突的情况
3. 合理设置事务参数，避免不必要的锁竞争
4. 在应用层做好重试机制，处理可能的锁冲突

通过理解这个问题的本质，我们可以更好地设计和使用TiKV的悲观锁机制，构建更稳定的分布式系统。