消息队列选型：Kafka vs Pulsar vs RocketMQ

可视化演示

展示三大消息队列架构差异（Kafka一体/Pulsar分离/RocketMQ事务）、消息投递语义(≤1/≥1/=1)与吞吐/延迟/事务/扩容/生态五维对比，帮助理解MQ选型决策。

消息队列基础

想象你开了一家网店。大促瞬间涌入几千个订单，如果每一单都让客服立刻打电话、仓库立刻发货、财务立刻对账，系统瞬间就会卡死。聪明的做法是设一个「订单中转站」：下单请求先扔进去，后端各个部门按自己的节奏取走处理。这个中转站，就是消息队列的核心思想——它从不在“谁送”和“谁收”之间强加同步，而是让两边各自为政、异步协作。

对应到技术世界，角色非常清晰：寄件人叫 Producer（生产者），收件人叫 Consumer（消费者），一条专线叫 Topic，中转站里的分拣中心叫 Broker。Producer 只管往 Topic 丢消息，Consumer 按需拉取，二者互不相识。这带来两个杀手级能力：异步解耦——上游不再关心下游是否在线、处理多慢；削峰填谷——流量洪峰先灌进队列，下游按最大处理能力慢慢消化，系统再也不会被瞬时流量冲垮。

但中转站不是无限的，它本质是一个排队系统。排队论里有一条著名定律——利特尔定律（Little's Law）：中转站里积压的订单数，等于每秒到达的订单数乘以每个订单平均停留的时间。这条公式，是后面理解三个产品吞吐差异的底层工具。

现在你理解了中转站的价值。但同样是中转站，Kafka、Pulsar、RocketMQ 三家公司的建造方案截然不同：一家铺超长传送带，一家建现代化物流园区，一家做同城保价急送。接下来，我们逐一参观。

Kafka架构剖析

先参观 Kafka。它的仓库是一条超长的自动传送带：所有包裹一到，就按到达顺序一个接一个平铺在传送带上，只能往后追加，绝不允许插队或修改。任何想看包裹的人，只能沿着传送带从头走到尾，按编号（offset）找到自己想要的货。这就是 Kafka 的存储模型——分布式提交日志（distributed commit log）。

传送带太长，一条不够用怎么办？Kafka 把一个 Topic 专线切成多个 Partition（分区），相当于并排铺开多条子传送带。为了防丢失，每条分区的数据会复制 N 份到不同节点（副本）。多分区带来并行度，副本带来可靠性，这是 Kafka 吞吐与容错的两大支柱。

那 Kafka 为什么快？两个秘密：顺序写盘和页缓存。机械硬盘顺序写可达每秒几百 MB，随机写却慢两三个数量级；Kafka 只追加不修改，恰好把磁盘最擅长的顺序写发挥到极致。同时，消息先写操作系统页缓存（page cache），由内核异步刷盘，免去每写一条都等待落盘的延迟。为了保证“副本跟上主节点”，Kafka 维护一个 ISR（In-Sync Replicas）同步副本集合，只有集合内的副本才参与“已确认”判定。

Kafka 把“快”做到了极致，但也有代价：想给传送带换布局很难——加机器要搬数据；想让多个公司共用一条传送带，也缺乏隔离机制。速度之王的短板，正好是下一家 Pulsar 的强项。

Pulsar架构剖析

Pulsar 建的是一座现代化物流园区，它与 Kafka 最大的不同可以浓缩成一句话：计算与存储分离。园区里有两类角色：分拣台 Broker 只负责收发包裹、维护会话状态，本身不存任何货；包裹真正存放的地点是共享总仓 BookKeeper，由一批 Bookie 存储节点组成。分拣台坏了，换一台新的立刻上岗，因为货都在总仓里——这就是“Broker 无状态”。

总仓怎么存？Pulsar 把数据切成一个个小段（Segment）分散存到多个 Bookie 上，每段有若干副本。这带来两个好处：分层存储——老数据可以自动滚动到廉价存储，想存多久存多久；扩容像呼吸一样自然——加 Broker 不用搬任何数据，加 Bookie 只是给总仓多几排货架。对比 Kafka 扩容时要把百万级分区搬来搬去，Pulsar 的体验堪称丝滑。

