mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
3698 字
10 分钟
消息队列选型
2026-05-08

选错消息队列的代价不是”性能差一点”——而是未来两年每次架构演进都要和这个错误决定搏斗。选了 RabbitMQ 做日志流,吞吐量上不去只能堆机器;选了 Kafka 做业务消息路由,每个场景都要写消费者代码模拟 Exchange;选了 RocketMQ 却发现团队没有 Java 经验,运维全靠复制粘贴配置。消息队列选型不是”哪个更好”的问题,而是”哪个更适合你的场景”——数据模型、路由需求、语义要求、运维能力,每个维度都决定着系统的上限。

一、四大消息系统定位#

1.1 核心定位#

系统一句话定位核心优势核心劣势
Kafka分布式事件流平台高吞吐、日志保留、流处理运维复杂、无灵活路由
RabbitMQ企业消息中间件灵活路由、低延迟、协议标准吞吐有限、无消息回放
RocketMQ金融级消息中间件事务消息、延迟消息、顺序消息社区偏中文、生态有限
Pulsar云原生消息平台存算分离、多租户、Geo 复制生态不成熟、运维复杂
graph TB Q["选择消息队列"] --> Q1["核心需求是什么?"] Q1 -->|"高吞吐日志流"| KAFKA["Kafka"] Q1 -->|"灵活路由+低延迟"| RABBIT["RabbitMQ"] Q1 -->|"事务+延迟+顺序"| ROCKET["RocketMQ"] Q1 -->|"云原生+多租户"| PULSAR["Pulsar"] Q1 -->|"不确定"| Q2["吞吐量要求?"] Q2 -->|"> 10万 TPS"| KAFKA Q2 -->|"< 10万 TPS"| Q3["需要灵活路由?"] Q3 -->|"是"| RABBIT Q3 -->|"否"| Q4["需要事务消息?"] Q4 -->|"是"| ROCKET Q4 -->|"否"| KAFKA

1.2 架构哲学对比#

维度KafkaRabbitMQRocketMQPulsar
数据模型分区日志(Partition)队列(Queue)队列(Queue)分区日志(Ledger)
路由模型无路由(按分区分配)智能路由(Exchange)Topic + TagTopic + Subscription
消费模型拉取(Pull)推送(Push)拉取(Pull)推送 + 拉取
消息保留时间/大小消费后删除时间/大小时间/大小/策略
消息回放支持不支持支持支持

二、全维度对比#

2.1 性能对比#

维度KafkaRabbitMQRocketMQPulsar
单机吞吐100万+ TPS万级 TPS10万+ TPS10万+ TPS
延迟毫秒级微秒级毫秒级毫秒级
消息大小MB 级KB~MB 级KB~MB 级MB 级
分区/队列上限数千数百数千数千

2.2 可靠性对比#

维度KafkaRabbitMQRocketMQPulsar
消息持久化磁盘 + 副本可选持久化磁盘 + 副本BookKeeper 副本
副本机制ISRQuorum Queue主从同步Ledger Quorum
exactly-once支持(事务 API)不支持支持(事务消息)支持
消息确认Producer ACKPublisher Confirm + Consumer ACKProducer ACK + Consumer ACKCursor ACK
死信队列手动实现原生支持内置重试 Letter

2.3 功能对比#

功能KafkaRabbitMQRocketMQPulsar
事务消息事务 API不支持原生支持不支持
延迟消息不支持插件支持原生支持原生支持
顺序消息分区有序队列有序原生支持Key_Shared
消息过滤Tag + SQL92
消息回溯按 Offset/时间不支持按时间戳按 Cursor
Schema 管理Schema Registry不支持不支持原生 Schema
多租户不支持Virtual Host不支持原生支持
Geo 复制MirrorMaker 2Federation不支持原生支持
流处理Kafka Streams不支持不支持Pulsar Functions

2.4 运维与生态对比#

维度KafkaRabbitMQRocketMQPulsar
部署复杂度
监控工具多(Kafka Manager 等)多(Management UI)
社区生态最成熟成熟中文社区成长中
学习曲线
K8s 支持StrimziOperatorOperatorOperator
商业支持ConfluentVMware阿里云StreamNative
客户端语言Java/Go/Python/…Java/Python/Go/…Java/Go/C++Java/Go/Python
管理界面多种第三方内置 ManagementDashboardManager

2.5 深入架构对比#

