消息队列选型与架构落地：Kafka与RabbitMQ高并发场景对比

高并发系统里消息队列承担削峰填谷、异步解耦与流量控制三个职责，选型错误会在业务量上来后频繁踩坑。Kafka和RabbitMQ是使用最广的两类消息中间件，设计目标截然不同：Kafka面向高吞吐日志型流数据，RabbitMQ面向可靠投递的业务消息。本文从吞吐、可靠性、消费模型三个维度对比，给出不同业务场景的选型结论与落地配置。

吞吐量与消息模型的核心差异

Kafka以分区为单位存储消息，分区内严格有序，多个分区并行读写，单个broker即可支撑每秒百万条级别的写入。RabbitMQ基于AMQP协议，每条消息都要经过exchange路由到queue，确认与持久化开销更高，单机吞吐通常在每秒几万到十几万条。

消费模型上，Kafka是拉取式（pull），消费者按offset自主控制进度，天然支持消息回溯重放；RabbitMQ是推送式（push）配合手动ack，更适合一条消息需要精确处理一次的场景。日志采集、埋点上报、流式计算选Kafka；订单通知、邮件短信、任务分发选RabbitMQ。

Kafka高吞吐集群配置要点

Kafka的吞吐瓶颈通常在磁盘IO与网络，配置重点是分区数、副本数与批处理参数。生产环境建议分区数按消费者实例数对齐，避免单分区热点：

# server.properties
num.partitions=12
log.retention.hours=72
log.segment.bytes=1073741824

# producer 侧批处理参数
batch.size=16384
linger.ms=5
acks=all

linger.ms控制发送端攒批等待时间，吞吐敏感场景调到5-20ms，延迟敏感场景保持0。消费端用enable.auto.commit=false配合手动提交位移，处理完成后再提交，防止异常崩溃导致消息丢失。

RabbitMQ高可用部署：镜像队列与优先级

RabbitMQ可靠性靠队列镜像与消息确认两级保障，生产配置采用镜像队列（quorum queue）把消息复制到多个节点：

rabbitmqctl set_policy ha-all ".*"   '{"ha-mode":"exactly","ha-params":3,"ha-sync-mode":"automatic"}'

生产者开启publisher confirm，消费者使用manual ack并在处理失败时重新入队：

channel.confirmSelect()
channel.basicConsume("task_queue", false,
  (consumerTag, delivery) => {
    try {
      process(delivery.content)
      channel.ack(delivery.deliveryTag)
    } catch (e) {
      channel.nack(delivery.deliveryTag, false, true)
    }
  })

优先级队列通过x-max-priority参数声明，会员下单等核心业务消息可插队处理，但不要过多依赖优先级，队列倾斜会造成低优先级消息长时间饥饿。

消息不丢失与幂等消费的完整链路

消息不丢要同时保证生产端、Broker、消费端三段不丢。生产端确认、Broker持久化（Kafka的acks=all + min.insync.replicas、RabbitMQ的persistent消息）、消费端手动ack，三段链路缺一不可。

网络抖动导致的消息重复在分布式系统中无法完全避免，消费端必须做幂等。常见做法是业务表加唯一约束（订单号、流水号），或用Redis setNX记录消息ID：

SETNX msg:order:10086 1 EX 86400

已处理过的消息ID在Redis中已存在时直接跳过业务逻辑，能兜住重复投递。消费失败重试要设置最大重试次数与死信队列，避免坏消息无限重试拖垮集群。

选型决策框架与迁移路线

决策时可以按三个问题判断：消息量级是否长期超过每秒十万条；是否需要消息回溯与重放；消费模式是流式处理还是任务式分发。前两个回答是、第三个是流式，选Kafka，其余场景RabbitMQ足够。业务同时需要两种特性时，用Pulsar替代（同时支持队列与流模型），或按边界拆分：日志走Kafka，业务通知走RabbitMQ。

老系统从RabbitMQ迁移Kafka时，先做双写灰度，消费端兼容两个消息源的格式，验证数据一致后再切流，避免一次性替换导致消息顺序错乱。