园区由物业统一管理，不同公司可以同时入驻而互不干扰：Pulsar 用 namespace（命名空间）做多租户隔离，每个租户有自己的配额、权限和流量策略。一个租户流量暴涨，最多挤占其所在资源，不会拖垮整座园区。对云厂商和 SaaS 平台来说，这是 Kafka 很难给出的承诺。

园区模式让 Pulsar 在弹性、多租户、长时存储上完胜，但每件货要“分拣台→总仓”两跳，多一次网络往返，裸延迟和吞吐未必比 Kafka 那条直通传送带强。接下来这家，专治“怕乱、怕丢”的场景。

RocketMQ架构剖析

RocketMQ 像同城保价急送专线，不追求传送带极速，但把两件事做到极致：严格先来后到，和“货到付款”式的事务保障。为什么需要严格先来后到？银行的转账、电商的下单，消息顺序错了，业务就乱了。RocketMQ 把消息放进有序队列，提供全局顺序和分区顺序两种模式，在金融交易圈口碑极佳。

再看“货到付款”，这是 RocketMQ 的招牌——事务消息。想象你在同城急送下了一单：骑手先取走一个“半包裹”（half message），此时这笔交易处于待定状态，消费者不可见；你确认付款后，系统才把半包裹升级为正式包裹发出。如果中途取消（本地事务回滚），半包裹直接作废。RocketMQ 通过这个两阶段机制，把“发消息”和“本地数据库操作”绑定成同一个事务，杜绝了“订单已付但物流没收到”的惨案。

其他细节同样扎实：主从同步保证高可用；消息带 Tag 支持在 Broker 端过滤，减少无效网络传输；消费失败可按时延不断重投，多次失败最终进入死信队列等人处理。架构上比 Kafka 多了轻量的 NameServer 做路由，运维组件更简单。

保价急送服务周全，但车队规模和速度终究有限：RocketMQ 的吞吐和水平扩展能力不如 Kafka，多租户隔离不如 Pulsar。三家风格已清晰，下一节我们把它们的“承诺”摆到桌面上对比。

消息语义对比

快递公司给用户的承诺分等级：Kafka 和 Pulsar 默认是“尽全力投递，可能多送一次”；RocketMQ 事务消息则基本做到“要么确认，要么退货”。这些承诺在消息领域有个名字：投递语义（delivery semantics），分为最多一次、至少一次、恰好一次。传统 MQ 多为“至少一次（at-least-once）”：消息可能重复投递，但绝不丢失，消费者必须自己做到幂等——同一消息处理多次，结果与处理一次相同。

顺序保证是第二个对比维度。Kafka 只在分区内有序，全局分散到多个分区就是乱序；RocketMQ 通过单一队列可做到全局有序，代价是牺牲并行度；Pulsar 的策略与 Kafka 类似，分区内有序。第三个维度是事务能力：RocketMQ 原生事务消息解决“跨系统原子性”；Kafka 的事务（Exactly-once）面向流处理中的原子写，两者不是一回事；Pulsar 的事务支持仍在追赶。

最后是失败处理：三者都会自动重试，多次失败后进入死信队列（DLQ），由人工或旁路任务补偿。别小看语义差异——金融场景里一条消息重复扣款是事故，日志场景里重复一条日志则无伤大雅。这正是选型最容易被忽视、却最影响业务正确性的维度。

承诺等级决定了业务要不要做幂等、要不要写补偿。选快递之前先想清楚：你的业务是丢不起，还是重不得？这个答案，直接指向不同的产品。

性能生态对比

参观完三家仓库，我们再比比车队规模和增值服务。先说吞吐与延迟的体感：单机裸吞吐上，Kafka 凭借顺序写和页缓存通常是第一梯队，尤其适合“写多读少”的日志洪流；RocketMQ 延迟控制出色，适合在线交易链路；Pulsar 因为多了一次存储写入，吞吐下限取决于存储集群，但胜在稳定可预期。

扩容是另一个分水岭。Kafka 加 Broker 时，要把既有分区的数据搬过去（重平衡），数据越多搬得越久，期间消费时延可能抖动；Pulsar 加 Broker 只需告诉园区“新分拣台来了”，数据分毫不动，扩容按秒计算；RocketMQ 的扩容同样需要迁移，但整体设计更轻量，运维门槛低。