四大系统的架构差异决定了它们的能力边界:

Kafka:分布式提交日志

Kafka 把消息当作不可变的日志记录,追加写入分区,消费者通过 Offset 随机访问。这种设计天然适合高吞吐顺序读写,但也意味着没有”消息已消费就删除”的概念——消息保留由策略决定,与消费状态无关。

// Kafka 的核心抽象:分区日志
// 每个 Topic 由多个 Partition 组成,Partition 内消息有序
// 消费者通过 Offset 标记消费位置
Properties props = new Properties();
props.put("bootstrap.servers", "kafka:9092");
props.put("key.serializer", StringSerializer.class.getName());
props.put("value.serializer", StringSerializer.class.getName());
props.put("acks", "all"); // 等待所有 ISR 确认
props.put("enable.idempotence", "true"); // 幂等生产者
props.put("compression.type", "lz4"); // 压缩减少网络开销
KafkaProducer<String, String> producer = new KafkaProducer<>(props);
// 发送到指定分区(按 Key hash),保证同 Key 有序
producer.send(new ProducerRecord<>("order-events", orderId, orderJson));

RabbitMQ:智能路由的队列模型

RabbitMQ 的 Exchange 是消息路由的核心——Producer 不直接发到 Queue,而是发到 Exchange,由 Exchange 根据 Binding 规则路由到 Queue。这种设计天然支持复杂的消息分发场景。

// RabbitMQ 的核心抽象:Exchange → Binding → Queue
// Producer 发到 Exchange,Exchange 路由到 Queue
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("rabbitmq");
try (Connection conn = factory.newConnection();
Channel ch = conn.createChannel()) {
// 声明 Topic Exchange
ch.exchangeDeclare("order-events", "topic", true);
// 绑定:order.new → 支付队列
ch.queueBind("payment-queue", "order-events", "order.new");
// 绑定:order.# → 通知队列(# 匹配多级)
ch.queueBind("notify-queue", "order-events", "order.#");
// 发布消息
ch.basicPublish("order-events", "order.new",
MessageProperties.PERSISTENT_TEXT_PLAIN, orderJson.getBytes());
}

RocketMQ:金融级可靠性

RocketMQ 的事务消息是它最独特的特性——通过两阶段提交 + 回查机制,保证本地事务和消息发送的原子性。这在电商、金融场景中是刚需。

// RocketMQ 事务消息:两阶段提交 + 回查
TransactionMQProducer producer = new TransactionMQProducer("order-group");
producer.setTransactionListener(new TransactionListener() {
@Override
public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
try {
// 执行本地事务:创建订单
orderService.createOrder(parseOrder(msg));
return LocalTransactionState.COMMIT_MESSAGE;
} catch (Exception e) {
return LocalTransactionState.ROLLBACK_MESSAGE;
}
}
@Override
public LocalTransactionState checkLocalTransaction(MessageExt msg) {
// 回查:订单是否创建成功?
Order order = orderService.getById(parseOrderId(msg));
return order != null ? COMMIT_MESSAGE : ROLLBACK_MESSAGE;
}
});

Pulsar:存算分离的云原生架构

Pulsar 把存储层(BookKeeper)和计算层(Broker)分离,Broker 无状态可以随意扩缩容,数据持久化由 BookKeeper 保证。这种架构天然适合云环境和多租户场景。

// Pulsar 的多租户 + 多订阅模式
PulsarClient client = PulsarClient.builder()
.serviceUrl("pulsar://pulsar:6650").build();
// 租户/命名空间隔离
Producer<String> producer = client.newProducer(Schema.STRING)
.topic("persistent://tenant-1/order-ns/order-events")
.enableBatching(true)
.batchingMaxMessages(1000)
.create();
// 多种订阅模式:Exclusive / Failover / Shared / Key_Shared
Consumer<String> consumer = client.newConsumer(Schema.STRING)
.topic("persistent://tenant-1/order-ns/order-events")
.subscriptionName("payment-sub")
.subscriptionType(SubscriptionType.Key_Shared) // Key 有序
.subscribe();

三、场景匹配#

3.1 典型场景推荐#

