Quickwit 项目中的 Ingest V2 服务优雅关闭问题分析

问题背景

在 Quickwit 分布式搜索项目中，Ingest V2 服务作为数据摄入的关键组件，其优雅关闭机制存在一些潜在问题。当用户尝试正常退出 Quickwit 服务时，偶尔会遇到 Ingest V2 服务在"decommissioning"阶段挂起的情况，只能通过强制终止(kill -9)来结束进程。

问题现象

从日志中可以观察到，当发送终止信号(CTRL+C)时，服务会打印"decommissioning ingester"信息，但随后便停止响应，无法正常退出。这种情况并非每次都能复现，具有一定的随机性。

根本原因分析

经过技术团队深入调查，发现该问题由多个因素共同导致：

1. 测试环境残留问题：即使在未显式启用 Ingest V2 的情况下(QW_ENABLE_INGEST_V2未设置)，执行REST API测试仍会创建shard并写入少量记录。这些shard不会被索引，也不会被清理。当下次尝试关闭未启用V2的节点时，系统会等待这些shard被清空，而这一过程永远不会完成。

2. 控制平面提前关闭问题：当控制平面(control plane)在新索引节点有机会调度其摄入管道之前就被关闭时，该节点在关闭过程中会永久挂起，因为其shard永远不会被索引。

3. 集群同时关闭问题：当同时关闭集群中的所有节点时，索引器会尝试提交最后一个空批次(可能是为了通知shard已关闭)，但由于元数据存储(metastore)和控制平面已不可用，这一操作会无限期失败。

解决方案与改进

技术团队通过添加集成测试来验证这些问题：

1. 添加了ingest_tests::test_shutdown_metastore_first测试用例，专门验证控制平面提前关闭场景
2. 添加了集群同时关闭场景的测试用例

这些测试在Ingest V1模式下通过，但在启用Ingest V2时失败，证实了问题的存在。

技术细节补充

在分布式系统中，服务的优雅关闭是一个复杂的问题，需要考虑：

• 数据一致性：确保所有在途数据被正确处理
• 资源清理：正确释放所有占用的资源
• 依赖管理：处理服务间的依赖关系，如控制平面与数据平面的交互
• 超时机制：为各种操作设置合理的超时，避免无限等待

Quickwit团队正在针对这些问题进行修复，包括改进shard的生命周期管理、优化关闭序列以及增强错误处理机制。

总结

Quickwit项目中Ingest V2服务的优雅关闭问题揭示了分布式系统设计中常见的挑战。通过深入分析问题根源并添加针对性测试，团队正在稳步推进解决方案。这类问题的解决不仅提高了系统的可靠性，也为类似分布式系统的设计提供了宝贵经验。