大讲堂
被低估的“消息水管”：技术边界到底在哪
大部分人对消息队列的认知，从一开始就偏了。觉得它就是个存消息的池子，生产者扔进去，消费者捞出来就行。错。RabbitMQ从设计之初，核心就不是“存”，是AMQP 0-9-1协议的原生路由逻辑——消息根本不会直接进队列，是先到交换机，根据你绑定的路由规则，把消息扔到对应的队列里。
拥挤的赛道：RabbitMQ的生态位正在被两边挤
现在做消息队列的赛道，挤得像早高峰的地铁。 一边是往上冲的云原生新贵：Kafka、Pulsar，单集群几十万甚至上百万QPS，存算分离，生态越来越全。另一边是往下沉的轻量选手：Redis Stream、NATS，单节点性能拉满，部署简单，连个配置文件都不用写。再加上各个云厂商自研的消息队列，从RocketMQ到CMQ，从云Kafka到云RabbitMQ，用户的选择多到挑花眼。
落地的坑：90%的团队都栽在配置上
见过太多团队，把RabbitMQ用成了“故障制造机”。 不是工具的问题，是配置的问题。 最常见的坑：不设队列的TTL。消息扔进去，消费者因为各种原因挂了，就永远在队列里堆着，从几十条堆到几十万条，再堆到几个G，最后把节点的磁盘打满，整个集群直接不可用。上次帮客户排查的事故，就是这个原因——他们给用户发优惠券的通知队列，消费者因为第三方短信接口挂了，停了三个小时，没人管，最后堆了2个G的消息，集群磁盘满了，连带着所有其他队列的消息都发不出去。 还有的坑：把RabbitMQ当缓存用。往队列里扔业务的临时数据，指望队列帮你存几个月，根本没想过队列的设计是为了“过手”消息，不是为了存数据。最后集群的存储成本高得离谱，还动不动就出问题。 更离谱的，是权限管控形同虚设。整个RabbitMQ集群的管理员密码，全公司开发都知道。去年有个朋友的团队，新来的实习生以为队列里的堆积消息是垃圾数据，直接点了删除，一下清了三个小时的订单消息，光挽回损失就花了十几万。 治理层面的问题就更多了：大部分团队的监控，只看集群是不是活着，根本不监控队列的积压量、消费者的处理速率、消息的生产速率。等告警弹出来的时候，积压已经到了千万级，就算把所有消费者拉满，也要十几个小时才能消费完，业务早就受影响了。还有的团队根本不做消息的幂等处理，消费者重复消费一次，就给用户发两次优惠券，扣两次库存，这种低级事故，每年都要在各个公司上演一遍。 聊到最后，说点实在的，未来三五年RabbitMQ会去哪？ 首先，它不会被淘汰。别信什么“老技术马上被淘汰”的鬼话，全球那么多中小团队，10个人以内的创业公司，谁有精力去搭一套Pulsar集群？谁能搞定Kafka那复杂的消费者组配置？RabbitMQ开箱即用的特性，对小团队来说就是刚需。这个生态位，没有任何一个新玩家能抢得走。 其次，它会越来越贴合云原生的趋势。现在已经有了官方的K8s Operator，支持一键部署集群，后续肯定会打通对象存储的存算分离架构，把消息存在低成本的对象存储里，降低用户的存储成本。以后你不用再为了存几个T的消息，买一堆高配置的SSD服务器，成本能降一大截。 最后，它会守住自己的基本盘，不会去硬卷百万级QPS的场景。就守着万级QPS、需要灵活路由、对可靠性要求高的那些场景：订单拆分、库存扣减、异步通知、工作流任务分发。不去跟Kafka抢日志流的市场，不去跟RocketMQ抢金融级交易的市场，就做最适合中小团队的那个消息队列。 上周帮朋友把那个堵了3个G的队列清完，顺手给他们加了死信队列和积压告警，运维群里终于不用半夜弹那些吓人的红告警了。 技术哪有什么银弹啊。 选对适合自己场景的工具，比追最新的技术栈，重要多了。作者|fawen
排版|fawen
审核|小北