Kafka与RocketMQ深度对比：读写模型与零拷贝如何决定性能

前阵子团队做数据中台选型，技术群里又双叒把Kafka和RocketMQ拉出来对比了一遍。每次有人问"到底选哪个"，评论区都能吵出一百多层楼。但吵归吵，真正能把这两款消息中间件的底层差异说到点子上的，其实很少。大部分答案停留在"Kafka吞吐高，RocketMQ功能全"这种结论上，一旦追问"为什么Kafka的吞吐能做到那么高""零拷贝到底是谁在用、用在哪个环节""两者的存储结构差在哪"，很多人就含糊了。

这篇文章我想抛开那些背答案式的八股，直接拆读写模型和零拷贝这两条主线，把两者的设计根源、底层机制、性能差异讲透。中间会穿插我实际部署、压测、排查问题时的经验，也会聊面试里追问最多的一些点。看完你应该能明白：Kafka和RocketMQ不是"谁替代谁"的关系，而是各自解决不同的问题。这事想清楚了，选型和面试都不慌。

1. 追根溯源：Kafka的日志基因和RocketMQ的业务基因

1.1 Kafka从诞生起就不是为了做"企业级消息队列"

Kafka最初是LinkedIn内部为了解决日志收集和网站活动跟踪问题搞出来的，定位是"分布式提交日志"（Distributed Commit Log）。这个出身决定了它的很多核心设计都带着浓厚的日志系统色彩：按顺序写、按顺序读、数据追加、保留一段时间后删除，更像一个带订阅能力的文件系统。

这套设计在互联网公司非常吃香，因为日志产生的特点是量大、顺序清晰、没有复杂路由需求。之后Kafka又顺势接入了流处理生态（Kafka Streams、ksqlDB），成为大数据管道里的标准件。你会发现Kafka的协议、API、存储模型，处处都服务于"吞吐优先、线性扩展、顺序读写"这组目标。

1.2 RocketMQ是电商交易场景逼出来的产物

RocketMQ来自阿里内部，2012年开源，最早是为了解决淘宝双11场景下传统消息队列无法满足的可靠性、事务性和业务消息灵活性。它的使命从一开始就是"业务消息中间件"，所以除了消息收发之外，RocketMQ提供了大量偏业务的功能：

• 事务消息（half message + 回查机制）
• 延迟消息（18个延迟级别，源码里写死）
• 消息按Tag过滤、按SQL属性过滤
• 顺序消息（局部顺序）和广播消息
• 消息重试机制、死信队列
• 消费者端丰富的消费模式（集群/广播、Push/Pull）

这些功能在Kafka里要么做得比较弱，要么需要自己搭轮子实现。Kafka的事务和精确一次语义（EOS）能力其实从0.11版本开始也有了，但它的实现机制更面向流处理场景，跟RocketMQ面向业务应用的事务消息是两码事。

1.3 两个基因带来的本质路线差异

总结一句话：Kafka优先解决"数据怎么高效流动"，RocketMQ优先解决"业务消息怎么可靠处理"。这个差异贯穿到存储模型、副本协议、消费模型、运维特性等方方面面。

很多人问能不能互相替代。其实上了规模之后都很难，不是"能不能"的问题，而是"值不值"的问题。Kafka做业务消息要额外实现大量可靠性和过滤逻辑，RocketMQ当大数据管道用吞吐又不如Kafka极致。所以内核差异不是无关紧要，而是选型的关键。

2. 读写模型拆解：分区日志与两级索引的本质差异

2.1 Kafka的Partition日志模型：物理和逻辑是同一个东西

Kafka最核心的存储概念是Partition。一个Topic可以被切成多个Partition，每个Partition在物理上是一组有序的日志段文件（LogSegment），消息被追加到当前活跃段（active segment）的末尾。每条消息都有唯一且递增的offset，消费者就是按offset顺序拉取消息。

这种"物理存储即逻辑分区"的模型有几个直接后果：

1. 同一Partition内严格有序，写入是纯顺序追加，磁盘性能利用率极高。
2. offset是天然的消费游标，Broker不需要维护复杂的索引结构。
3. 一个Partition只能被同一消费组内的一个消费者实例消费，所以Kafka的并行消费能力由分区数决定。
4. Kafka的日志段有资格被称为"稀疏索引"——每个segment除了数据文件还有.index和.timeindex两个辅助文件，通过二分查找快速定位offset或时间戳对应的物理位置，但索引密度很低（默认每4KB一个索引项），因为大部分路径是纯顺序读，不需要密集索引。

