KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
Kafka 工程课 · 课程导读 — keel 龙骨
Kafka 工程课：提交日志、副本与事务 的参考信息：Kafka 工程课 · 课程导读
你现在的起点
- 会写
producer.send()和consumer.poll()，能把 Kafka 跑起来； - 但把 Kafka 当「一个更快的队列」在用——以为消息被消费掉就没了，以为
acks=all等于「绝不丢」； - 出过或见过这几类问题：某个 key 的消息全挤在一个分区、消费组时不时卡几秒、某个 topic 写不进去但报错看不懂。
如果你符合上面这几条，这门课就是为你写的。
这门课和「消息队列选型」的分工
《可扩展性》05 章 · 消息队列 回答的是选型：什么时候该上 MQ、RabbitMQ 和 Kafka 各自适合什么。它的结论是「Kafka 适合日志流、可回放」这类判断。
这门课不做选型，只把 Kafka 自己讲透：一个 topic 在磁盘上长什么样、ISR 是谁在维护、acks 到底等谁、重平衡为什么停顿、事务的两个写怎么变成一个原子动作。先读选型那一章建立取舍框架，再来这里补机制；顺序反了容易把 Kafka 的机制当成所有 MQ 的通用机制。
一条能走通的学习路径
提交日志不是队列（先纠正「消费即删除」这个前提）
→ 存储模型（分区 / 段 / 稀疏索引 / 顺序写）
→ 副本、ISR 与 leader 选举（acks=all 到底保证什么）
→ 生产者的确认与顺序（acks 四档 + 幂等生产者）
→ 消费组与再平衡（分配、心跳、offset 提交三时机）
→ 端到端可靠性（at-least-once 到事务）
→ 容量、积压与运维（分区数怎么定、积压能不能追回来）
前五章是机制，第六章把这些机制收口成运维判断。
章节地图
| 章 | 关键问题 | 你会亲手验证什么 |
|---|---|---|
| 00 · 提交日志不是队列 | 同一批消息为什么能被多个消费组各消费一遍；offset 存在哪 | 两个新消费组从最早各读一遍同一 topic，读到相同条数；__consumer_offsets 是 compact 日志 |
| 01 · 存储模型 | 分区 / 段 / 稀疏索引各自的职责 | dumplog 看真实记录；量出稀疏索引间隔；对比活动段与滚动完段的索引文件大小 |
| 02 · 副本、ISR 与 leader 选举 | ISR 谁在维护；acks=all 保证什么、不保证什么 |
停 broker 复现 NotEnoughReplicasError；看 ISR 收缩/回填与 leader 切换 |
| 03 · 生产者的确认与顺序 | acks 四档语义；重试与乱序 | 幂等生产者 3000 条零乱序；对照 acks=1 + 重试跑出真实乱序 |
| 04 · 消费组与再平衡 | 分配策略、会话超时、重平衡为什么停顿 | 两成员分派与撤下；量出重平衡停顿毫秒数与死亡成员分区的空窗秒数 |
| 05 · 端到端可靠性 | 从 at-least-once 到事务 | init_transactions + send_offsets_to_transaction；对比 read_committed / read_uncommitted；日志里找控制批 |
| 06 · 容量、积压与运维 | 分区数怎么定；积压能不能追回来 | ProducerPerformance / ConsumerPerformance 实测吞吐与延迟；按净速度算积压追平时间 |
学完这门课你能做什么
- 拿到一个 Kafka 集群，能说清「消息存在哪、副本状态如何、消费到哪」，而不是只看一条
lag数字； - 能对 AI 或同事给出的 Kafka 方案做评审：分区数、
acks、min.insync.replicas、事务用法分别踩在哪； - 能解释
acks=all在生产事故里为什么仍然会「写不进去」，以及它不保证什么； - 积压时不先加消费者，而是先算「净速度能不能追平」。
前置要求
- 会基本的 Kafka 客户端 API 与命令行（或愿意照着章节里的命令跑）；
- 了解日志追加、顺序 IO、副本这些通用概念（不懂也行，第 01、02 章会从现场讲起）；
- 建议先读 《可扩展性》05 章 · 消息队列，建立「什么时候该用 MQ」的判断。