记一次消息队列选型对比线上排查：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 模式下的消息重复处理，保证订单逻辑幂等性，资金安全才有底。

架构没有银弹，只有合适。你现在的项目里，消息队列最怕出什么问题？