文章目录
- 前言
- 一、Kafka 的 ACK 机制
- acks = 0：最快但最不可靠
- acks = 1：Kafka 默认设置
- acks = -1（或 all）：最可靠但最慢
- 三种 ACK 对比
- 二、Kafka 提供的 API 有哪些
- Sample API（底层 API）
- High-level API（高级 API）
- Consumer Group 机制
- 两套 API 对比
- 三、Kafka 创建 Topic 后如何将分区放置到不同的 Broker 中
- 规则一：副本因子不能大于 Broker 的个数
- 规则二：第一个分区的第一个副本随机放置
- 规则三：其他分区依次往后移
- 规则四：剩余副本的放置
- 总结
前言
用 Kafka 的第一步通常是把消息发出去、消费回来，看起来很简单。但稍微深入就会遇到一连串的选择题：acks 设 0 还是 -1？用 High-level API 还是 Sample API？分区副本怎么就自动散落到不同机器上了？
这些选择背后都有明确的设计意图。ACK 机制决定了你在"快"和"稳"之间站哪边，两套 Consumer API 决定了你要自己管状态还是交给框架，分区分配规则则决定了集群负载是否均衡。
本期西瓜带你学Kafka就把这三个机制拆开讲清楚
一、Kafka 的 ACK 机制
ACK 机制是 Producer 端最核心的可靠性配置，它决定了"一条消息发出去之后，什么时候才算发送成功"。
Kafka 的 Producer 有三种 ACK 机制，通过参数acks配置，可选值为0、1和-1。
acks = 0：最快但最不可靠
相当于异步操作。Producer 不需要 Leader 给予回复，发送完就认为成功，继续发送下一条（批）Message。
- 延迟：最低
- 可靠性：最差
- 风险：当服务器发生故障时，很可能发生数据丢失。消息发出去了，但 Broker 可能根本没收到
适用场景：日志采集、监控打点等允许少量丢失的场景。
acks = 1：Kafka 默认设置
表示 Producer 要 Leader 确认已成功接收数据才发送下一条（批）Message。
- 延迟：较低
- 可靠性：较好
- 风险：Leader 宕机，Follower 尚未复制的情况下，数据就会丢失
这是延迟和可靠性之间的折中方案，适合大多数业务场景。
acks = -1（或 all）：最可靠但最慢
Leader 接收到消息之后，还必须要求 ISR 列表里跟 Leader 保持同步的那些 Follower 都确认消息已同步，Producer 才发送下一条（批）Message。
- 延迟：最高
- 可靠性：最好
- 风险：几乎不会丢消息（除非 ISR 中所有副本同时宕机）
适用场景：金融交易、订单系统等对数据零丢失有严格要求的场景。
三种 ACK 对比
| acks 值 | 等待确认 | 延迟 | 可靠性 | 丢消息风险 |
|---|---|---|---|---|
| 0 | 不等待任何确认 | 最低 | 最差 | Broker 故障即丢失 |
| 1 | 等待 Leader 确认 | 较低 | 较好 | Leader 宕机且 Follower 未同步时丢失 |
| -1 | 等待 ISR 所有副本确认 | 最高 | 最好 | 几乎不丢失 |
二、Kafka 提供的 API 有哪些
Kafka 提供了两套 Consumer API，分别是High-level API和Sample API（也叫 Simple Consumer API / Low-level API）。两者的定位完全不同。
Sample API（底层 API）
这是一个底层 API，特点如下：
- 维持了一个与单一 Broker的连接
- 完全无状态，每次请求都需要指定 offset 值
- 因此这套 API 也是最灵活的
适用场景：需要精确控制消费位置、需要自定义消费逻辑、需要消费特定 Partition 的场景。
代价是：所有的状态管理（offset 记录、Broker 发现、故障转移）都需要自己实现。
High-level API（高级 API）
该 API 封装了对集群中一系列 Broker 的访问，使用起来更简单：
- 可以透明地消费下一个 Topic 的消息
- 自己维护了已消费消息的状态，即每次消费的都是下一个消息，不需要手动管理 offset
Consumer Group 机制
High-level API 还支持以组（Group）的形式消费 Topic，这是它最强大的特性：
同组名 = 队列模式
如果 Consumers 有同一个组名，那么 Kafka 就相当于一个队列消息服务。各个 Consumer 均衡地消费相应 Partition 中的数据，每条消息只会被组内的一个 Consumer 消费。
不同组名 = 广播模式
若 Consumers 有不同的组名，那么此时 Kafka 就相当于一个广播服务，会把 Topic 中的所有消息广播到每个 Consumer。
两套 API 对比
| 特性 | Sample API | High-level API |
|---|---|---|
| 状态管理 | 无状态，手动管理 offset | 自动维护消费状态 |
| 连接方式 | 单一 Broker | 集群级别 |
| 灵活性 | 最灵活 | 受限但够用 |
| 使用复杂度 | 高 | 低 |
| Consumer Group | 不支持 | 支持 |
| 适用场景 | 精确控制、特殊需求 | 常规业务消费 |
三、Kafka 创建 Topic 后如何将分区放置到不同的 Broker 中
创建 Topic 时，Kafka 需要决定每个 Partition 的各个副本分别放在哪台 Broker 上。这个分配遵循以下规则：
规则一：副本因子不能大于 Broker 的个数
这很好理解——如果只有 3 台 Broker，你不可能创建 4 个副本，因为没有足够的机器来放置。
规则二：第一个分区的第一个副本随机放置
第一个分区（编号为 0）的第一个副本放置位置是随机从 BrokerList 中选择的。这个随机起点保证了不同 Topic 的分区不会总是从同一台 Broker 开始分配。
规则三：其他分区依次往后移
其他分区的第一个副本放置位置相对于第 0 个分区依次往后移。
举个例子：假设有 3 个 Broker、3 个分区，第一个分区随机选中了第二个 Broker，那么：
| 分区 | 第一个副本放置的 Broker |
|---|---|
| Partition-0 | Broker-2（随机选中） |
| Partition-1 | Broker-3（往后移一位） |
| Partition-2 | Broker-1（再往后移一位，循环回来） |
规则四：剩余副本的放置
剩余的副本相对于第一个副本放置位置，其实是由nextReplicaShift决定的，而这个数也是随机产生的。
这样设计的目的是：让副本尽可能均匀地分散在不同的 Broker 上，避免某台 Broker 承载过多的副本导致负载不均衡，同时也避免同一个 Partition 的多个副本落在同一台 Broker 上（那样就失去了容灾意义）。
总结
- ACK 机制：三种级别（0/1/-1）在延迟和可靠性之间提供了灵活的权衡选择，根据业务对数据丢失的容忍度来配置
- 两套 API：Sample API 灵活但复杂，High-level API 简单且支持 Consumer Group 的队列/广播两种模式
- 分区分配规则：随机起点 + 依次后移 + 随机偏移，确保副本在集群中均匀分布