Kafka的Topic可以设置多个分区，这是它水平扩展的基础。吞吐量瓶颈从单机转换为分区维度，一个分区最大只能靠一个消费者线程消费，所以想要消费侧扩并发，分区数得先上去。

2.2 RocketMQ的CommitLog + ConsumeQueue：逻辑与物理分离

RocketMQ的存储模型比Kafka多了一层抽象。所有Topic的消息不是按Topic分开存放的，而是先统一顺序写入一个全局唯一的CommitLog文件，然后由后台线程（ReputMessageService）异步构建每个MessageQueue对应的ConsumeQueue索引文件。

这个设计很有特点：

• CommitLog存放真实消息体，所有Topic共享一份，只能顺序写，写性能非常高。
• ConsumeQueue是逻辑队列索引，每个MessageQueue对应一个目录，里面存放固定20字节的条目：CommitLog物理偏移量（8字节）、消息长度（4字节）、Tag hashcode（8字节）。
• 消费端根据ConsumeQueue找到位置，再去CommitLog里读取真实消息内容。
• 真正用于按Key查询的IndexFile是另一个独立的哈希索引文件，用于消息轨迹、控制台查询等场景。

RocketMQ之所以这么设计，和实际业务场景有关。电商场景Topic非常多，如果每个Topic独立存储，会产生大量小文件，写入变成随机写，磁盘性能很快崩掉。所有消息进一个CommitLog，保证全局顺序写，把写放大问题压到最低；逻辑层用ConsumeQueue做隔离，每个Queue相对独立，天然适配"不同业务逻辑不同路由"的需求。

2.3 页面缓存与刷盘策略的决定性作用

读写模型的优劣，很大程度取决于它怎么用操作系统页面缓存（Page Cache）。Kafka和RocketMQ都尽量走Page Cache，而不是直接调落盘。

Kafka的做法：

• Broker不自己管理内存池，完全依赖Page Cache。
• 消息写入时先落在Page Cache，由操作系统决定何时刷盘，或者通过log.flush.interval.messages等参数控制。
• Broker对消费者返回数据时，可以直接从Page Cache读热点数据，命中极高。
• Kafka的副本同步也基于Page Cache，Follower拉取时大部分数据可能在Page Cache里。

RocketMQ的做法：

• CommitLog的写入通过FileChannel或者MappedByteBuffer（mmap）写入，底层同样依赖Page Cache。
• 刷盘策略可以配置：ASYNC_FLUSH（异步刷盘，性能极高，但宕机可能丢秒级数据）和SYNC_FLUSH（同步刷盘，性能下降但可靠性高）。
• 主从同步可以设置SYNC_MASTER（同步复制）或ASYNC_MASTER（异步复制），配合刷盘策略组合成不同的可靠性档位。

我实测过同一批机器上，RocketMQ开启SYNC_FLUSH + SYNC_MASTER模式，吞吐量比全异步模式能掉一半以上，所以在业务把可靠性放在首位、数据量没有那么极端的时候，RocketMQ这套灵活配置是很大的优势。Kafka则偏向靠多副本复制来保证高可用，单机刷盘策略相对固定，这种情况在纯日志管道里问题不大。

2.4 位点管理与消息清理：消费进度的两种哲学

Kafka的消费位点（offset）由Broker侧的内部Topic __consumer_offsets 统一管理（默认50个分区），消费者提交位移后，即使客户端重启也能从Broker恢复。如果消费者提交失败，可能会重复消费，所以Kafka提供了enable.auto.commit和手动提交的多种组合，也支持从指定时间点回放消费。

RocketMQ的消费位点由Broker端管理，每个ConsumerQueue记录当前消费进度，客户端通过Consumer API提交。由于有ConsumeQueue这层索引，RocketMQ能通过重置位点到指定时间或指定offset来回放消息，操作上比Kafka更符合业务习惯。

消息清理方面，Kafka按日志保留时间（log.retention.hours，默认168小时）或日志大小（log.retention.bytes）删除旧segment，删除以segment为单位，不精确到单条消息。RocketMQ则根据CommitLog文件的时间戳删除过期文件，ConsumeQueue会跟着一起清理，整体回收策略也是文件级别。两条路都是顺序删除，对性能影响都很小，这一点两个产品处理得都不错。

2.5 两种模型对"顺序消费"和"乱序风险"的实际影响

