前端轮询还是后端通过WebSocket推送？产品过期提醒方案选型咨询

核心业务判断基准 #

先对齐两个影响选型的核心参数，你可以结合自身实际情况匹配：

• 提醒允许的最大延迟：比如是1分钟、10分钟还是1小时
• 活跃用户规模n：是几十、几千还是十万以上

两种方案优劣势&开销对比 #

1. 前端轮询方案 #

• 开销特性：
  • 数据库侧：每t周期n次单用户维度查询，请求均匀分布无峰值压力，只要给user_id+expire_date加复合索引，单条查询耗时基本在毫秒级，几乎不会产生性能负担
  • 服务端侧：无状态HTTP请求，不需要维持长连接，开发调试成本极低，扩缩容无额外适配要求
  • 客户端侧：低频定时请求对现代浏览器几乎无额外开销，弱网环境下自动重试成本极低
• 劣势：t设置过短、n规模超过10万时，总请求量会线性上涨，存在冗余请求（当期无过期产品的用户请求属于空跑）

2. 后端单实例轮询+WebSocket推送方案 #

• 开销特性：
  • 数据库侧：每t周期仅1次全局查询，但该查询需要扫描全量即将过期的产品再关联对应用户，数据量大时单次查询的复杂度、耗时远高于前端轮询的单用户查询
  • 服务端侧：需要维持n个长连接，单实例可支撑的WebSocket连接上限通常在1万~10万量级（和服务器配置有关），用户规模超过单实例上限时还需要开发跨实例订阅分发逻辑，开发和维护成本高很多；集中推送瞬间会产生带宽、CPU尖刺，可能影响其他业务正常运行
  • 客户端侧：需要处理WebSocket断开重连、心跳维持逻辑，弱网环境下容易丢失通知
• 优势：总开销和用户规模解耦，用户量极大时全局查询的成本优势才会体现

最终选型建议 #

• 如果你的用户规模在10万以下，或者提醒允许延迟在5分钟以上，优先选前端轮询：开发成本低、维护难度低，只要把轮询间隔t设置合理即可，比如允许延迟10分钟就设t=10分钟，单用户每10分钟发一次请求完全不会给服务端造成可感知的压力。
• 如果你的用户规模超过10万，且提醒延迟要求在1分钟以内，再考虑WebSocket方案：同时建议不要用单实例定时全局轮询的模式，可以结合MongoDB的change stream监听产品过期事件，触发后再给对应用户推送，能避免集中查询的性能尖刺，效率远高于定时全局扫描。

通用优化建议 #

不管选哪个方案，都可以给即将过期的产品加预计算标记，比如提前24小时给将要过期的产品打上to_be_expired标签，查询时直接过滤该标签，能大幅降低数据库查询开销。

内容的提问来源于stack exchange，提问作者Gergő Horváth