每秒50k WebSocket消息场景：Redis Streams缓冲vs双异步写入孰优？

方案B更优，核心原因如下： #

• 隔离WebSocket处理层的压力：方案A里，WebSocket handler既要执行异步PostgreSQL写入，又要推送Redis Stream到前端。但PostgreSQL写入哪怕是异步，也绕不开数据库连接池限制、磁盘IO延迟、锁竞争等问题。每秒50k的量级下，只要数据库出现波动，WS handler就会被阻塞，轻则消息堆积，重则直接崩溃导致WebSocket连接断连。方案B中，WS handler仅需将消息快速写入Redis Stream——这是内存级操作，延迟微秒级，能牢牢守住消息摄入的入口稳定性。
• 任务解耦+弹性伸缩：方案B将写库和推前端拆分为独立的消费者进程。比如数据库写入效率低时，直接增加写库消费者的数量即可；前端推送压力大时，单独扩容前端消费者。方案A的两个任务绑定在WS handler中，扩容只能整体调整，无法针对性分配资源，造成极大浪费。
• 容错能力更强：Redis Stream自带持久化和ACK确认机制，哪怕某个消费者进程挂掉，消息也不会丢失，重启后可继续处理。方案A中如果写库失败，还需在WS handler中添加重试逻辑，本就繁忙的WS层会雪上加霜；方案B的消费者可单独处理重试、死信队列等逻辑，完全不影响消息摄入。

进一步优化的方案 #

• Redis Stream分区+消费者组：单条Redis Stream的吞吐上限约为每秒10万，50k虽未达顶，但通过拆分多个Stream分区、为每个分区配置独立消费者组，可进一步提升并行处理能力，避免单Stream成为瓶颈。
• PostgreSQL批量写入：消费者不要单条写入数据库，可攒够100条消息或等待100ms后执行批量插入，能将数据库写入吞吐量提升数倍，同时减少连接开销。
• 前端推送分层：如果前端是WebSocket集群，不要让消费者直接推送给每个前端连接，改为消费者将消息存入Redis Pub/Sub，前端WS服务订阅Pub/Sub后再广播给用户，这样能减少消费者的连接压力，更适配集群场景。
• 监控兜底：监控Redis Stream的消息堆积量、消费者处理延迟、PostgreSQL写入QPS等指标，一旦堆积超过阈值就自动扩容消费者，提前规避雪崩风险。

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