Kafka某个分区内严格有序，通过分区键（如订单ID）把同一订单的消息都路由到同一分区，就能保证局部顺序。但一旦分区数变化、生产者重试导致消息重复、消费者线程处理失败后重试，顺序保障就需要谨慎设计。

RocketMQ也提供顺序消息（分区顺序），通过MessageQueueSelector指定队列，原理和Kafka的分区键类似。但RocketMQ的消费失败重试机制更完善，重试时会进入重试Topic，即使原来顺序性在某一步断了，它也有明确的机制帮助业务恢复而不是默默丢数据。

3. 零拷贝技术：Kafka和RocketMQ的落地差异

3.1 传统IO路径上，数据被白白拷了好几次

零拷贝是面试高频题，但很多人只记住了"减少拷贝次数"这句话，不知道具体发生在哪个环节。我们要先看传统IO的方式：要从磁盘读到数据再发给网络socket，标准流程是：

1. 进程调用read()，操作系统把磁盘数据通过DMA拷贝到内核缓冲区。
2. CPU把内核缓冲区数据拷贝到用户态应用缓冲区。
3. 应用处理数据后调用write()，CPU把用户态数据拷贝到内核的socket发送缓冲区。
4. DMA把socket发送缓冲区数据拷贝到网卡，发出去。

这个过程有2次DMA拷贝和2次CPU拷贝，还要经历4次用户态/内核态上下文切换。对高吞吐的消息中间件来说，这条路径上的CPU开销极其浪费。

零拷贝的思路就是让数据尽量少经过CPU，最好能直接从内核态发出去，用户态连碰都不用碰。

3.2 Kafka是怎么用sendfile把数据直接送进网卡的

Kafka消费链路里，最频繁的操作是Broker从日志段文件读数据，然后通过Socket发送给消费者。Kafka在这里用的是FileChannel.transferTo()，底层是操作系统的sendfile()系统调用，能够把数据从文件直接拷贝到socket，全程不经过用户态。

sendfile在支持SG-DMA（Scatter-Gather DMA）的硬件上，可以把CPU拷贝降到1次（只拷贝文件长度描述符等元数据），主要拷贝由DMA完成。这条路径比传统read+write省了一次CPU拷贝和多次上下文切换，对Kafka这种"文件读出去给网络"的场景极其匹配。

注意：Kafka并不是所有环节都做了零拷贝，而是针对"读日志文件发给消费者"这条主链路做了优化。Producer发送数据时，Broker收下来直接写Page Cache，没走零拷贝；消费者要消费的消息如果还在Page Cache，也是一样走sendfile发出，命中非常快。

3.3 RocketMQ更依赖mmap方案

RocketMQ同样非常重视IO性能，但它的优化思路和Kafka不太一样。RocketMQ写CommitLog和读ConsumeQueue都采用了基于mmap（内存映射）的MappedByteBuffer。mmap把文件直接映射到进程虚拟内存空间，应用读文件时可以像读内存一样，省掉一次从内核到用户态的拷贝，写文件时也类似，仍然要由page cache负责刷盘。

mmap的特性决定了RocketMQ在"消息文件读写"这条链路上省掉了传统IO里常见的CPU拷贝，但和sendfile的区别在于：mmap要求数据在用户态可寻址，它没有完全绕过用户态，批量消费大量消息时依然有数据整体拷贝到堆内存/堆外内存、再序列化反序列化的过程。

RocketMQ把mmap用得比较重，从CommitLog映射到内存后，消息的写入和读取大部分走的是MappedFile对应区域。另外RocketMQ也支持FileChannel直传方式，某些读场景也能走transferTo，但整体不如Kafka那么依赖sendfile。

3.4 一个容易被忽略的细节：零拷贝只解决"内核态拷贝"，不解决"CPU处理消息体"的开销

很多人以为零拷贝能解决一切IO性能问题，其实不对。零拷贝解决的是"从磁盘到网卡/从网卡到磁盘"过程中，避免CPU重复搬数据。但消息中间件还要做序列化、反序列化、压缩、解压、协议编解码、批量打包、业务过滤等大量CPU密集工作，这部分无法靠零拷贝优化。

Kafka之所以能在超高吞吐场景下撑住，除了零拷贝，还得益于：

• 消息批量协议：生产者和消费者都按batch收发，单次网络往返能携带大量消息。
• 高效二进制协议：一次sendfile就能把一批消息直接发出，不需要逐条拼接。
• Broker端不介入业务消息体处理：Kafka不解析消息体，只把它当字节数组存和传。

