如何存储websocket接收的消息避免丢失 低成本消息队列选型咨询

结论先行：根据你团队的业务规模选即可，两种方案都能解决你的问题，不用纠结 #

首先先解决你提到的场景2的低级问题：变量覆盖根本和队列选型无关，是你的代码写法问题。你把$msg按引用传递给异步写库函数，后续变量被修改当然会导致写入内容出错，只要每次收到消息后对$msg做深拷贝生成独立的不可变对象，再传入写库逻辑，就能直接规避这个问题，这是后续所有方案的前提。

方案1：DAU<10万、日消息量<100万级，优先用轻量自研队列 #

完全没必要额外部署维护MQ组件，凭空增加运维成本，用语言内置的线程安全队列就能搞定：

• 收到websocket消息后，第一时间做两个无阻塞操作：
  • 直接转发消息给目标用户，完全不引入额外延迟
  • 把深拷贝后的消息对象推入线程安全的FIFO队列（不需要自己从零实现数据结构，绝大多数编程语言都有成熟的内置实现：比如Go的无缓冲/有缓冲channel、Python的queue.Queue、Java的ConcurrentLinkedQueue、Node.js的bull轻量队列等，稳定性都经过了大规模验证）
• 单独启动1~N个独立的消费常驻线程/协程，专门从队列拉取消息，批量写入数据库：可以设置攒满50条或者间隔200ms刷一次库，比单条写入性能高10倍以上，完全扛得住普通规模的消息量
• 加两个兜底逻辑即可：进程收到退出信号时，先把队列中剩余的所有消息刷入数据库再退出；运行时监控队列长度，超过阈值就触发告警，提前规避堆积风险

方案2：DAU≥10万、日消息量≥1000万级，直接上成熟MQ，优先选RabbitMQ #

业务规模上来之后，自研队列的内存上限、进程崩溃消息丢失的问题会凸显，直接用成熟MQ更省心：

• 优先选RabbitMQ而不是Kafka：你的场景核心诉求是消息低延迟、可靠不丢，不需要Kafka面向日志场景的超高吞吐能力，RabbitMQ部署更轻量，运维门槛更低，天然支持消息持久化、重试、死信队列等能力，完全匹配聊天消息存储的需求
• 逻辑和自研队列一致：收到消息转发完成后，直接把消息发往MQ，单独的消费服务消费MQ消息批量写库即可，不需要自己处理队列持久化、异常重试、分布式部署下的队列调度等逻辑，踩坑更少

额外优化建议 #

不管选哪种方案，都不要用单条SQL写数据库，批量写入的性能提升是最显著的，也能大幅降低数据库的IOPS压力，避免写入阻塞。

备注：你提到的高成本云厂商实时数据库确实没必要，上述两种方案的成本都非常低，完全能满足中小规模聊天系统的需求。

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