Kafka与RocketMQ读写模型、零拷贝及调优实战对比

聊消息中间件绕不开的话题就那几样：吞吐、可靠性、顺序、延迟。但真正能在面试和线上问题排查里拉开差距的，是把读写模型和底层存储机制吃透。这两年我一直在Kafka和RocketMQ之间来回切换，看过不少人两套都部署过，真要问一句“为什么Kafka消费那么快”“为什么RocketMQ写消息能这么稳”，很多人是说不清楚的。这篇文章我就把Kafka和RocketMQ的读写模型、存储结构、零拷贝实现放在一起做个彻底对比，同时把部署、调优、踩坑经验也一并聊透，希望你看完能直接用到自己的项目和答疑里。

这两套MQ对新手来说最容易犯的错，就是拿着Kafka的使用习惯去套RocketMQ，或者反过来。只要你把两者在设计层面的取舍搞明白，后面配参数、定位性能瓶颈、回答面试题都会轻松很多。整篇文章会从架构差异讲起，然后拆读写路径，再重点聊零拷贝，最后给实际部署调优和常见问题速查，干货量不小，慢慢看。

1. 核心定位与架构差异：为什么两个系统长得完全不一样

1.1 设计哲学决定技术路线

先看两个系统的出身。Kafka是LinkedIn为了解决日志采集和传输搞出来的，核心诉求就一个字：快。大量日志数据要低延迟、高吞吐地流过去，所以Kafka从骨子里就是为一个“日志系统”设计的——数据只追加、不修改、纯顺序读写、消费完成后不删除数据、靠保留时间或大小过期。这种设计让Kafka在吞吐上几乎没对手，但也导致它在消息删除、死信处理、延迟消息这类“业务级能力”上比较薄弱。

RocketMQ是阿里在电商业务场景里摸爬滚打出来的，消息要支撑订单、交易、库存这些核心链路，所以它不只是“快”，更重要的是“可靠”和“好用”。电商场景里消息不能丢，而且配套的死信队列、定时消息、事务消息、消息重试这些能力，都是业务侧硬需求。这些功能Kafka很多要么没有、要么很别扭。两句话概括：Kafka是数据管道，RocketMQ是业务消息总线。这个定位差异，直接决定了两者在存储结构、读写模型、代码实现上的分道扬镳。

从技术栈上说，Kafka用Scala和Java写的，RocketMQ是纯Java。但这并不是两者区别的决定因素，真正的分水岭在于存储层的组织方式，这个我们下面细说。

1.2 存储层的根基：分区文件与双层队列

Kafka存储的核心是分区。一个主题可以拆成多个分区，每个分区在磁盘上就是一个目录，目录里是一串segment日志段文件。消息按offset顺序追加到当前活跃的segment文件里，所有读写都是顺序的。为了快速定位offset，每个segment配了一个稀疏索引文件，索引里不存每一条消息，而是每隔若干字节存一条，消费时先查索引再二分定位。你可以把Kafka的分区想象成一条无限长的纸带，只往末端写，读的时候从中间某个位置顺着往后读。

RocketMQ的存储结构则是双层的：所有主题的消息统统先写进同一个CommitLog，这是全局唯一的一份物理文件，任何主题、任何队列的消息都顺序追加到这个文件里。然后通过一个异步分发机制，生成每个队列对应的ConsumeQueue逻辑队列，ConsumeQueue里只存消息在CommitLog中的物理偏移量、消息长度、tag哈希这20个字节的条目。实际消费时，消费者拿到的是ConsumeQueue里的“指针”，然后去CommitLog里读真正的消息内容。

这个差别看起来很底层，但影响深远。Kafka的分区越多，磁盘上文件越多，顺序写就容易被削弱；RocketMQ所有写入都集中在CommitLog，天然保持顺序写，所以它敢支撑大量队列而写入性能不崩。代价是RocketMQ读消息时会多一次“查索引再读数据”的间接跳转，Kafka由于消费者自己管理offset，定位直接，读路径更短。正是这两种存储模型，构成了后面读写模型差异的物理基础。

2. 读写模型拆解：生产者怎么写，消费者怎么读

2.1 生产端：先攒一波再写，还是攒一点就写

