TiKV 在单节点IO挂起场景下的QPS归零问题分析

问题背景

在分布式键值存储系统TiKV的实际生产环境中，我们观察到一个值得关注的现象：当集群中单个TiKV节点发生IO挂起故障时，整个系统的查询性能(QPS)会持续下降直至归零。这种情况出现在TiKV 8.3.0-alpha版本中，测试环境采用8核32GB配置，运行TPCC基准测试时模拟IO挂起故障。

问题现象

正常情况下，系统应该能够在5分钟内从单个节点的IO故障中恢复。然而实际观察到的现象是：

• QPS持续下降
• 最终完全降为零
• 系统无法自动恢复

通过监控图表可以清晰地看到这一异常现象：在故障注入后，系统吞吐量呈现不可逆的下降趋势，而非预期的短暂波动后恢复。

根因分析

深入分析日志和系统行为后，我们发现问题的核心在于Region 4189的状态机被阻塞。具体机制如下：

1. 配置变更阻塞：问题Region(4189)正在等待一个未完成的ConfChange操作完成。由于IO挂起，该ConfChange对应的日志条目无法持久化到磁盘，导致状态机无法推进。

2. 调度冲突：PD调度器同时发起了两个操作：

   • move-hot-write-peer操作：试图将store 12的peer迁移到store 14
   • evict-slow-store-scheduler操作：试图将leader从store 13转移到store 1

3. 死锁形成：由于第一个ConfChange未完成，后续所有的TransferLeader请求都被拒绝，系统陷入死锁状态。日志中频繁出现"reject transfer leader due to pending conf change"的警告信息。

技术细节

从Raft协议的角度来看，当前实现中存在一个过于严格的约束检查：

1. 现有机制：当前实现要求在进行Leader转移前，必须确保所有pending的ConfChange都已被应用。这是为了保证Leader转移时的成员组配置是最新的。

2. 问题所在：当发生IO挂起时，ConfChange日志无法持久化，自然也无法被应用，导致Leader转移被无限期阻塞。

3. 协议理论：根据Raft论文中的Election Safety和Leader Completeness属性，实际上只要确保目标peer已经应用了ConfChange，就可以安全地进行Leader转移，而不需要当前Leader也完成应用。

解决方案

基于上述分析，我们提出以下改进方案：

1. 放宽约束条件：修改Leader转移的预检查逻辑，只要求目标peer已经应用了ConfChange，而不要求当前Leader也必须完成应用。

2. 具体实现：

   • 在发送TransferLeader预检查消息(MsgTransferLeader)时，从目标peer的响应中提取已应用的index
   • 比较该index与ConfChange的index
   • 只有当前者大于等于后者时，才允许Leader转移

3. 安全性证明：

   • 如果目标peer不在新配置中(已被移除)，它无法成为Leader，不影响安全性
   • 如果目标peer在新配置中，根据Raft协议属性，可以保证状态机安全

实施效果

该方案实施后，系统在单节点IO挂起时表现出的韧性显著提升：

1. 能够及时转移Leader角色
2. 避免因单个节点故障导致整个Region不可用
3. 保持系统整体可用性
4. 符合Raft协议的安全性和活性要求

总结

分布式系统的容错能力是其核心价值所在。通过对TiKV在IO故障场景下行为的深入分析，我们不仅解决了特定的QPS归零问题，更重要的是加深了对Raft协议实现细节的理解。这种基于协议理论指导工程实践的方法，是构建可靠分布式系统的关键。