<p style="text-align:center"><img src="https://www.171host.com/wp-content/uploads/2026/11/20261102175035-6ae8cd6b920f1.png" alt="封面图" style="max-width:100%;height:auto" /></p>
记一次消息队列选型对比线上排查：Kafka/RabbitMQ/Pulsar 技术选型
凌晨三点报警群炸了，消息积压百万条，消费者扛不住。很多兄弟选型时只看名气，不看场景，最后运维火葬场。今天不聊虚的，直接扒开 Kafka、RabbitMQ、Pulsar 的底裤，聊聊生产环境最容易踩的 3 个坑。
吞吐量与延迟的博弈
很多新人一上来就无脑 Kafka，觉得吞吐量大就是好。但如果你做的是即时通讯或订单状态通知，毫秒级延迟才是命门。RabbitMQ 基于 Erlang 虚拟机，延迟极低，但吞吐量上限明显。Kafka 是顺序写磁盘，吞吐无敌，但延迟波动大。
看个 Kafka 生产者配置，别默认瞎用：
producer = KafkaProducer(
bootstrap_servers=['localhost:9092'],
acks='all', # 关键配置
retries=3
)
输出效果：acks='all' 保证数据不丢，但吞吐量下降 30%。如果业务允许丢少量日志，改成 acks=1 能显著提升速度，别为了安全牺牲性能。
消息积压的终极解法
生产环境最怕积压。RabbitMQ 积压多了会拖垮内存，Kafka 积压在磁盘还好说，但消费速度跟不上也白搭。Pulsar 的存算分离架构在这里是杀手锏，Segment 机制让扩容消费组无需迁移数据。
RabbitMQ 设置死信队列防止阻塞：
arguments:
x-message-ttl: 60000
x-dead-letter-exchange: "dlx.exchange"
输出效果：消息 60 秒未消费自动转入死信队列，主队列不被阻塞，方便后续单独回放处理，避免雪崩。
事务与一致性陷阱
涉及资金交易，必须考虑事务消息。Kafka 支持事务但重量级，RabbitMQ 靠 Confirm 机制，Pulsar 原生支持事务且性能损耗小。别为了简单牺牲一致性，否则对账能対死你。
Pulsar 消费者订阅模式选择：
consumer.newConsumer()
.subscriptionType(SubscriptionType.Failover)
.subscribe();
输出效果：Failover 模式主备切换秒级生效，避免 Shared 模式下的消息重复处理，保证订单逻辑幂等性，资金安全才有底。
运维老兵避坑清单
1. 日志采集无脑 Kafka，业务通知优先 RabbitMQ。
2. 涉及金融交易，检查是否开启事务或 Confirm 机制。
3. 预估积压量，超过磁盘阈值必须上 Pulsar 或扩容。
4. 别忽略网络带宽，千兆网卡跑不满 Kafka 吞吐量。
5. 监控告警必须覆盖消费 lag，别等报警才处理。
架构没有银弹，只有合适。你现在的项目里，消息队列最怕出什么问题？