Kafka生产端有一个内存缓冲区（RecordAccumulator），生产者发送的消息不会一条条发，而是先攒在缓冲区里，攒够一批（batch.size）或者到了等待时间（linger.ms）才一次性发给broker。broker收到这批消息后，顺序追加到当前分区的segment文件，同时依赖操作系统的PageCache缓存，写入性能极高。这种批量攒批的设计，是Kafka吞吐能打的重要原因之一——一次请求处理上万条消息，和一次请求处理一条消息，两者性能差了好几个数量级。

写不写磁盘还要看ack配置：acks=0发出去不管，acks=1写到leader分区的PageCache就返回，acks=-1（all）要等所有ISR副本都写入才返回。很多生产事故都是因为把acks设成1，以为消息已经落盘，实际上消息还在PageCache里，机器一断电数据就没了。这一点我在后面踩坑部分会再强调。

RocketMQ生产端不走“攒批再发”的大批量语义，它的高性能主要靠存储层的顺序写。生产者把消息发到broker后，broker把消息写入CommitLog，这个过程是纯顺序追加，配合mmap内存映射，速度非常快。RocketMQ默认采用异步刷盘机制，写入PageCache就直接返回，后台线程定时把缓存里的数据刷到物理磁盘。如果你开同步刷盘，每条消息都要fsync到磁盘才返回，可靠性极高但性能大幅下降，一般只在金融级链路才开同步刷盘。

这里有个生产端的本质区别：Kafka把“攒批”放在客户端，通过batch.size和linger.ms两个参数控制攒批策略，能攒出非常大的请求；RocketMQ更依赖broker端的顺序写能力，单条消息写入路径短、延迟低，批量能力体现在阻塞队列和消费端批量消费上。所以在极高吞吐的日志接入场景Kafka更占优，而在大量小消息、单条延迟敏感的业务场景里，RocketMQ的延迟表现往往更稳定。

2.2 消费端：消费者自己拉，还是broker推给你

Kafka的消费模型是彻底的拉模式（pull）：消费者主动去broker拉取消息，拉到多少算多少，拉完了再拉下一批。每个消费者属于一个消费者组，分区会分配组里的各个消费者，一个分区同时只能被组内一个消费者消费，这是Kafka保证分区内消息顺序消费的基础。消费者消费完会提交offset，offset记录自己在分区里的消费位置，下次重启接着从这个位置读。

这里要注意，Kafka的offset提交是一个很常见的坑点：自动提交（enable.auto.commit=true）默认每隔5秒提交一次，如果消费者在提交前崩了，重启后就会重复消费一部分消息。很多团队后来都改成手动提交，在业务处理成功后再提交offset，用“至少一次”语义换取不丢消息。

RocketMQ的消费模型对外号称是推模式（push），实际底层是长轮询（long polling）：消费者发请求问broker有没有新消息，broker没消息就hold住这个请求，等一段时间或者有新消息到了再返回。这让消费端用起来像“有消息就推给你”，代码感知上是推送，底层还是拉，但省去了消费者频繁空轮询的浪费。RocketMQ消费的时候还要考虑消费组在一个队列上的消费位点（消费进度）管理，消费成功后要更新本地或broker上的offset，失败的消息会进入重试队列，重试到一定次数进入死信队列。

从使用体验上，RocketMQ的push模型对业务代码更友好——你只需要写一个回调处理消息，框架帮你拉取和投递。Kafka则需要消费线程自己控制拉取频率、offset提交时机，灵活但更容易踩坑。两者本质都是在解决“消费者如何协同、如何记账”的问题，只是Kafka把控制权交给客户端，RocketMQ把默认体验做到了broker侧。

2.3 副本机制对读写路径的影响

Kafka的高可用靠副本机制：每个分区有多个副本，副本之间通过ISR（In-Sync Replica，同步中副本集合）维护一致性。生产者只写leader副本，消费者也只从leader副本读，follower副本只负责同步数据。如果leader挂了，从ISR里重新选一个leader出来，继续对外服务。这个设计简单高效，但写入路径上有一个细节：即使acks=all，也要等ISR里所有副本确认才能返回，这会影响生产端的写入延迟，尤其在跨机房的副本同步场景里特别明显。

RocketMQ在主从模式下，生产者写master节点，消费者既可以从master读也可以从slave读，这跟Kafka“只从leader读”不一样。RocketMQ的主从复制分同步复制和异步复制：同步复制是master写入成功并同步给slave成功后返回，异步复制则是master写完就返回，slave在后台努力追上。同步复制可靠性高但写入延迟增加，异步复制性能好但在master宕机时可能丢一小段数据。RocketMQ在4.5版本后引入了基于Raft的Dledger模式，可以自动选主，解决了主从自动切换的问题，但很多存量集群还是经典主从架构。

