RabbitMQ 深度实践：在 Kubernetes 上构建生产级消息队列

Tue, 16 Jun 2026 10:00:00 +0800

服务已经全面上了 Kubernetes，但消息队列还孤零零地跑在一台虚机上——这是很多团队在云原生迁移中都会遇到的阶段性尴尬。消息队列的 K8s 化比无状态服务复杂得多：数据持久化、集群选主、滚动升级期间的消息可靠性，每一项都需要在部署前想清楚。

本文面向已在 K8s 上运维过服务、正在考虑引入或迁移消息队列的工程师。内容沿"选型 → 核心概念 → 生产部署 → 高可用 → 可观测性 → 业务落地 → 故障排查"这条工程路径展开，读完后你能独立完成 RabbitMQ 在 K8s 上的全链路落地。

一、先做选型：RabbitMQ、Kafka、RocketMQ 如何抉择

在深入 RabbitMQ 之前，先用 3 个问题确认它是否适合你的场景——如果答案都是"否"，后续内容可能不适合你现在的需求。

决策树：

Q1. 你的消息需要"消费后保留并支持历史回放"吗？
 ├── 是 → 考虑 Kafka（事件日志语义）
 └── 否 → 继续 Q2

Q2. 单队列 TPS 是否超过 10 万/s？
 ├── 是 → 考虑 Kafka 或 RocketMQ（吞吐优先场景）
 └── 否 → 继续 Q3

Q3. 是否需要分布式事务消息或精确到秒的延迟消息？
 ├── 是 → 考虑 RocketMQ（电商事务场景原生支持）
 └── 否 → RabbitMQ 是你的首选

如果你走到了最后一个"否"，那么 RabbitMQ 的低延迟（<1ms）、灵活路由（多种 Exchange 类型）和成熟的 K8s Operator 是难以替代的优势。

Middleware on Zhengdong.jzd 个人博客

RabbitMQ 深度实践：在 Kubernetes 上构建生产级消息队列

一、先做选型：RabbitMQ、Kafka、RocketMQ 如何抉择