使用Socket.IO做前端推送时仍需MongoDB Change Stream的原因是什么

两种实现方案都可以满足基础的课程创建通知需求，引入MongoDB Change Stream的核心价值是适配生产环境的复杂场景，避免后续业务迭代出现隐患，必要性主要体现在以下几个方面：

• 变更逻辑与业务接口彻底解耦
  如果把Socket.IO推送逻辑耦合在创建课程的业务接口中，所有触发课程新增的场景都需要重复编写推送代码：后续新增批量导入课程、后台定时任务生成课程、其他服务直连数据库写入课程等入口时，每处都要补充推送逻辑，很容易出现漏发通知的问题。
  用Change Stream监听的模式下，只要是数据库层面完成课程文档写入的操作，都会统一触发推送逻辑，和上层触发入口无关，不需要反复修改业务代码。
• 天然保证数据一致性
  接口内直接发送Socket.IO的模式，很容易出现时序问题：如果代码逻辑写反（先推送再写库）、或者数据库异步落库失败，会出现用户收到通知但找不到对应课程的异常。
  Change Stream监听的是数据库已经提交成功的持久化变更，不存在推送和实际数据不一致的问题。
• 容错能力更强，不影响主接口性能
  接口内同步发送Socket.IO时，如果推送服务出现波动，会直接拖慢创建课程接口的响应速度，甚至导致接口超时；如果接口进程崩溃，未完成的推送也会直接丢失。
  独立的Change Stream监听服务不会侵入主业务链路，推送失败时还可以基于Change Stream自带的resume token实现断点续传，不会漏过任何变更事件。
• 后续扩展成本极低
  后续如果需要新增课程更新、课程删除的通知场景，或者要同步课程数据到搜索引擎、数仓等其他系统，只需要在Change Stream的监听逻辑中新增处理分支即可，完全不需要修改主业务接口的代码。

如果你的业务场景十分简单，只有唯一的课程创建入口、也没有后续的扩展计划，直接在接口成功后触发Socket.IO是更轻量化的选择，不需要过度设计。

内容的提问来源于stack exchange，提问作者Bipin Shrestha