KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
Kafka 工程课：提交日志、副本与事务 — keel 龙骨
以本机三节点 KRaft 集群的真跑输出为主线把 Kafka 讲透：分区、段与稀疏索引，ISR 与 acks 的真实语义，副本选举与 unclean 取舍，生产者幂等与顺序保证，消费组再平衡的停顿量级，事务与 Exactly-Once，段滚动、retention 与积压容量估算。含两次失败注入的真实报错与三个 Windows 上的坑。
以本机三节点 KRaft 集群的真跑输出为主线把 Kafka 讲透：分区、段与稀疏索引，ISR 与 acks 的真实语义，副本选举与 unclean 取舍，生产者幂等与顺序保证，消费组再平衡的停顿量级，事务与 Exactly-Once，段滚动、retention 与积压容量估算。含两次失败注入的真实报错与三个 Windows 上的坑。
章节目录
- 00 · 提交日志不是队列 — 这一章纠正一个前提。你后面所有的判断——acks 该设几、分区该给几个、积压该不该慌——都建立在「Kafka 里一条消息被消费之后会发生什么」这个前提上。前提错了，后面全错。
- 01 · 存储模型 — 第 00 章说「消息不会被消费掉」，但它到底躺在哪、长什么样，决定了 Kafka 的性能边界：为什么顺序写能扛住百万级吞吐，为什么按 timestamp 查历史消息很贵，为什么一个分区就是一个 CPU 核。这一章把分区目录拆开看。
- 02 · 副本、ISR 与 leader 选举 — acks=all 是 Kafka 里被误解最多的一行配置。很多人把它读成「绝不丢」，然后在把一个 broker 停掉之后发现生产端写不进去，报错还不是他预期的那个。这一章把 ISR 这个中间概念拆开，并且用真实报错把「什么情况报什么错」钉死。
- 03 · 生产者的确认与顺序 — 生产端最容易被「配一个参数就以为解决了」的地方。acks 决定丢不丢，max.in.flight 和 retries 决定乱不乱，而幂等生产者只解决其中一部分。这一章把这三组参数的边界钉清楚，并且真的跑出一次乱序。
- 04 · 消费组与再平衡 — 消费组卡住的那几秒，是 Kafka 排障里最常被误判的地方。有人看到「消费停了 10 秒」就以为是下游慢，实际是重平衡；有人看到 lag 涨了就去加消费者，实际是分区不够。这一章把位点提交、心跳、再平衡拆开，并且把停顿时间量出来。
- 05 · 端到端可靠性 — 「先消费、再处理、再写下游、再提交位点」这四步里，只要第 4 步之前进程挂了，消息就会被处理两次。第 03 章的幂等生产者只覆盖了生产端一个会话，跨不过「消费 + 生产」这个组合。这一章讲 Kafka 用事务把两个写变成一件事。
- 06 · 容量、积压与运维 — 前面五章讲的是机制，这一章把这些机制收口成四件运维上真要做的判断：分区数怎么定、积压能不能追回来、盯哪些指标、什么时候该承认这台架构撑不住了。所有数字都来自本机实测。