从运维角度说，Kafka的ISR和leader选举相对成熟，故障自愈能力强；RocketMQ经典模式下主从切换依赖人工或第三方组件，Dledger模式提供了自动能力但部署复杂度高一些。这些副本机制的取舍，也会直接影响你在生产环境里看到的写入路径行为。

3. 零拷贝：两个MQ快起来的核心秘密，到底谁更彻底

3.1 先理解一次网络传输要拷贝几次

聊零拷贝之前，先看最传统的文件发送路径。比如一个服务要把磁盘上的文件发给客户端，传统做法是：调用read把文件从磁盘读到内核缓冲区（DMA拷贝），再从内核缓冲区拷到用户空间缓冲区（CPU拷贝），然后调用write把用户空间缓冲区的数据拷到socket发送缓冲区（又是CPU拷贝），最后网卡从socket缓冲区把数据发出去（DMA拷贝）。整个过程下来，数据被拷贝了4次，而且经历了4次用户态和内核态的上下文切换。在消息中间件这种高频IO场景里，这种开销是致命的。

零拷贝不是“一次拷贝都没有”，而是通过减少用户态和内核态之间的数据搬运来降低开销。最常用的两种机制：mmap和sendfile。mmap把文件映射到进程地址空间，用户态可以直接读写这段映射内存，省去了传统read时“内核缓冲区→用户缓冲区”的这次CPU拷贝，但写入socket时仍然有一次CPU拷贝从映射区域到socket缓冲区。sendfile则是彻底绕过用户空间，直接在内核态把文件数据从磁盘映射到socket发送缓冲区，配合DMA scatter/gather特性，甚至可以做到“没有CPU参与的数据搬运”。

最直观的类比：传统IO像你从库房拿货到柜台（用户空间），再把货搬上快递车（socket）；mmap是库房和柜台打通了一个窗口，你直接在窗口把货递上车；sendfile则是库房和快递车直连的传送带，你根本不需要出现在现场。数据搬运的每一环节省下来，对高吞吐的MQ消费链路都是实打实的性能提升。

3.2 Kafka的零拷贝实践：索引文件mmap + 消费数据sendfile

Kafka是零拷贝技术的典型受益者，它把零拷贝用在了两个关键地方。

第一个是日志段的索引文件用mmap映射。Kafka的索引文件是很稀疏的偏移量索引，文件小、访问频繁，用mmap映射到用户态内存后，消费者找offset的时候直接在内存里做二分查找，速度快、没有系统调用开销。这个文件不适合用sendfile，因为不是一次性发给客户端，而是broker内部要反复查询的，mmap是最合适的方案。

第二个是消费消息时直接用sendfile。Kafka在把磁盘上的消息数据返回给消费者时，会调用文件通道的transferTo方法，数据直接从磁盘文件传输到网络socket，整个过程不经过用户空间，不需要把消息内容一步步拷贝到JVM堆里。用Kafka消费大量消息时，如果消息体比较大，就能明显感受到这个设计的威力——CPU几乎不参与数据搬运，全部让DMA去干活。

不过Kafka的sendfile路径有个前提：数据必须直接从文件发出去，不能经过业务逻辑的修改。如果消息经过了重新压缩、转换格式、调整字段之类处理，就必须先读进内存处理再发出去，零拷贝就失效了。所以Kafka文档里强调，要保持高吞吐，消费者和生产者最好都别去做太多解码再编码的转换动作。

3.3 RocketMQ的零拷贝实践：CommitLog的mmap与堆外传输

RocketMQ同样大量使用零拷贝，但它和Kafka走了不太一样的路。

RocketMQ写消息的核心是MappedFile，一个MappedFile对应CommitLog里的一个文件，创建的时候用FileChannel.map把文件映射成MappedByteBuffer，之后所有消息写入都直接写到这块映射内存里。由于映射区域就在用户态地址空间，写入时省掉了一次传统IO的内核态到用户态的拷贝。配合异步刷盘线程定期把映射内存刷到磁盘，这就是RocketMQ高吞吐写入的秘密。

