Kafka 存储与消费模型

Tue, 25 Aug 2026 00:00:00 +0000

Kafka 的高性能依赖于「分区日志 + 顺序写 + 批量拉取」的设计。理解存储与消费模型，才能合理配置并行度与避免重复消费。

Topic 与 Partition

topic 是逻辑主题，partition 是物理并行单位，消息只追加写入分区末尾。
每个分区是一个有序、不可变的日志，由多个 segment 文件组成，并维护 offset（分区内唯一递增）。
分区数决定了消费的并行上限：一个分区同一时刻只被 group 内一个消费者消费。

Offset 与消费位移

消费者处理完消息后提交的位移称为 offset，Kafka 将其保存在内部 topic __consumer_offsets 中：

Producer -> [partition-0: 0,1,2,3 ...]
 ^
 | committed offset (group A)
Consumer group A 从 offset=4 继续拉取

位移提交方式影响可靠性：

自动提交：间隔提交，可能丢失（提交后未处理崩溃）或重复（处理中崩溃未提交）。
手动提交：处理成功后再提交，配合幂等可实现至少一次/精确一次。

Consumer Group 与 Rebalance

同一 group 内的消费者共同消费 topic 的全部分区，分区在成员间均衡分配。当成员加入/退出时触发 rebalance，重新分配分区。频繁 rebalance 会暂停消费，应控制 session.timeout 与 heartbeat.interval 并避免消费耗时过长。

Kafka 可靠性与精确一次

Tue, 25 Aug 2026 00:00:00 +0000

Kafka 的可靠性需要在 producer、broker、consumer 三端协同配置。下面从「不丢、不重、有序」三个目标展开。

Producer 端的可靠性

通过 acks 控制写入持久化级别：

acks=0：发完即认为成功，可能丢消息，吞吐最高。
acks=1：leader 写入即成功，leader 宕机可能丢。
acks=all：ISR 全部同步才成功，最安全，配合 min.insync.replicas 防单点。

开启重试（retries）可应对瞬时失败，但会带来重复：网络抖动导致 producer 未收到 ack 而重试，同一条消息被写两次。

幂等 Producer 与事务

Kafka 提供 幂等 producer（enable.idempotence=true），broker 用 producerId + 序列号 去重，保证单分区内不重不漏。需要跨分区、跨系统的原子写入时，使用事务（transactional.id）将多次 produce 与 offset 提交纳入一个事务：

producer.initTransactions();
producer.beginTransaction();
producer.send(record1);
producer.send(record2);
producer.commitTransaction(); // 要么都成功，要么都不可见

消费端去重与幂等

即使 producer 幂等，consumer 在 rebalance 或位移提交时机不当时仍可能重复消费。消费端应保证业务幂等：

用唯一键（订单号等）做去重表/唯一索引。
将「处理 + 提交位移」放在同一事务（如消费写 DB 同时记录 offset）。

分区顺序性

Kafka 只保证单分区内有序。需要全局顺序只能单分区（牺牲并行）；需要业务顺序则按 key（如用户 id）分区，使同一 key 落到同一分区，从而在该 key 维度保持顺序。精确一次（EOS）正是幂等 + 事务 + 消费幂等三者叠加的结果。

Kafka on 追风笔记