MongoDB用作请求队列时，collection.watch()与sched.scheduler哪种轮询方式更好？

直接结合MongoDB请求队列的场景对比两种方案的适配性，不做冗余铺垫。

你当前轮询方案的固有问题 #

• 延迟硬伤：固定3秒的查询间隔意味着，哪怕文档刚被写入/更新，最坏也要等3秒才会被处理，对实时性要求稍高的请求队列场景很难接受。
• 无效开销：哪怕队列没有任何新增/变更，每3秒都会触发一次查询空跑，数据量越大，无意义的查询对MongoDB和应用的资源消耗越高。
• 边界处理风险：如果没有做严格的游标持久化、幂等标记，轮询的时间窗口边界很容易出现漏处理、重复处理的问题。

优先选择collection.watch()的场景（绝大多数请求队列场景都适配） #

collection.watch()是MongoDB原生的变更订阅能力，刚好匹配你要监听新增、更新两类文档变更的需求，优势非常明确：

• 实时性拉满：变更事件是MongoDB主动推送的，延迟可以压到百毫秒级，远低于3秒轮询的固定间隔，完全满足请求队列的快速响应要求。
• 资源开销极低：只有真的有文档变更时才会触发处理逻辑，没有空跑的查询，MongoDB和应用端都能省大量资源。
• 原生支持你需要的事件类型：不需要自己写查询条件去区分新增、更新操作，订阅时直接指定监听insert、update事件即可，事件自带文档的变更上下文，不需要额外查询全量文档比对。

用collection.watch()必须注意的工程坑 #

• 版本和部署要求：能力要求MongoDB 3.6及以上版本，且必须部署为副本集模式（哪怕是单节点的测试环境也要开副本集），分片集群需要4.0以上版本才支持跨分片的变更监听。
• 必须做断线重连和断点续传：长连接不可能永不断开，MongoDB端有超时限制、网络波动也会中断连接，需要持久化每次消费完的resumeToken，重连时带上这个token拉取断线后的变更，否则会直接漏消费请求。
• 不要在监听回调里做阻塞逻辑：回调本身只是负责接收变更事件、投递给异步处理逻辑就行，要是在回调里做长时间的业务处理，会导致事件堆积、连接超时断开，反而影响可用性。

仍适合用sched定时轮询的场景 #

只有满足以下任意一个条件时，才建议保留你现在的轮询方案：

• 业务对实时性要求极低：比如允许请求有几分钟的延迟，不需要追求快速响应，轮询的开发、运维成本更低，不需要处理watch的重连、token持久化等逻辑。
• 现有MongoDB版本低于3.6，不支持watch能力。
• 变更量极大：事件推送的吞吐超过了应用的处理上限，这时候用轮询批量拉取、批量处理的吞吐反而更高，不会出现事件洪水冲垮应用的问题。

落地的兜底建议 #

如果最终选择用collection.watch()替换轮询，建议额外加一层低频的兜底轮询：比如每5分钟跑一次全量校验，扫出因为watch断线漏处理的文档，同时给所有处理逻辑加幂等判断，不管是watch收到的事件还是兜底轮询扫到的文档，都要校验处理状态，避免重复消费。

内容的提问来源于stack exchange，提问作者badass 1996