Meteor项目中MongoDB Oplog观察驱动程序的竞态条件问题分析

问题背景

在Meteor项目中使用MongoDB的oplog观察驱动程序时，发现了一个可能导致驱动程序永久停留在FETCHING状态的竞态条件问题。这个问题主要影响Meteor 3.0.4和3.1.1版本，而在较早的1.10.1版本中并未出现。

问题现象

正常情况下，oplog观察驱动程序会在STEADY、QUERYING和FETCHING三种状态间循环切换，最终总会回到STEADY状态。但在特定情况下，驱动程序可能永久停留在FETCHING状态，导致以下连锁反应：

1. 写屏障(writefences)无法解除
2. updated DDP事件无法发送
3. Meteor方法看似没有"返回"给客户端（虽然result消息已送达，但缺少updated消息）

问题根源分析

问题的核心在于waiting计数器变量与实际执行情况不同步。这个计数器用于跟踪未完成的Promise数量，但在某些情况下可能被错误地递减到负值(-1)，导致Promise永远无法解析。

具体来说，DocFetcher的fetch方法在某些情况下会多次调用回调函数。每次回调都会递减waiting计数器，如果回调被调用次数多于预期，计数器就会变为负值。一旦计数器变为负值，整个流程就会陷入停滞状态。

技术细节

从日志中可以清晰地看到问题发生的过程：

1. 初始状态下waiting计数器为1
2. 处理第一个文档(uX5rTXAMf2grJ7KCC)后，计数器递减为0
3. 处理第二个文档(7t5FEj7RnBDd9ocLG)时，计数器再次递减为0
4. 但随后同一个文档的处理回调被再次触发，导致计数器错误地递减为-1

这种重复回调的情况可能是由于MongoDB查询结果处理过程中的某种竞态条件导致的。

解决方案建议

针对这个问题，提出了以下改进方案：

1. 完全移除waiting计数器机制
2. 改用Promise.all()来跟踪所有fetch操作的完成状态
3. 直接await所有fetch Promise的完成

这种方案的优势在于：

• 消除了手动管理计数器带来的复杂性
• 避免了计数器不同步的风险
• 即使回调被多次调用，Promise机制也能保证流程正常继续

实际验证

该修复方案已在生产环境中部署验证：

• 修复前：每天都会出现多次此问题
• 修复后：问题完全消失，且未发现任何负面影响

总结

这个案例展示了在异步编程中手动管理状态可能带来的风险。使用语言/框架提供的原生机制(如Promise)往往比手动计数器更可靠。对于Meteor开发者来说，在升级到3.x版本时需要注意这个潜在问题，特别是在高负载或复杂查询场景下。