消息队列选型：Kafka vs RabbitMQ vs Pulsar，在监控场景下的优劣对比
做实时监控系统，消息队列是绕不开的中间件。说白了，它就是整个系统的「数据高速公路」。路修得不好，数据堵车、丢包、延迟，监控就废了。
我个人习惯，选型前先问自己三个问题：数据量多大？延迟要求多高？运维能力够不够？这三个问题问完，选型方向基本就定了。
今天咱们就聊聊监控场景下，Kafka、RabbitMQ、Pulsar 这三兄弟到底怎么选。我踩过的坑不少，希望能帮你少走弯路。
先看一张整体对比图
下面这张图，是我自己总结的。它把三个消息队列在监控场景下的核心差异画出来了。你一看就明白，它们各自擅长什么。
Kafka：吞吐量之王，但延迟不是它的强项
Kafka 在监控场景下，最大的优势就是吞吐量。我做过一个项目，每天要处理几十亿条行情 tick 数据。用 Kafka，单机就能扛住每秒几十万条写入。这得益于它的「顺序读写」和「零拷贝」技术。
但这里有个坑。Kafka 的延迟，其实没那么低。它为了吞吐量，做了批量处理。你想想看，攒一批消息再发，延迟自然就上去了。在毫秒级延迟要求下，Kafka 可能不太够用。
监控场景适用点：
- 海量日志采集（系统日志、应用日志）
- 监控指标聚合（CPU、内存、网络等）
- 需要消息回溯的场景（比如回放历史数据）
我曾经踩过的坑：
有一次，我把 Kafka 的分区数设到了 2000 个。结果集群 rebalance 花了整整 40 分钟。期间整个系统不可用。后来我才知道，Kafka 的分区数建议控制在 1000 以内。分区太多，Leader 选举和 Rebalance 都会出问题。
RabbitMQ：低延迟的王者，但别让它扛大流量
RabbitMQ 的延迟能做到微秒级。这在交易系统中非常关键。我记得有一次做高频交易信号分发，要求端到端延迟小于 1 毫秒。RabbitMQ 是当时唯一能满足要求的。
但它的吞吐量是硬伤。单机撑死了也就几万条/秒。你想想看，如果每秒有几十万条行情数据涌进来，RabbitMQ 直接就崩了。
另外，RabbitMQ 的消息回溯能力很弱。消息一旦被消费确认，基本就丢了。这在监控场景下是个大问题。你想查一下 10 分钟前的某个告警消息，对不起，查不到。
监控场景适用点：
- 实时告警推送（延迟敏感）
- 交易信号分发（微秒级要求）
- 小规模、高可靠的消息路由
我的建议：
如果你用 RabbitMQ 做监控，一定要开启 lazy queues 模式。默认情况下，RabbitMQ 把消息存在内存里。一旦内存爆了，系统就 OOM 了。Lazy 模式会把消息刷到磁盘，虽然慢一点，但稳很多。
Pulsar：后起之秀，但生态还不够成熟
Pulsar 是这三者里最年轻的。它最大的特点是计算存储分离。说白了，就是 Broker 只管计算，数据存在 BookKeeper 里。这样扩容非常灵活。
在监控场景下，Pulsar 的「分层存储」很实用。热数据存在 SSD 里，冷数据自动迁移到 HDD 甚至 S3。这样既能保证近期数据的查询速度，又能低成本保存历史数据。
但说实话，Pulsar 的坑也不少。我去年在一个项目里试过 Pulsar，结果遇到了好几个 bug。社区虽然活跃，但文档和最佳实践还不够完善。如果你团队里没有熟悉 Pulsar 的人，建议谨慎。
监控场景适用点：
- 云原生环境（Kubernetes 部署）
- 多租户场景（不同业务线共用集群）
- 需要长期保存监控数据的场景
我曾经踩过的坑：
Pulsar 的客户端连接数管理，跟 Kafka 完全不一样。我一开始用 Kafka 的思路去配 Pulsar 的 Producer，结果连接数暴涨，把 Broker 打挂了。后来才发现，Pulsar 的 Producer 是异步的，需要合理控制并发数。
选型决策矩阵
下面这张表，是我在实际项目中总结的。你可以根据自己的需求，对着打分。
| 评估维度 | Kafka | RabbitMQ | Pulsar |
|---|---|---|---|
| 吞吐量（百万级/秒） | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| 延迟（微秒级） | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 消息回溯 | ⭐⭐⭐⭐ | ⭐ | ⭐⭐⭐⭐⭐ |
| 运维复杂度 | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
| 社区生态 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 云原生支持 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
我的最终建议
说了这么多，到底怎么选？我个人的经验是：
- 如果你做的是海量日志采集、监控指标聚合，选 Kafka。它皮实耐操，社区资源丰富，遇到问题随便一搜就有答案。
- 如果你做的是实时告警推送、交易信号分发，选 RabbitMQ。它的低延迟是硬通货，但注意控制流量。
- 如果你在云原生环境，或者需要多租户支持，可以试试 Pulsar。但要做好踩坑的心理准备。
其实，很多大型监控系统是混合使用的。比如，用 Kafka 收海量日志，用 RabbitMQ 推实时告警。各取所长，才是最佳实践。
一个小技巧：
不管你选哪个，一定要做好消息积压监控。我见过太多系统，消息队列积压了几百万条，监控系统还在那傻傻地跑。等发现的时候，数据已经延迟了十几分钟。在交易系统里，这十几分钟可能就是几百万的损失。
公众号:蓝海资料掘金营，微信deep3321