TiKV中EntryCache的断言失败问题分析与解决

问题背景

在TiKV分布式存储系统中，EntryCache是用于缓存Raft日志条目的重要组件。近期在测试中发现了一个导致TiKV panic的问题，错误信息为"assertion failed: cached_last < trunc_to_idx"。这个问题发生在EntryCache的append操作中，当系统尝试追加新的Raft日志条目时触发了断言失败。

问题现象

当TiKV节点处理Raft日志时，EntryCache模块会在追加新日志时检查缓存状态。具体来说，系统会验证当前缓存中的最后一个日志索引(cached_last)是否小于要截断的索引(trunc_to_idx)。如果这个条件不满足，就会触发断言失败导致进程panic。

根本原因分析

经过深入分析，发现问题源于TiKV对Raft协议实现中的一个边界条件处理不当。具体场景如下：

1. 一个Raft组中有三个节点A、B、C，初始时A是Leader，所有节点的持久化、提交和应用索引都是10。
2. A节点与B、C网络隔离，此时A收到一个请求产生索引11的日志，但由于隔离无法提交，该日志被放入EntryCache。
3. 选举超时后，B成为新Leader并处理新请求，产生并提交了索引11的日志。
4. A节点网络恢复后，收到来自B的Raft消息(索引11)，提交索引变为11。
5. A节点在处理这些消息时，会尝试将索引11的日志发送给ApplyFsm应用，同时又要将新日志(索引11)写入EntryCache，导致冲突。

问题的核心在于：

1. TiKV实现了"在持久化前应用已提交Raft日志"的特性
2. 角色变更时重置了max_apply_unpersisted_log_limit，但收集就绪消息的操作发生在角色变更前
3. 导致新Follower在同一轮处理中可以应用比预期更多的Raft日志

解决方案

针对这个问题，我们采取了以下改进措施：

1. 修改raft-rs实现，仅允许Leader返回已提交但未持久化的日志条目
2. 移除原有的断言检查，因为"在持久化前应用已提交Raft日志"的特性使得该断言不再成立

测试验证

为了验证修复效果，可以通过以下方式模拟问题场景：

1. 暂停store writer线程
2. 制造网络分区场景
3. 观察在节点恢复后EntryCache的处理行为

总结

这个问题的发现和解决过程展示了TiKV团队对分布式一致性协议的深入理解。通过分析Raft日志处理流程中的边界条件，我们不仅修复了当前的panic问题，还进一步完善了TiKV的日志处理机制，提高了系统的健壮性。这也提醒我们在实现分布式系统时，需要特别注意角色变更和网络分区等边界场景的处理。