场景推荐系统原因
日志收集Kafka高吞吐、日志保留、多消费者
用户行为追踪Kafka高吞吐、消息回放
事件驱动架构Kafka / Pulsar事件保留、流处理
订单状态变更RocketMQ事务消息、顺序消息
支付回调RocketMQ事务消息、高可靠
任务分发RabbitMQ灵活路由、低延迟
RPC 异步调用RabbitMQ请求-回复模式、低延迟
配置变更通知RabbitMQFanout 广播、低延迟
多租户 SaaSPulsar原生多租户、资源隔离
跨区域复制Pulsar原生 Geo 复制
IoT 数据接入Pulsar多协议、分层存储

3.2 选型决策树#

graph TD START["选择消息队列"] --> Q1{"吞吐量 > 10万 TPS?"} Q1 -->|"是"| Q2{"需要灵活路由?"} Q1 -->|"否"| Q3{"需要事务消息?"} Q2 -->|"是"| WARN["Kafka 吞吐高但无路由<br/>考虑 Pulsar"] Q2 -->|"否"| KAFKA["Kafka"] Q3 -->|"是"| ROCKET["RocketMQ"] Q3 -->|"否"| Q4{"需要灵活路由?"} Q4 -->|"是"| Q5{"需要消息回放?"} Q4 -->|"否"| Q6{"需要多租户?"} Q5 -->|"是"| PULSAR["Pulsar"] Q5 -->|"否"| RABBIT["RabbitMQ"] Q6 -->|"是"| PULSAR2["Pulsar"] Q6 -->|"否"| Q7{"团队经验?"} Q7 -->|"Java"| KAFKA2["Kafka"] Q7 -->|"Erlang/多语言"| RABBIT2["RabbitMQ"]

3.3 场景深度匹配#

金融交易场景

金融交易对消息可靠性要求极高——消息不能丢、不能重复、顺序不能乱。RocketMQ 的事务消息 + 顺序消息 + 延迟消息组合,是金融场景的最佳选择。

// 金融交易:RocketMQ 事务消息 + 顺序消息
// 1. 转账操作:事务消息保证 DB 和 MQ 一致
TransactionMQProducer producer = new TransactionMQProducer("transfer-group");
producer.setTransactionListener(new TransactionListener() {
@Override
public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
// 扣减余额 + 记录流水(本地事务)
accountService.transfer(transferRequest);
return LocalTransactionState.COMMIT_MESSAGE;
}
@Override
public LocalTransactionState checkLocalTransaction(MessageExt msg) {
TransferRecord record = transferService.getById(parseId(msg));
return record != null ? COMMIT_MESSAGE : ROLLBACK_MESSAGE;
}
});
// 2. 顺序消息:同一账户的操作必须有序
Message msg = new Message("transfer-events", tag, transferJson.getBytes());
// 使用 accountId 作为 Key,保证同一账户的事件在同一个队列
msg.setKeys(accountId);
SendResult result = producer.send(msg, new MessageQueueSelector() {
@Override
public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
int index = Math.abs(accountId.hashCode()) % mqs.size();
return mqs.get(index);
}
}, accountId);

日志收集场景

日志收集的核心需求是高吞吐 + 多消费者。Kafka 的分区日志模型天然适合——多个消费者组可以独立消费同一份数据,互不影响。

# Kafka 日志收集:Filebeat → Kafka → Logstash → Elasticsearch
# Filebeat 配置
filebeat.inputs:
- type: log
paths: ["/var/log/app/*.log"]
fields:
app: order-service
env: production
output.kafka:
hosts: ["kafka:9092"]
topic: "app-logs"
partition.round_robin:
reachable_only: true
required_acks: 1
compression: gzip
max_message_bytes: 1000000

IoT 数据接入场景

IoT 设备数量多、数据量波动大、协议多样。Pulsar 的多协议支持(MQTT、Kafka 协议)和分层存储(热数据在 BookKeeper,冷数据在 S3)是关键优势。

# Pulsar IoT 接入:MQTT 协议 + 分层存储
# Pulsar MQTT 协议适配器
mqtt:
enabled: true
port: 1883
maxConnections: 100000
# 分层存储策略:热数据 7 天,冷数据转 S3
policies:
retention:
retentionTimeInMinutes: 10080 # 7 天热数据
retentionSizeInMB: -1
offload:
offloadThresholdInSeconds: 604800 # 7 天后转冷
offloadPolicies:
managedLedgerOffloadDriver: s3
s3Region: us-east-1
s3Bucket: pulsar-offload

微服务通信场景

微服务之间需要灵活的消息路由——不同服务订阅不同的事件子集。RabbitMQ 的 Exchange + Binding 模型让路由规则可以精细控制。