多协议与生态方面：Pulsar 原生支持 Kafka 协议、MQTT、AMQP，客户端几乎零改造迁移；Kafka 的杀手锏是生态——Kafka Connect 做数据集成、Schema Registry 管格式、KSQL 做流式查询，加上 Flink/Spark 全家桶的深度适配，流式处理事实标准的地位难以撼动；RocketMQ 生态在国内阿里系技术栈中非常成熟，配套监控告警完善，社区中文资料丰富。

没有一辆车能同时做到最快、最稳、服务最全。性能与生态的取舍，最终要落到业务需求上打分——这就是最后一节要做的事。

选型决策指南

选快递公司，先看你的货是什么。货是海量日志、埋点、指标？Kafka 当仁不让——日志就是纯追加的流，天生匹配 Kafka 的顺序写和重放能力，加上 Flink 生态的深度绑定，实时数据管道的不二之选。这也是 Kafka 吞吐之王的用武之地。

货是订单、转账、库存这类强一致交易？RocketMQ 的事务消息和顺序消息直击痛点，“先半消息、确认后提交”帮你免去手工补偿的深渊。货是“我要给几十个客户开隔离的消息空间”？比如 SaaS 平台、云厂商，Pulsar 的多租户与计算存储分离，让你不必为每个客户单独搭集群，运维成本断崖式下降。

最后还有两个现实因素：成本和团队。小集群、业务简单、团队只熟 Kafka，强行上 Pulsar 的分布式存储反而增加运维负担；反之，规模巨大且多团队共用时，Kafka 的“一人一集群”模式会变成资源黑洞。理性的做法，是把吞吐、事务、多租户、生态、运维五个维度列成评分表，按场景加权求和，让数据替你做决定。

大到国家级快递网络，小到同城跑腿，各有各的适用半径。选型没有最好，只有最匹配——带上这张评分表，你就能从容回答“到底该用哪一个”。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""Queue semantics simulator: replay Kafka/Pulsar/RocketMQ delivery behaviors"""import random  class Queue:    def __init__(self, name, dup_rate, ordered, tx_mode=False):        self.name = name        self.dup_rate = dup_rate        self.ordered = ordered        self.tx_mode = tx_mode        self.sent_list = []        self.received_list = []        self.rollback_count = 0     def send(self, msg_id):        # RocketMQ: a prepared (half) message may be rolled back        if self.tx_mode and random.random() < 0.02:            self.rollback_count += 1            return        self.sent_list.append(msg_id)     def consume(self):        # Kafka/Pulsar keep order inside a partition but lose global order        seq = list(range(len(self.sent_list)))        if not self.ordered:            random.shuffle(seq)        for idx in seq:            msg_id = self.sent_list[idx]            # at-least-once: the same message may be delivered twice            if random.random() < self.dup_rate:                self.received_list.append((msg_id, 2))            self.received_list.append((msg_id, 1))     def run(self, n):        for i in range(n):            self.send(i)        self.consume()        seen = set(m for m, _ in self.received_list)        dup = len(self.received_list) - len(seen)        lost = n - len(seen)        got = [m for m, _ in self.received_list]        ok_order = got == sorted(got)        print("[%s] delivered=%d dup=%d lost=%d ordered=%s" %              (self.name, len(self.received_list), dup, lost, ok_order))  def main():    random.seed(42)    n = 1000    queues = [        Queue("Kafka", 0.03, False),        Queue("Pulsar", 0.03, False),        Queue("RocketMQ", 0.03, True, True),    ]    for q in queues:        q.run(n)    print("RocketMQ half-message rollbacks:", queues[2].rollback_count)  if __name__ == "__main__":    main()

1. class Queue:用参数化类抽象队列语义：重复率、是否全局有序、是否启用事务两阶段。
2. if self.tx_mode and random.random() < 0.02:模拟 RocketMQ 半消息被回滚：确认之前断了，这笔交易就作废。
3. seq = list(range(len(self.sent_list)))构造消费顺序索引，模拟 Broker 决定消息的分发顺序。
4. if not self.ordered:Kafka/Pulsar 多分区并发消费导致全局乱序，RocketMQ 单队列保持严格先来后到。
5. self.received_list.append((msg_id, 2))at-least-once 语义下，同一条消息可能被重复投递，副本标记为 2。
6. seen = set(m for m, _ in self.received_list)幂等去重：消费者拿到重复消息后也只处理一次。
7. ok_order = got == sorted(got)校验消费顺序是否被打破，输出 True 或 False。
8. random.seed(42)固定随机种子，让多次运行的对比结果可复现。

常见误区

面试题