RisingWave流处理系统中状态表异步删除导致的数据一致性问题分析

在分布式流处理系统RisingWave中，我们发现了一个关于状态表管理与流处理作业协调的重要问题。这个问题出现在执行DROP SINK操作时，特别是在处理带有回填(backfill)功能的流处理作业场景下。

问题现象

当系统执行DROP SINK命令时，偶尔会出现流处理任务异常终止的情况。错误日志显示某些行数据无法找到，同时伴随状态表已被删除的警告信息。这种情况在测试环境中表现为间歇性失败，说明这是一个竞态条件问题。

技术背景

RisingWave采用了一种创新的流处理架构，其中：

1. 状态表：用于存储流处理作业的中间状态，包括回填进度等信息
2. 共享缓冲区压缩：定期将内存中的不可变数据(immutable mem-table)压缩为SST文件
3. 元数据管理：通过中心化的元数据服务管理表结构信息

问题根源

经过深入分析，我们发现问题的根本原因在于状态表删除流程与流处理作业终止流程之间存在时序问题：

1. 删除顺序问题：当执行DROP SINK时，系统首先从目录中删除相关状态表，然后才通过屏障管理器调度流处理作业的停止命令
2. 竞态窗口：在目录删除和作业实际停止之间存在时间差，此时流处理任务仍在运行并尝试写入已不存在的状态表
3. 压缩机制缺陷：共享缓冲区压缩时发现表不存在会静默忽略相关数据，导致后续读取时数据丢失

技术细节

具体到实现层面，问题表现为：

1. 压缩逻辑：共享缓冲区压缩时会检查表ID是否存在于目录中，不存在的表数据会被丢弃
2. 回填机制：回填执行器依赖状态表来跟踪进度，当相关数据丢失时会报"row not found"错误
3. 速率限制：压缩速率限制为1的设置增加了问题出现的概率，使得回填进度表可能在删除前未被压缩

解决方案

针对这一问题，开发团队提出了以下改进方向：

1. 流程重构：调整流处理作业停止流程，确保先停止所有相关执行器再删除状态表
2. 错误处理：改进共享缓冲区压缩时的错误处理机制，对不存在的表采取更明确的处理策略
3. 同步机制：加强元数据变更与流处理任务状态之间的同步保证

系统设计启示

这一问题的发现为流处理系统设计提供了重要启示：

1. 资源生命周期管理：需要严格定义和实现各类资源的创建、使用和销毁顺序
2. 错误恢复策略：对于可能出现的中间状态需要有明确的处理策略，不能简单忽略
3. 测试覆盖：需要特别关注分布式场景下的时序问题和竞态条件

总结

RisingWave中发现的这一状态表管理问题，典型地展示了分布式系统中资源生命周期管理的复杂性。通过深入分析这一问题，不仅解决了特定的bug，也为系统架构的持续优化提供了宝贵经验。这类问题的解决有助于提高系统的稳定性和可靠性，特别是在处理长时间运行的流处理作业时。