消费路径上，RocketMQ先读ConsumeQueue，它本身也是MappedFile映射，读取“指针”开销极低；拿到offset后去CommitLog读真正的消息内容，也是通过MappedByteBuffer直接读取。消息数据从磁盘映射到用户态后，会放入堆外内存或直接通过Netty发送。RocketMQ默认情况下传输用的是堆外内存（DirectByteBuffer），配合Netty的零拷贝机制，减少了堆内堆外的一次拷贝。如果你想更彻底地启用文件通道直达socket，RocketMQ也提供了一个开关，打开后走的是FileRegion，底层就是FileChannel.transferTo，效果类似Kafka。

但注意，RocketMQ默认在“磁盘文件→网络发送”这一段，并不像Kafka那样全局走sendfile，而是走mmap + 堆外内存。原因在于RocketMQ的消息消费经常要做tag过滤、属性过滤，消息内容需要经过用户态逻辑处理后才决定是否投递，强制走sendfile反而会限制功能。所以RocketMQ在业务灵活性和极致性能之间做了平衡：写入和索引读取走mmap保证顺序写性能，网络传输走堆外减少拷贝，同时保留FileRegion开关给极端性能场景。

3.4 零拷贝对比表与容易被神话的误区

这里我想泼一盆冷水：零拷贝不是万能的。很多团队把Kafka性能全部归功于sendfile，其实是误解。在消息体很小（比如几百字节）时，零拷贝带来的收益非常有限，真正的性能瓶颈往往是网络往返次数、锁竞争、消费者处理逻辑和JVM GC。零拷贝要在大消息、高吞吐、持续转发场景里才有明显的收益。

另外一个容易踩的坑是mmap的边界：mmap映射的文件大小是有限制的，超出范围会导致映射失败或需要重新映射；而且mmap的内存是受操作系统虚拟内存管理的，如果映射了超大文件又没按segment切割，很容易把进程内存空间撑爆。所以RocketMQ和Kafka都强制要求segment文件按固定大小切分，Kafka的log.segment.bytes默认1GB，RocketMQ的CommitLog文件默认1GB，一个是防单个文件过大影响IO，另一个也是配合mmap映射边界。理解了这个，你在调参时就不会乱改文件大小。

4. 从部署和调优视角看两个MQ：配置项与落地细节

4.1 容器化快速部署：docker compose 写 Kafka 与 RocketMQ

说实话，现在再从头本地安装Kafka或RocketMQ对大多数人没必要，容器部署是最快的方式。不过要注意，Kafka和RocketMQ对磁盘和内存的要求都不低，容器里跑的话建议至少给4GB以上内存，数据目录用外部卷挂载，别放在容器可写层里，否则容器一重启数据全没。

先看Kafka的docker compose示例，单机开发环境用KRaft模式（不依赖ZooKeeper，Kafka 3.5以后很成熟）：

yaml复制services:
  kafka:
    image: apache/kafka:3.7.0
    container_name: kafka
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "PLAINTEXT://:9092,CONTROLLER://:9093"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT://localhost:9092"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@localhost:9093"
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
    volumes:
      - kafka-data:/var/lib/kafka/data
volumes:
  kafka-data:

再说RocketMQ。RocketMQ官方提供了完善的docker镜像，但默认的apache/rocketmq镜像启动broker前需要配好内存参数，否则容易因为JVM启动参数和容器内存不匹配直接启动失败。最省心的方式是用官方dashboard镜像一并把控制台起了。下面这个compose文件包含nameserver、broker和dashboard：

yaml复制services:
  namesrv:
    image: apache/rocketmq:5.1.0
    container_name: rmqnamesrv
    ports:
      - "9876:9876"
    command: sh mqnamesrv

  broker:
    image: apache/rocketmq:5.1.0
    container_name: rmqbroker
    depends_on:
      - namesrv
    ports:
      - "10911:10911"
      - "10909:10909"
    environment:
      NAMESRV_ADDR: namesrv:9876
    command: sh mqbroker -n namesrv:9876 -c /home/rocketmq/conf/broker.conf
    volumes:
      - ./broker.conf:/home/rocketmq/conf/broker.conf
      - rmq-data:/home/rocketmq/store

  dashboard:
    image: apache/rocketmq-dashboard:1.0.0
    container_name: rmqdashboard
    depends_on:
      - namesrv
    ports:
      - "8080:8080"
    environment:
      JAVA_OPTS: "-Drocketmq.namesrv.addr=namesrv:9876"

volumes:
  rmq-data:

