公司刚上微服务那会儿，消息队列选了RabbitMQ。一开始觉得就是个发发通知的工具，随便配配就行。结果上线没几天，消息积压、连接打满、偶尔还抽风断连，排查起来头都大了。
别让默认配置坑了你
刚装完RabbitMQ，默认是允许guest用户从远程登录的。本地测试没问题，一上生产就出事。有次被扫描到，差点被人当成跳板。改的第一件事就是删掉guest，新建用户加权限：
rabbitmqctl add_user myuser mypassword
rabbitmqctl set_permissions -p / myuser ".*" ".*" ".*"还有那个默认的磁盘预警阈值，40GB才报警。小机器哪扛得住？我们那台80G的服务器，消息一多直接写满，服务全挂。后来改成内存或磁盘剩10%就告警，配合监控系统发钉钉，才算稳住。
镜像队列不是万能的
听说镜像队列能高可用，立马整个集群三节点，队列全设成镜像。结果主节点一抖，同步延迟飙升，消费卡住。查了半天才发现，网络波动时，镜像队列会阻塞生产者。
后来调整策略，核心订单类走镜像，日志类就单点加持久化。毕竟不是所有消息都那么重要，日志丢了也能接受。
持久化别漏了这三个地方
光把消息标成delivery_mode=2还不行。交换机、队列、消息三者都得持久化，少一个都可能丢数据。
有次重启后队列没了，才发现创建队列时没勾durable。代码里补上：
channel.queue_declare(queue='task_queue', durable=True)生产者也得确认机制打开，不然发出去就不管了。confirm模式一开，配合重试，心里踏实多了。
连接和通道管理要上心
早期服务每次发消息都新建连接，用完还不关。跑两天连接数上千，RabbitMQ直接拒绝新连接。后来统一用连接池，一个服务维持几个长连接，按业务分通道。
通道也不乱用，不同业务分开，避免一个业务异常影响其他。
监控不能只看界面
Web管理界面看着挺直观，但没人一直盯着。我们接了Prometheus + Grafana，关键指标全画图：队列长度、消费者数、未确认消息、连接数。
有一次图上突然队列堆积上涨，一看是下游服务更新后消费逻辑卡住了，及时回滚，避免问题扩大。
合理设置TTL和死信队列
有些任务最多等5分钟，超时就没意义了。给消息加TTL：
channel.queue_declare(queue='order_queue', arguments={
"x-message-ttl": 300000, // 5分钟
"x-dead-letter-exchange": "dlx.exchange"
})超时的消息自动进死信队列，后面再分析原因。既不卡主流程，又能追溯问题。
这些配置调下来，RabbitMQ才算真正稳了。原来真不是装完就能跑的玩具，每个参数背后都是血泪教训。