如何正确设计高并发场景下的应用内实时通知服务？

你的性能问题根源是API请求线程被同步执行的5-6k条通知创建+WebSocket推送阻塞了。Node.js基于单线程事件循环模型，同步批量数据库操作和IO会卡住整个进程，导致其他请求排队。不管后续用不用队列，第一步必须把通知处理从API主流程中剥离，转为异步任务。

要不要引入队列服务？需要，且不算过度设计 #

你部署在K8s且新增服务无压力，队列是解决当前问题的最优方案——你的场景已经出现批量操作阻塞主流程的情况，队列的核心作用就是削峰填谷、解耦同步依赖，完全匹配你的需求，不属于过度设计。

为什么放弃纯数据库方案？ #

纯靠数据库定时轮询（比如每隔几秒查pending状态的通知）也能实现异步，但缺点很明显：

• 轮询间隔难把控，太短增加数据库压力，太长则实时性不足
• 无法实现任务重试、批量调度、多实例负载均衡（比如让多个进程分摊推送任务）
• 你已经用触发器在数据库层处理合并逻辑，再把推送逻辑塞进去会进一步加重数据库负担

Redis vs RabbitMQ怎么选？ #

• 如果只是做简单的任务分发、Pub/Sub，Redis完全够用：轻量、和Node.js集成简单，K8s部署成本低。你的通知场景不需要复杂路由、事务，只需要把批量通知任务丢进队列，由消费者进程处理推送，Redis完全覆盖需求。
• 若后续需要延迟通知、死信队列、优先级队列这类复杂能力，再考虑切换到RabbitMQ，现阶段没必要提前做过度设计。

队列和数据库的职责划分 #

• 数据库负责持久化最终状态：所有通知（包括合并后的）必须存在notifications表，这是用户查看历史通知的唯一数据源，state字段可用来标记是否已完成推送。
• 队列负责传递待处理任务：队列里不需要存完整的通知内容，只存任务元数据即可——比如通知类型、触发事件的资源ID、目标用户ID列表（或筛选条件）。这样消息体积小，处理效率更高。

举个实际流程例子：当Article created事件发生时

1. API端点只需要向Redis队列发送一条消息：{ type: 'article_published', articleId: 123, targetUserIds: [1,2,...,5000] }，然后立即返回响应给客户端
2. 独立的通知消费者进程监听队列，拿到消息后：
   • 执行数据库操作（触发你已有的合并触发器），创建或更新用户的通知记录
   • 批量向在线用户推送WebSocket消息

实时推送：WebSockets更适合你的场景 #

• WebSockets是首选：你的通知需要双向交互（比如用户标记已读要同步回后端），且WebSockets支持全双工，推送延迟更低，完全匹配应用内实时通知的需求。
• SSE更适合单向、无需客户端交互的场景（比如新闻推送），且浏览器对SSE的并发连接数有限制，不适合给数千用户批量推送。

WebSockets的优化细节 #

• 用Redis Pub/Sub做集群消息同步：如果你的Node.js应用是多实例部署，单个实例只持有当前连接的用户，需要通过Redis把推送给某用户的消息广播到所有实例，由持有该用户连接的实例完成推送。
• 批量推送：给数千用户发同类型通知时，不要循环调用ws.send()，可以先缓存消息，再用WebSocket的广播功能（比如用Socket.io这类库）批量发送。
• 心跳机制：检测用户的WebSocket连接状态，避免向离线用户推送，减少无效操作。

避免过度设计的实用技巧 #

1. 最小化引入队列：一开始只做核心的异步任务分发，不用搞复杂的任务调度、监控，先解决卡顿问题再说。
2. 复用现有逻辑：你已经验证过的数据库触发器合并通知逻辑，完全不用改动，只需要把通知创建操作从API移到消费者进程。
3. 逐步迭代：先上线Redis队列+单消费者进程，观察性能；如果后续用户量增长到十万级，再考虑拆分独立通知服务、增加消费者实例、引入监控告警。

落地步骤参考 #

1. 在K8s部署Redis实例（用StatefulSet或第三方Operator均可）。
2. 用ioredis库在Node.js应用中实现生产者（API端点发消息）和消费者（独立进程监听队列）。
3. 修改API端点：把原来同步执行的通知创建+推送逻辑，替换成向Redis队列发送任务消息，立即返回响应。
4. 编写独立的通知消费者进程：监听队列消息，执行数据库通知创建（触发合并逻辑），然后向在线用户推送WebSocket消息。
5. 配置K8s Deployment，让消费者进程以2-3个实例运行，分摊任务压力。

内容的提问来源于stack exchange，提问作者Denis Yakovenko