RabbitMQ 系列讲完之后，本篇切换到 Kafka。和 Rabbit 不同，Kafka 的定位不是 MQ——它是「分布式流处理平台」。这个根本性的定位差异决定了它和 RabbitMQ 的所有不同：吞吐量、消息可靠性、有序性、消费模型。本系列 3 篇，先从「它是什么、能干嘛、消息怎么保证不丢」讲起。
一、Kafka 是什么
Kafka 是一个分布式流处理平台（Distributed Streaming Platform）。它提供三大能力：
- 发布订阅消息流（类似 MQ）
- 以容错的方式存储流记录
- 实时处理流记录
关键词是「流」——Kafka 把消息当成持续不断的流来处理，而不是「一条一条的消息」。这个定位决定了它在大数据、日志、监控领域的统治地位。
1.1 Kafka 的核心特性
- 分布式流处理平台（不是 MQ）
- 提供发布订阅 + topic 支持，可以当成 MQ 来用
- 吞吐量极高，但不保证消息的全局有序（只能保证 partition 内有序）
- 与其他 MQ 不同，靠 offset 可以实现重复消费（基于日志机制）
「重复消费」是 Kafka 与传统 MQ 最大的区别之一：传统 MQ 消息被消费后就删除，Kafka 的消息可以保留几天甚至几个月——消费完后只是 offset 移动，下次可以从任意 offset 重新消费。这是流处理的基础。
二、四大典型应用场景
| 场景 | 描述 |
|---|---|
| 日志收集 | 把分布式系统的日志统一汇聚到 Kafka，再落到 ES / HDFS |
| 流式系统 | 配合 Spark Streaming / Flink 做实时计算 |
| 消息系统 | 业务消息总线（对消息有序性不在意的场景） |
| 用户活动跟踪 / 运营指标监控 | 用户行为埋点、实时大盘 |
大厂的「埋点 → Kafka → 实时计算 → 大盘」几乎是标配。你今天在淘宝点的每一颗按钮，都通过 Kafka 流到了下游。
三、核心概念速览
理解 Kafka，必须先把这几个名词搞清楚：
| 概念 | 含义 |
|---|---|
| Broker | 一个 Kafka 服务节点 |
| Topic | 消息主题，逻辑分类（如 user_action） |
| Partition | Topic 的物理分片，并行单元 |
| Producer | 消息生产者 |
| Consumer | 消息消费者 |
| Consumer Group | 消费者组，组内分摊消费、组间独立消费 |
| Offset | 消费者在 partition 中的位置游标 |
| Replica | 副本（leader / follower） |
| ISR | In-Sync Replicas，与 leader 保持同步的副本集合 |
Topic: order-events（3 个 partition）
├── Partition 0 → [msg0, msg1, msg2, msg3, ...]
├── Partition 1 → [msg0, msg1, msg2, ...]
└── Partition 2 → [msg0, msg1, msg2, msg3, msg4, ...]partition 是 Kafka 高吞吐的物理基础——不同 partition 可以并行读写。partition 数量直接决定并发上限。
四、Kafka 与 RabbitMQ 的定位差异
回顾 MQ 选型对比，再补一张 Kafka vs RabbitMQ 的细化表：
| 维度 | RabbitMQ | Kafka |
|---|---|---|
| 定位 | 消息队列 | 流处理平台 |
| 单机吞吐 | 万级 | 十万级 |
| 延迟 | μs 级 | ms 级 |
| 消息模型 | 队列（消费即删除） | 日志（按 offset 消费、可重放） |
| 路由能力 | 强（Exchange + routing key） | 弱（按 topic 订阅） |
| 有序性 | 队列内有序 | partition 内有序 |
| 消息堆积 | 内存/磁盘，堆积会拖垮性能 | 天生为堆积设计 |
| 事务消息 | 弱 | 支持（0.11+ Transactions） |
| 典型场景 | 业务消息、复杂路由 | 大数据、日志、流处理 |
不是二选一，而是各管一头——很多大公司同时用 RabbitMQ（业务消息）和 Kafka（大数据）。业务消息走 Rabbit，埋点日志走 Kafka。
五、消息传递保障（核心）
这是 Kafka 最重要的一节。配置项：ACKS_CONFIG（生产者侧）。
消息传递有三种语义：
| 语义 | acks 值 | 消息消费次数 | 性能 | 适用场景 |
|---|---|---|---|---|
| 最多一次（At most once） | 0 | 0 ~ 1 次 | 最好 | 允许丢的指标/日志 |
| 至少一次（At least once） | 1 | 1 ~ 多次 | 中等 | 大多数业务 |
| 只有一次（Exactly once） | all | 1 次 | 最差 | 计费、交易 |
5.1 最多一次（acks = 0）
- Producer 发送消息后，不需要等待任何确认
- 配置的重试不生效，回馈的 offset 总是
-1 - 消息可能消费 0 到 1 次（可能丢）
适用：允许丢失的指标数据——比如每秒一次的 CPU 监控，丢一条无所谓，下一秒还会有。
5.2 至少一次（acks = 1）
- 至少等待 leader 成功把数据写到本地 log
- 不等待 follower 是否写入成功
- 此时如果 follower 未写入时 leader 挂掉，消息丢失
这是 Kafka 的默认值。生产环境的最低保障，配合重试可以达到「至少一次」。
5.3 只有一次（acks = all）
- leader 等待所有 ISR 副本都成功写入日志
- 最强保证，效率最差
- 生产者发送消息时，生成一个 id（PID + seq），broker 拿到消息后根据 id 去重
acks = all:
Producer → Leader → 等待所有 ISR 写入 → 返回 ack
↓
Follower1 ✅
Follower2 ✅ ← 全部确认后才算成功Kafka 在 0.11 版本（2017 年）就引入了 Exactly-Once Producer 语义——通过 PID（Producer ID）+ Sequence Number 实现幂等发送，配合事务 API 可以实现”只有一次”。本文发布于 2018 年 5 月，当时 Kafka 1.1 已具备完整的 exactly-once 能力，不是 2.5 才引入。重要数据（计费、交易、扣款）必须用
all+ Transactions。
5.4 怎么选
| 业务类型 | 推荐 acks |
|---|---|
| 日志、监控埋点 | 0 |
| 普通业务消息 | 1（默认） |
| 订单、支付、扣款 | all |
| 流处理 Exactly-Once | all + Transactions |
生产建议：核心业务一律
all，宁可慢也不要丢；埋点和日志0或1即可，吞吐量第一。
六、Kafka 为什么这么快（预告）
本篇不展开，下一篇「Kafka（中）」会详细讲。这里先给结论：
- 日志顺序读写（磁盘顺序 IO 接近内存）
- partition 并行
- 批量发送 + 数据压缩
- 零拷贝（sendfile）
这四条加起来，让单机 Kafka 能扛住十万级 TPS。下一篇会把每一条掰开揉碎讲，包括零拷贝为什么从 4 步变成 2 步。
七、小结
| 概念 | 一句话 |
|---|---|
| Kafka 定位 | 流处理平台（不是 MQ） |
| 核心特性 | 高吞吐、partition 并行、可重放 |
| 典型场景 | 日志、流处理、监控、消息总线 |
| 三种语义 | at-most-once / at-least-once / exactly-once |
| 生产核心配置 | acks（0/1/all） |
下一篇「Kafka（中）：吞吐量为什么这么大——日志、零拷贝、批量」进入 Kafka 的「性能原理」——为什么它能扛住十万 TPS，磁盘 IO 是怎么被榨干的。
现代视角补一句（2026）：到 2026 年，Kafka 的 KRaft 模式已经成熟——不再依赖 ZooKeeper，元数据用 Raft 自管理。同时 Partition Tiered Storage（分层存储）让 Kafka 能堆 TB 级数据而不用每个 broker 都扛全量。但 acks 三档语义、partition 并行模型——这些 2018 年的设计到现在一点没变。