// 微服务通信:RabbitMQ Topic Exchange 精细路由
// 订单服务发布事件
channel.basicPublish("order-events", "order.created", null, event1);
channel.basicPublish("order-events", "order.cancelled", null, event2);
channel.basicPublish("order-events", "order.shipped", null, event3);
// 支付服务只订阅创建事件
channel.queueBind("payment-queue", "order-events", "order.created");
// 通知服务订阅所有事件
channel.queueBind("notify-queue", "order-events", "order.#");
// 物流服务只订阅发货事件
channel.queueBind("shipping-queue", "order-events", "order.shipped");

实时分析场景

实时分析需要流处理能力——Kafka Streams 内置在 Kafka 生态中,无需额外部署流处理引擎。

// 实时分析:Kafka Streams 窗口聚合
StreamsBuilder builder = new StreamsBuilder();
KStream<String, OrderEvent> orders = builder.stream("order-events");
// 按客户分组,5 分钟窗口统计
KTable<Windowed<String>, OrderStats> stats = orders
.groupBy((key, event) -> event.getCustomerId())
.windowedBy(TimeWindows.of(Duration.ofMinutes(5)))
.aggregate(
OrderStats::new,
(customerId, event, aggregate) -> aggregate.add(event),
Materialized.with(Serdes.String(), new JsonSerde<>(OrderStats.class))
);
// 输出到统计 Topic
stats.toStream()
.map((key, value) -> new KeyValue<>(key.key(), value))
.to("order-stats");

3.4 反模式:选型陷阱#

陷阱说明后果
追新选择最新最酷的系统生态不成熟,踩坑多
过度设计简单场景用复杂系统运维成本远超收益
单一系统所有场景用一个系统无法满足所有需求
忽略运维只看功能不看运维上线后运维困难
忽略团队不考虑团队技术栈学习成本高
CV 驱动大厂用什么我们就用什么大厂的规模和你的规模不一样
功能堆砌选功能最多的系统用不到的功能增加运维负担
Note

选型的第一原则是”够用就好”——不要为了可能永远不会出现的需求选择复杂的系统。如果当前场景只需要简单的任务分发,RabbitMQ 就够了;如果未来需要高吞吐日志流,再引入 Kafka 也不迟。很多生产系统是多个消息系统并存的。

反模式案例:用 Kafka 做任务分发

某团队听说 Kafka 性能最强,就用 Kafka 做所有消息场景。结果发现任务分发场景需要灵活路由——不同任务类型分给不同处理队列,Kafka 没有原生路由能力,只能创建大量 Topic 或在消费端做过滤。最终不得不引入 RabbitMQ 做任务分发,Kafka 只保留日志流场景。

反模式案例:用 RabbitMQ 做日志收集

另一个团队用 RabbitMQ 做日志收集,结果日志量上来后 RabbitMQ 吞吐跟不上,消息消费后就被删除无法回放,多团队想消费同一份日志还得创建多个 Queue 做广播。最终迁移到 Kafka,RabbitMQ 只保留业务消息场景。

四、混合架构#

4.1 多系统并存#

在实际生产中,多个消息系统并存是常态:

graph TB subgraph "日志流" APP["应用日志"] --> KAFKA["Kafka"] KAFKA --> ES["Elasticsearch"] KAFKA --> HDFS["HDFS"] end subgraph "业务消息" ORDER["订单服务"] --> RABBIT["RabbitMQ"] RABBIT --> PAY["支付服务"] RABBIT --> NOTIFY["通知服务"] end subgraph "事务消息" TRADE["交易服务"] --> ROCKET["RocketMQ"] ROCKET --> SETTLE["结算服务"] ROCKET --> RISK["风控服务"] end

4.2 系统间桥接#

// Kafka → RabbitMQ 桥接
@KafkaListener(topics = "order-events")
public void onOrderEvent(ConsumerRecord<String, String> record) {
// 将 Kafka 事件转发到 RabbitMQ
rabbitTemplate.convertAndSend("order-exchange", "order.new", record.value());
}
// RabbitMQ → Kafka 桥接
@RabbitListener(queues = "analytics-queue")
public void onAnalyticsMessage(Message message) {
// 将 RabbitMQ 消息转发到 Kafka
kafkaTemplate.send("analytics-topic", new String(message.getBody()));
}
桥接方式说明延迟可靠性
应用层桥接代码中转发中(需处理失败)
Kafka ConnectSource/Sink Connector
RabbitMQ Shovel内置插件
Pulsar IO内置 Connector