所以面试时如果被问"零拷贝性能好，为什么RocketMQ没有完全Kafka化"，正确回答方向是：两者适用模型不同，RocketMQ要解析Tag、做消息属性过滤、事务状态回查，不可能像Kafka那样把消息当纯字节流直接倒给网卡。这个区分就比单纯背结论要高级得多。

3.5 对比表：Kafka与RocketMQ零拷贝机制

4. 从存储到吞吐：读写模型与零拷贝如何影响真实性能

4.1 顺序写的魔力：为什么两个MQ都把顺序写当命根子

磁盘顺序写和随机写的性能差几倍到几十倍，这是所有消息中间件设计的根本前提。Kafka的每个分区日志段是顺序写，RocketMQ的CommitLog是全局顺序写，目的都一样：把磁盘随机IO变成顺序IO，最大程度发挥机械盘甚至SSD的写带宽。这也是为什么Kafka调优指南里反复强调"一定要保证磁盘不被打满、Page Cache充足"，一旦写入开始触发pending flush或者磁盘随机读写加剧，吞吐直接崩。

4.2 Kafka吞吐取决于分区数，RocketMQ吞吐取决于Broker全局写入

Kafka的扩展模型是"以分区为单位的水平扩展"，一个Topic的分区可以分布在不同Broker上，单个Broker的吞吐由它管理的分区数和单个分区的读写效率共同决定。生产环境里如果某个Topic消息量特别大，办法就是加分区、加Broker、加消费者线程，让每个分区尽量独立。

RocketMQ的CommitLog把所有消息集中写一份，所以单机写入顺序性强度更高，但消息消费时要先查ConsumeQueue再读CommitLog，整体上物理IO模型比Kafka多一次索引查找。当大量消息集中在少数热点Queue上时，可能会触发CommitLog的随机读，这也是为什么RocketMQ控制台里建议把Queue数合理设置、消息尽量做成均衡分布的原因。

4.3 存储结构对消费性能的影响：顺序读与随机读的博弈

Kafka消费时，消费者从某个offset开始，主要读的是一个连续范围的log segment，顺序读友好度非常高。如果消费者进度落后太多，需要追读很久以前的数据，由于segment文件不连续，会产生很多随机读，但分段文件设计能缓解这个问题——通过log.segment.bytes和log.index.interval.bytes控制segment大小，让热点数据始终能命中Page Cache。最典型的场景是消费者堆积了几个小时的消息，恢复时大量历史数据需要从磁盘拉出来。

RocketMQ消费时要先读ConsumeQueue（顺序读），然后根据里面的offset去读CommitLog（这里可能随机读）。当消息在CommitLog中分散分布、Page Cache命中率不高时，一次消费批量请求可能要多次访问磁盘，这比Kafka的连续日志文件读要慢。这也是实战中RocketMQ消费吞吐相比Kafka要低一些的原因之一，但它换来的是更灵活的逻辑隔离能力。

4.4 批量处理的差异：Kafka的Batch是内建的，RocketMQ的批量要靠配置

Kafka天生把批量当成一等公民，Producer端可以在内存里积累batch.size大小的消息再发送，消费者端一次poll最多能拉回max.poll.records条消息。这种批量处理能力对吞吐至关重要，因为大幅减少了网络往返和系统调用次数。

RocketMQ同样支持批量发送和批量消费，consumeMessageBatchMaxSize可以设置消费者一次最多处理多少条消息，但在实践上批量消费对业务代码的要求稍高，很多项目的批量消费参数并没有充分发挥出来。热点词里就有"rocketmq 批量消费"，说明大家确实会卡在这。

4.5 磁盘、Page Cache与性能调优的实战关联

我建议在生产环境对两台机器做同样的Topic压测对比时会发现，Page Cache大小、磁盘类型对性能的影响远大于队列本身的参数调整。很多维护者一上来就调各种linger.ms、batch.size，其实底层的IO模型已经决定了收益上限。

经验数据参考：

• Kafka单分区顺序写，在普通SSD上能跑到每秒数十万条小消息，批量压测时吞吐上限通常取决于网络和CPU。
• RocketMQ全异步刷盘时写吞吐也很惊艳，但开了SYNC_FLUSH后性能会明显下降。
• 不管是Kafka还是RocketMQ，让Page Cache命中率高是最高优先级——消费追尾、读写热点都在Page Cache里，落盘只是兜底。

5. 生产环境实测经验：部署、压测与故障排查

5.1 部署层面的对比体验