注意broker.conf里要显式配置brokerIP1为宿主机IP或公网IP，否则容器里的broker会向客户端注册容器内IP，客户端根本连不上。这是我的血泪经验，之前搭RocketMQ容器环境几乎每个新手都栽在这上面。

4.2 核心参数对比调优

调优不能只盯着某一个参数，要跟着读写模型走。Kafka生产端几个关键参数都是围绕“攒批”设计的：batch.size决定攒多大，linger.ms决定最多等多长时间，buffer.memory决定攒批内存总多大。如果业务要求低延迟，linger.ms可以设成0或者1ms，但代价是吞吐下降；如果追求吞吐，就调大batch.size和linger.ms。消费端还有一个常被忽略的参数：fetch.min.bytes，它表示一次拉取请求至少要拉回多少字节才返回，调大它可以减少频繁拉取带来的网络开销，但会增加等待时间。

RocketMQ最值得关注的是存储和刷盘相关的参数。broker.conf里的transientStorePoolEnable是个宝藏参数，开启后broker会使用堆外内存池作为写入缓存，消息先写入堆外内存再刷到PageCache和磁盘，能减少GC压力和写入抖动。刷盘策略flushDiskType默认是ASYNC_FLUSH异步刷盘，换成SYNC_FLUSH就是同步刷盘，可靠性高但性能下降明显。RocketMQ消费端的consumeThreadMin和consumeThreadMax控制消费线程数量，如果消费逻辑是纯CPU密集，建议线程数别超过CPU核数；如果是IO密集，可以多开一些。还有pullBatchSize，默认是32条，在有批量处理需求时可以调大。

下面把常见的对应关系整理成一张表：

这些参数不是调一次就完事，要配合监控。Kafka的监控指标看broker的BytesInPerSec、BytesOutPerSec，RocketMQ看broker的putMessageDistributeTime和ConsumerLag。没有监控就调优，等于闭着眼开车。

4.3 可视化与运维工具

两个MQ都有不错的控制台，但侧重点不同。Kafka的生态工具多，最常用的可视化工具是Kafka UI和Kafdrop，都能看topic列表、分区情况、消费者组和消费延迟。Kafka UI功能更全，还支持直接在界面发送测试消息。桌面端有个叫Offset Explorer的工具（原来叫Kafka Tool），做客户端调试很方便，也是我日常工作用得最多的。

RocketMQ官方控制台是rocketmq-dashboard，功能覆盖主题管理、消费者管理、消息查询、消息轨迹追踪，还能做消息重发、死信队列管理，这在线上排查问题时特别好用。启动它就一句docker run的事，前提是确认Java环境版本匹配。另外RocketMQ自带的mqadmin命令行工具也很强，查主题路由、查消费进度、重置消费位点都靠它，在服务器上没有图形界面时是唯一选择。

如果用Prometheus做监控，Kafka有kafka-exporter，RocketMQ社区也有对应的Metrics插件，配合Grafana面板能看到吞吐趋势、消费积压、磁盘IO等核心指标。一套监控体系搭起来之后，很多看似玄学的性能问题其实一眼就能看到瓶颈在哪。

5. 真实环境里踩过的坑与高频面试题速查

5.1 典型问题排查：消息延迟高、集群宕机、批量消费

Kafka消息延迟高是我被问得最多的问题。排查思路要先分清是生产延迟还是消费延迟。生产延迟高，优先看broker的CPU、内存和PageCache状态，再用kafka-topics.sh --describe看分区数是不是太少，分区数少于消费者并发度就会导致消费者空闲、吞吐受限。消费延迟高，先看消费组lag，用kafka-consumer-groups.sh --describe --group xxx，lag一直涨，说明消费速度跟不上生产速度，重点看消费者拉取参数和业务处理逻辑。之前我排查过一个线上案例，大量消息单条都超过1MB，max.poll.records没调小，消费者拉一次要处理很久，心跳超时被踢出消费者组，结果rebalance频繁，lag暴涨，把参数调小并增加消费线程后恢复。

集群宕机恢复是另一个高频场景。Kafka集群宕机很多时候不是Kafka进程挂了，而是磁盘满了、文件句柄耗尽、PageCache被回收导致IO卡死。如果副本因IO卡顿被移出ISR，消息写入就走不下去。恢复思路是：先看系统指标，再把ISR异常的副本检查一遍，用kafka-reassign-partitions.sh迁移或补齐副本。RocketMQ集群的常见故障是主从数据不同步、broker注册到nameserver异常。排查时先看mqadmin clusterList确认broker是否在线、主从复制状态是否正常，再查磁盘空间。