4.3 桥接的一致性保证#

系统间桥接时,需要保证消息不丢不重:

// 可靠桥接:使用本地消息表保证一致性
@Transactional
public void bridgeToRabbitMQ(ConsumerRecord<String, String> record) {
// 1. 检查是否已桥接(幂等)
if (bridgeLogRepository.exists(record.topic(), record.offset())) {
return; // 已桥接,跳过
}
// 2. 转发到 RabbitMQ
rabbitTemplate.convertAndSend("order-exchange", "order.new", record.value());
// 3. 记录桥接日志
bridgeLogRepository.save(new BridgeLog(record.topic(), record.offset()));
}

4.4 桥接的监控与告警#

监控指标说明告警条件
桥接延迟源系统到目标系统的延迟> 5s
桥接错误率转发失败的比例> 0.1%
桥接吞吐每秒转发的消息数突然下降
消息丢失率源系统有但目标系统没有> 0
# 监控桥接状态
# Kafka Connect 状态
curl http://localhost:8083/connectors/rabbitmq-sink/status
# RabbitMQ Shovel 状态
rabbitmqctl list_shovels

五、迁移策略#

5.1 从 RabbitMQ 迁移到 Kafka#

阶段步骤风险
1. 评估分析当前 Exchange/Queue 拓扑
2. 映射Exchange → Topic,Queue → Consumer Group
3. 双写同时写入 RabbitMQ 和 Kafka
4. 切换消费消费者从 Kafka 消费
5. 停写旧系统停止写入 RabbitMQ
6. 下线旧系统移除 RabbitMQ
graph LR subgraph "阶段 1:双写" P1["Producer"] --> RMQ1["RabbitMQ"] P1 --> KAFKA1["Kafka"] RMQ1 --> C1["Consumer<br/>(从 RabbitMQ)"] end subgraph "阶段 2:切换消费" P2["Producer"] --> RMQ2["RabbitMQ"] P2 --> KAFKA2["Kafka"] KAFKA2 --> C2["Consumer<br/>(从 Kafka)"] end subgraph "阶段 3:下线旧系统" P3["Producer"] --> KAFKA3["Kafka"] KAFKA3 --> C3["Consumer<br/>(从 Kafka)"] end

5.2 迁移注意事项#

注意事项说明
消费语义RabbitMQ 推模式 → Kafka 拉模式,消费逻辑需调整
路由映射Exchange 的复杂路由需要用多个 Topic 替代
消息确认RabbitMQ ACK → Kafka Commit,语义不同
有序性RabbitMQ 队列有序 → Kafka 分区有序,Key 设计需调整
延迟消息Kafka 无原生延迟消息,需自行实现
死信处理RabbitMQ 原生死信 → Kafka 手动 DLQ Topic
Warning

消息系统迁移是高风险操作——务必采用双写+逐步切换的策略,确保在任何时刻都可以回滚。千万不要”大爆炸”式切换——一旦出问题,无法快速回退。

5.3 迁移实战案例#

案例:某电商从 RabbitMQ 迁移到 Kafka

背景:订单量增长 10 倍,RabbitMQ 吞吐成为瓶颈。需要将日志类消息迁移到 Kafka,业务消息保留在 RabbitMQ。

// 迁移第一步:双写适配器
@Service
public class DualWriteMessageService {
private final RabbitTemplate rabbitTemplate;
private final KafkaTemplate<String, String> kafkaTemplate;
private final FeatureFlagService featureFlag;
public void sendOrderEvent(String routingKey, String payload) {
// 始终写入 RabbitMQ(旧系统)
rabbitTemplate.convertAndSend("order-exchange", routingKey, payload);
// 特性开关控制是否写入 Kafka
if (featureFlag.isEnabled("kafka-dual-write")) {
try {
kafkaTemplate.send("order-events", routingKey, payload).get(5, TimeUnit.SECONDS);
} catch (Exception e) {
// 双写阶段 Kafka 写入失败不影响主流程
log.warn("Kafka dual-write failed", e);
metricsService.increment("kafka.dual-write.failure");
}
}
}
}
// 迁移第二步:对比验证
@Scheduled(fixedRate = 60000)
public void verifyDualWriteConsistency() {
// 抽样对比 RabbitMQ 和 Kafka 的消息
long rabbitCount = rabbitAdmin.getQueueMessageCount("order-queue");
long kafkaLag = kafkaAdmin.getConsumerGroupLag("order-consumer-group");
metricsService.gauge("migration.consistency.gap", Math.abs(rabbitCount - kafkaLag));
}