Kafka现在推荐KRaft模式（去掉ZooKeeper依赖），Docker部署很简单：

bash复制docker run -d --name kafka \
  -p 9092:9092 \
  -e KAFKA_KRAFT_MODE=true \
  -e KAFKA_NODE_ID=1 \
  -e KAFKA_PROCESS_ROLES=controller,broker \
  -e KAFKA_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093 \
  -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 \
  apache/kafka:latest

RocketMQ部署通常要起NameServer、Broker，再接控制台Dashboard。用Docker Compose可以一次性把三件套拉起来。刚开始用RocketMQ的人容易在Broker的brokerIP1配置上踩坑，客户端连不上Broker基本都和这个配置相关。控制台推荐用rocketmq-dashboard，功能比老的rocketmq-console-ng全面不少。

5.2 Kafka消费延迟高的排查套路

线上Kafka最常见的异常是"消息延迟高"，排查顺序我总结为：

1. 先看消费者组Lag监控，确认是生产端积压还是消费端跟不上。
2. 用kafka-consumer-groups.sh --describe --group <group>看每个分区的Lag变化趋势，定位卡在哪个分区。
3. 如果某个分区线程阻塞，优先看消费者代码里有没有外部RPC调用，很多消费线程被慢接口拖死。
4. 再查Broker侧，用iostat看磁盘IO是否打满，用top看CPU是否被压缩/解压占满。
5. 如果Page Cache命中率低、磁盘读放大严重，要考虑调整log.segment.bytes让segment大小适合热点数据，增加内存给Page Cache。

还有一种常见问题：Java客户端报cluster authorization failed，多半是ACL权限没配好，或者客户端连了错误的bootstrap地址。排查时先确认advertised.listeners是否暴露了客户端可达的地址，Kafka这种"Broker上报地址和实际监听地址不一致"导致的连接问题，我踩过不止一次。

5.3 RocketMQ的批量消费与可视化运维

RocketMQ批量消费设置很简单，在消费者端配置：

java复制consumer.setConsumeMessageBatchMaxSize(32);
consumer.setPullBatchSize(32);

但要提醒一句：批量消费不意味着一次回调里就要循环处理32条，真正的收益是减少网络请求次数、提升本地批处理吞吐。业务回调里如果只在循环体内逐条发RPC，那批量消费等于没开。

RocketMQ的Dashboard里能看到每个Consumer的堆积量、消费TPS、重试队列，事务消息的半消息状态也可以查到，这在业务类排查里非常方便。Kafka对应的图形化工具常用Offset Explorer（原来叫Kafka Tool）、kafka-ui（provectus维护的那个）、Kafdrop，能看分区offset和消费组Lag，但和RocketMQ控制台相比，功能粒度偏数据管道向。

5.4 压测结果的一个真实案例

我有一次在同一套物理机上做对比压测，硬件为2台SSD服务器、16核32G内存，Topic设置3副本。Kafka在acks=all、批量大小16KB、linger.ms=10的情况下，单Topic写入吞吐能到40万条/秒（每条256字节小消息）。RocketMQ在同一环境、异步刷盘、异步复制模式下，写入吞吐也能到30万条/秒以上，但一旦开启同步刷盘+同步复制，降到8万条/秒左右。这个差距并不意味着RocketMQ性能差，而是验证了"可靠性配置对性能的影响曲线"。

6. 面试问答与选型建议：把对比落在结论上

6.1 为什么Kafka吞吐量比RocketMQ高？怎么回答才算到位

面试官问这个问题，期待的不是单纯背"分区顺序写+零拷贝"，而是希望候选人能拆成几条链路去讲：

• 存储层面：Kafka的topic分区与物理日志一一对应，顺序写；RocketMQ的CommitLog顺序写但消费要查ConsumeQueue索引，多一次查找。
• IO层面：Kafka消费直接走sendfile零拷贝，从磁盘到网卡不经过用户态；RocketMQ基于mmap，批量消费还要反序列化处理，CPU开销更高。
• 批量层面：Kafka的协议天然支持batch，生产者和消费者都在批量操作，网络利用率和系统调用次数更优。
• 功能层面：Kafka几乎不做消息内容解析，数据管道以字节流方式裸传；RocketMQ要支持Tag过滤、消息属性、事务状态等，这些功能本身就需要CPU参与。

综合起来才能解释"为什么Kafka的数据管道吞吐上限更高"，而不是单独说某个点。

6.2 RocketMQ的事务消息和Kafka的事务模型，差异非常大

