消息队列为谁而生：削峰与解耦

发布时间:2025-12-17 01:48

## 概念 消息队列是在业务各环节之间插入的一层缓冲区：上游把消息丢进去就返回，下游按自己的节奏取出来处理。它解决的是两个古老问题：瞬时的流量尖峰把下游压垮，以及多个系统之间调用关系缠成一团。理解这两个用途，比记住任何一款产品的名字都重要，产品会换，问题形态不变。 ## 原理：两个核心价值 削峰把瞬时压力变换成平均压力。秒杀开始的一瞬间涌入十万请求，数据库直接写必然崩掉；改成写队列再由消费者匀速处理，峰值被削平成一条平稳的消费曲线，系统容量按平均值规划即可。解耦把直接调用换成间接传递。订单产生后要通知库存、积分、短信三个系统，直连意味着改一处动全身；订单服务只管发一条消息，谁关心谁订阅，新增消费方不用惊动生产方，团队边界也跟着清晰。 ## 最小实操与堆积预案 ``` redis-cli LPUSH task:mail "order 1001" ``` 轻量场景用 Redis 的列表就能搭起一进一出的队列原型，生产规模再换专业产品。重点说堆积：消费者处理不动、消息越积越多，是引入队列后必然遭遇的考验。预案要有三条：消费速率与生产速率的监控分开画线，堆积量持续增长立刻告警；设计好消息的过期与丢弃策略，过期数据宁丢勿堵；扩消费者实例前先确认处理逻辑支持并行，否则扩了也白扩。 ## 常见错误 一是把队列当万能缓冲，掩盖了下游本身的性能缺陷，堆积常态化后队列从保险变成延时本身；二是没设计幂等，消息重投时业务重复执行，账算错比慢更严重；三是无死信通道，处理失败的消息消失在日志里，问题无从追溯。顺云云服务器上自建队列服务时，把磁盘容量按峰值堆积时长做预算，监控告警配在堆积量而不是消费速率上，这两个习惯能挡住大部分事故。