迁移耗时 3 个月,分 6 个阶段逐步切换,期间未发生任何线上事故。关键经验:双写阶段必须做数据对比,确保两个系统的消息一致。

六、成本对比#

6.1 总体拥有成本#

成本维度KafkaRabbitMQRocketMQPulsar
硬件成本高(存储密集)高(存储+计算分离)
运维人力
学习成本
商业版许可Confluent(贵)VMware(中)阿里云(中)StreamNative(中)
社区支持丰富丰富中文为主成长中

6.2 规模与成本的关系#

规模推荐月成本估算
小型(< 1万 TPS)RabbitMQ1-3 台服务器
中型(1-10万 TPS)Kafka / RocketMQ5-15 台服务器
大型(> 10万 TPS)Kafka15-50 台服务器
超大规模(多区域)Pulsar50+ 台服务器

6.3 云服务成本对比#

云服务对应系统按量计费预留实例适用场景
AWS MSKKafka$0.024/GB-hour1 年/3 年日志流 + 事件驱动
AWS MQRabbitMQ$0.036/hour/instance1 年/3 年业务消息
阿里云 RocketMQRocketMQ¥0.40/百万消息包年包月电商/金融
AWS KinesisKinesis(类 Kafka)$0.015/hour/shard1 年/3 年日志/流处理
GCP Pub/SubPub/Sub$40/TB通用消息
Tip

云服务可以显著降低运维成本,但要注意出口流量费用。Kafka 的高吞吐意味着大量的网络流量,跨区域流量费用可能超过实例费用本身。

6.4 实际案例:电商平台的选型决策#

以一个中型电商平台为例,分析不同业务场景的消息系统选择:

业务场景需求分析选型决策
用户行为日志高吞吐(10万+ TPS)、多消费者、日志保留Kafka
订单创建→支付事务消息、顺序消息、高可靠RocketMQ
订单状态通知灵活路由(不同渠道)、低延迟RabbitMQ
库存同步跨服务一致性、消息不丢RocketMQ 事务消息
搜索索引更新异步更新、允许延迟Kafka
营销活动通知广播通知、一次性消费RabbitMQ Fanout
graph TB subgraph "电商平台消息架构" LOG["用户日志<br/>Kafka"] --> ANALYTICS["数据分析"] LOG --> SEARCH["搜索索引"] ORDER["订单服务<br/>RocketMQ"] --> PAYMENT["支付服务"] ORDER --> INVENTORY["库存服务"] NOTIFY["通知服务<br/>RabbitMQ"] --> EMAIL["邮件"] NOTIFY --> SMS["短信"] NOTIFY --> PUSH["App推送"] end

这个案例展示了”多系统并存”的合理性——不同场景有不同的最优选择,强行统一到一个系统会牺牲某些场景的性能或功能。

6.5 选型评估矩阵#

当你面对选型决策时,可以用以下评分矩阵量化评估:

评估维度权重KafkaRabbitMQRocketMQPulsar
性能匹配30%9677
功能匹配25%7898
运维成本20%6865
团队匹配15%????
生态成熟10%9856
Tip

消息队列选型的黄金法则:1)从业务场景出发,不要从技术偏好出发;2)先选”够用”的,不要选”最强”的;3)考虑团队的技术栈和运维能力;4)多系统并存是正常的,不要强求统一;5)预留迁移路径,不要把自己锁死在一个系统上。

七、总结#

上一章探讨了Schema 演化与兼容性。

维度关键要点
Kafka高吞吐日志流首选,生态最成熟
RabbitMQ灵活路由+低延迟,业务消息首选
RocketMQ事务+延迟+顺序,电商金融首选
Pulsar云原生+多租户,SaaS 平台首选
选型原则够用就好、考虑运维、团队匹配
混合架构多系统并存是常态,通过桥接互连
迁移策略双写+逐步切换,确保可回滚
成本考量硬件+运维+学习+许可,综合评估

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

消息队列选型
https://blog.souloss.com/posts/messaging/message-queue-selection/
作者
Souloss
发布于
2026-05-08
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时