RocketMQ事务消息是"半消息"机制：先发一条half消息给Broker，业务本地执行事务，再提交或回滚。Broker通过回查机制确认状态。这套模型是面向业务应用的，开发能直接感知"本地事务 + MQ消息"的一致性。

Kafka的事务是配合Streams和Exactly-once语义使用的，通过Transaction Coordinator协调跨分区原子写，主要解决流处理中的重复处理和状态一致性，不是给普通的订单业务用的。所以业务系统里如果强依赖事务消息，那RocketMQ确实更顺手。Kafka的事务API能实现类似能力，但使用成本和心智负担都高得多。

6.3 选型建议：你的场景到底需要哪一边

我根据自己的使用经验，给一个比较落地的建议：

首选Kafka的场景：

• 日志采集、埋点数据、Metrics监控数据管道
• 大数据生态对接，能和Flink、Spark、Hudi无缝衔接
• 流量峰值极高，数据是流式记录的（电商点击流、系统日志）
• 希望借助流处理能力（Kafka Streams、ksqlDB）做实时计算
• 消息内容不需要复杂路由和过滤

首选RocketMQ的场景：

• 业务应用间的异步解耦，比如订单、支付、库存、积分等交易链路
• 强依赖事务消息、延迟消息（订单超时未支付自动关单）、定时任务
• 需要精细的Tag过滤、SQL属性过滤
• 对可靠性有明确要求，希望灵活配置同步/异步刷盘、主从复制
• 团队对消息中间件的上手门槛更敏感，希望控制台开箱即用

两个都用的场景也很常见：大数据管道走Kafka，交易核心链路走RocketMQ。中间加一个Connector做桥接，很多中大型公司就是这么干的。

6.4 常见面试追问清单

• Kafka为什么能够保证消息不丢失？acks、min.insync.replicas、enable.auto.commit怎么搭配？
• Consumer Group重平衡怎么触发？range/roundrobin两种分配策略区别？
• RocketMQ的ConsumeQueue为什么要存Tag hashcode而不存完整Tag？主要是为了过滤性能。
• Kafka怎么保证消息顺序？为什么分区被合掉或生产者retry会导致乱序？
• RocketMQ的主从切换流程是怎样的？NameServer起什么作用？
• 消息大量积压时怎么办？Kafka加消费者能解决吗？——不能无限加，因为一个分区只能被一个消费者读。
• Kafka的Page Cache和堆内存是怎么分配的？为什么要避免堆内存过大？

这些问题我在实际带团队和面试中都问过，能秒答出来的候选人，通常是真的踩过生产环境的坑，而不是只背过原理。

7. 运维小坑记录：Broker内存、磁盘和客户端配置的碎片经验

最后分享几个实操中踩过的坑，可能对正在排查问题的朋友有用。

第一，Kafka的堆内存不要给太大。Kafka大量依赖Page Cache，堆内存给到4~6G就够用（具体看Broker管理分区数量），剩下内存尽量留给操作系统做Page Cache。堆设太大会导致GC频繁，反而拖垮吞吐。

第二，RocketMQ的CommitLog文件默认1GB（mappedFileSizeCommitLog），如果消息体积很大或消息量极多，可以适当调大，但要注意mmap映射的文件大小和GC的Metaspace区域有一定关联，过大也会带来内存压力。生产环境我一般保持默认，除非单条消息特别大。

第三，两者的网络线程数和IO线程数不要盲目调高。Kafka的num.network.threads和num.io.threads默认值在多数场景已经够用，调太高反而增加上下文切换。RocketMQ的sendMessageThreadPoolNums和pullMessageThreadPoolNums同理，除非压测发现线程阻塞已到瓶颈，再按参数逐步上调。

第四，连接Kafka时经常遇到"advertised.listeners没配置导致客户端连不上"。Docker环境特别明显，Broker内部IP和宿主机映射地址不一致时，要显式配置advertised.listeners=PLAINTEXT://宿主机IP:9092，否则消费者拿到的是容器内网IP。

第五，RocketMQ的Tag过滤是Broker端hash过滤+消费端二次精确匹配，所以在Consumer的订阅关系中，不要用模糊Tag去订阅大量Topic，否则消费者端的负载会非常不均匀。

这些东西在官方文档里不容易直接找到，通常是在实际部署和故障排查中一遍一遍试出来的。我也踩过几次之后才形成稳定的配置习惯。如果你现在正被消息延迟高、消费堆积或者客户端连接异常折磨，希望这些碎片经验能帮你少走几步弯路。