RocketMQ批量消费场景里，新手容易误解“批量”是broker一次推很多消息，其实批量主要靠消费者配置。核心是把消费逻辑改成list处理，一条条处理还是打平成list处理，性能差距可能是几倍。如果你用的是Spring Cloud Stream或者RocketMQ的push consumer，要确认消费者端的consumeMessageBatchMaxSize配置，默认是1，意味着即使broker一次性给你推送多条，框架也会一条条回调你的方法。改成大于1后，回调方法收到的是List，这时候才能做真正的批量处理，比如批量入库、批量调用外部服务。

5.2 让新手崩溃的配置与启动问题

Kafka新手常见报错no service name defined in either jaas or kafka config，这跟认证配置有关，通常出现在启用了SASL或Kerberos的集群连接场景。解决思路是先确认自己的客户端有没有配置jaas文件，Kafka的JAAS配置既可以通过-Djava.security.auth.login.config指定，也可以在Kafka配置里通过sasl.jaas.config直接内联，两种方式至少要有一种，否则就报这个错。如果你只是连着玩的本地单机版，建议先把协议配置成PLAINTEXT，别上来就用SASL。

Windows上部署Kafka也是经典大坑。Kafka本身是跨平台的，但Windows下有两个问题：一是shell脚本要换成.bat版本，kafka-server-start.bat而不是kafka-server-start.sh；二是JDK版本不匹配，Kafka 3.x在JDK8和JDK11上都能跑，但RocketMQ 5.x建议用JDK11+，如果你在Windows本地装RocketMQ老出新特性异常，先检查JDK版本。RocketMQ的Windows安装还要注意data路径不能有空格，否则启动会莫名其妙失败。

离线部署的情况我也遇到过。要求不能联网拉镜像的隔离环境里，部署Kafka一定要提前把镜像导出成tar包，用docker save和docker load中转。如果有JDK要求，也需要准备离线的JDK包。这种环境下我建议直接采用二进制包部署而非容器，毕竟Kafka和RocketMQ的官方包都是免安装的，解压就能跑，离线环境里操作反而更可控。

5.3 面试题速查：两套MQ的高频考点

面试和晋升答辩里这两个MQ被问得最多的几个问题，我整理成一份速查，方便你临时抱佛脚：

• 为什么Kafka吞吐高？答：顺序写磁盘、PageCache利用、批量攒批、分区并行、零拷贝（sendfile）。
• 为什么RocketMQ写入也很快？答：所有消息顺序写CommitLog、mmap内存映射、异步刷盘、堆外内存池。
• 零拷贝原理是啥？答：减少用户态内核态切换和数据拷贝次数，常见手段mmap和sendfile，分别对应减少CPU拷贝和绕过用户空间。
• Kafka消息会丢吗？答：看配置。acks=0可能丢，acks=1宕机丢，acks=all配合min.insync.replicas才能最大程度避免。
• RocketMQ如何保证消息不丢？答：同步刷盘+同步复制，生产者重试，消费端手动确认，死信兜底。
• Kafka能保证消息顺序吗？答：只能保证分区内顺序，分区之间不保证。要全局顺序只能单分区，代价是吞吐受限。
• RocketMQ支持事务消息吗？答：支持。通过半消息和消息回查机制实现最终一致性。

还有一个大方向经常被问：到底怎么选型？我的思路是，日志采集、数据管道、实时计算接入，Kafka闭眼选；业务系统内部的消息通知、订单状态流转、需要重试和死信的，RocketMQ更顺手。两者不是替代关系，很多大厂会同时部署两套，各干各的活用。

结尾

最后再分享一个我个人的实操习惯：每套MQ的线上环境，我都至少会确认三张配置清单——生产端参数、消费端参数、副本与刷盘策略。不要等到线上出问题了再临时去翻配置，很多延迟和丢消息问题，其实在你上线第一版的时候就已经埋下了。Kafka和RocketMQ的读写模型和零拷贝技术，说到底都是围绕“磁盘顺序写、内存少拷贝、网络少往返”这三件事在做文章，把这三条主线记在脑子里，你再看任何消息中间件都会快得多。踩过几次坑之后你会发现，所谓性能优化，大多数时候不是某个神秘参数，而是把存储、IO、网络、GC这些基础环节一点点抠回来的。