日志采集场景中，Kafka 确实是目前（2025–2026 年）最主流的选择，而 RocketMQ 虽然也很优秀，但在日志聚合、统一收集、流式处理这类需求上，使用频率明显低于 Kafka。下面从实际工程实践角度说明为什么大多数公司/团队最终还是选了 Kafka，而不是 RocketMQ。
1. 生态与客户端支持（决定性因素之一）
| 维度 | Kafka | RocketMQ | 谁赢？ & 对日志采集的影响 |
|---|---|---|---|
| 日志采集 Agent | Filebeat、Fluent Bit、Fluentd、Logstash 原生支持 | 支持，但需要额外插件或自己写 producer | Kafka 胜 → 开箱即用，几乎不用改配置 |
| 社区与文档 | 全球最大，中文英文资料极丰富 | 主要阿里系 + 部分中文社区 | Kafka 胜 → 遇到问题 Google 基本能搜到答案 |
| 公司/云厂商默认集成 | AWS MSK、Confluent、Azure Event Hubs、华为云、腾讯云等都主推 Kafka | 阿里云/华为云有 RocketMQ，但非唯一首选 | Kafka 胜 → 云上日志方案基本默认走 Kafka |
| 下游消费生态 | Flink、Spark Streaming、ClickHouse、Elasticsearch、DataHub 等原生 connector 最完善 | 支持，但 connector 成熟度 & 社区活跃度低 | Kafka 胜 → 从采集 → 存储 → 分析整条链路最顺滑 |
一句话：日志采集的上游 Agent 和下游大数据生态，几乎都把 Kafka 当成“事实标准”，这导致切换成本极高。
2. 吞吐量 & 性能（日志场景最敏感的指标）
日志采集典型特征：海量小消息、高写入吞吐、低价值单条消息、对延迟相对不敏感。
| 指标 | Kafka | RocketMQ | 谁更适合日志采集？ |
|---|---|---|---|
| 单机写入吞吐 | 百万 TPS 很常见（甚至更高） | 十万～几十万 TPS | Kafka 明显占优 |
| 零拷贝 & sendfile | 原生支持 sendfile + 顺序写 + page cache 优化 | 主要靠 mmap + commitlog | Kafka 在大批量小包场景下 CPU & 网络效率更高 |
| 批量 & 压缩 | Producer 端批量 + 压缩（snappy/lz4/zstd）极致优化 | 支持批量，但整体吞吐不如 Kafka | Kafka 胜 |
| 磁盘利用率 | Partition → log segment，顺序追加 | CommitLog + ConsumeQueue 双文件结构 | Kafka 更简单，随机写更少 |
真实压测结论（多家公司 2024–2025 数据）：
- Kafka 单 broker 写入能轻松跑到 80–150 万条/s（小日志）
- RocketMQ 一般在 20–60 万条/s 左右
日志采集对成本敏感 → 同样的机器，Kafka 能扛更多日志，省机器、省钱。
3. 消息语义 & 特性对比（日志场景下谁更合适）
| 特性 | Kafka | RocketMQ | 日志采集更需要谁？ |
|---|---|---|---|
| 严格顺序保证 | Partition 内有序 | Queue 内严格有序 | 日志基本不强依赖全局顺序，Kafka 够用 |
| 事务消息 | 支持事务（exactly-once） | 原生支持分布式事务 | 日志采集几乎不用事务 |
| 消息回溯 / 重放 | offset + 保留时间 / 大容量日志 | 支持重置消费位点 | Kafka 的日志风格 + 无限期保留更适合审计/回溯 |
| 延迟队列 / 定时消息 | 不原生支持 | 原生支持 | 日志采集不需要 |
| 死信队列 | 无（靠死信主题自己实现） | 原生死信队列 | 日志采集对丢消息容忍度高，通常不care死信 |
| 消费进度管理 | offset 由 consumer 自己管理 | broker 帮管 | Kafka 更灵活（尤其配合 Flink 等 exactly-once） |
日志采集的核心诉求是“尽量不丢、能回溯、吞吐量越大越好”，Kafka 在这三点上都更贴合，而 RocketMQ 的强项（事务、顺序、定时、死信）在日志场景基本用不上。
4. 实际公司选择倾向（2025–2026 真实情况）
- 国际 / 大数据公司（Google、Uber、Netflix、字节跳动国际版、Snowflake 用户等）→ 几乎 100% Kafka
- 中国互联网大厂：
- 字节跳动、腾讯、百度、美团 → 主力 Kafka（日志域）
- 阿里系（淘宝、天猫、支付宝）→ 早期大量 RocketMQ，但日志域也大量混用 Kafka
- 云厂商日志服务：
- AWS CloudWatch + Kinesis → Kafka 兼容
- 阿里云 SLS → 支持 RocketMQ，但默认推 Kafka 协议
- 华为云、腾讯云 → Kafka 占主导
一句话总结：日志采集已经形成了“Kafka 生态闭环”，采集端 → 中间件 → 存储 → 计算 → 可视化 整条链路最成熟、最省心。
什么时候反而更适合 RocketMQ？
- 你已经在阿里云生态深处，且全部用 RocketMQ 事务消息
- 业务对严格顺序 + 分布式事务要求极高（金融、对账、核心交易链路）
- 消息量不算特别大，但对低延迟 + 精确一次要求更高
- 公司内部全部用 RocketMQ，想保持技术栈统一
但如果单纯做日志采集 + 指标聚合 + 链路追踪 + 用户行为分析，绝大多数团队在 2025–2026 年仍然会优先选择 Kafka。
你所在的场景是纯日志聚合，还是混杂了交易/订单消息？
或者你已经在用 RocketMQ，想知道迁移到 Kafka 的性价比？可以继续聊～
