第1章 初识Kafka
依据O'Reilly与中文版第2版完整目录：从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象
第1章 初识Kafka
本课程对应Gwen Shapira、Todd Palino、Rajini Sivaram、Krit Petty著《Kafka权威指南》第2版，薛命灯译，人民邮电出版社2022年11月出版，318页，ISBN 9787115601421；英文第2版由O'Reilly于2021年出版。课程严格使用第2版14章与附录A、B的目录边界，不把第1版旧目录、后来Kafka版本的实现或厂商功能冒充原书内容。
本页对应一个正式单元，逐项覆盖25个目录节点。主问题是“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”，最终交付为需求到Kafka抽象映射、分区键样本、端到端消息轨迹与多集群边界表，由另一位工程师更换消息键、负载和故障点重放。
学习目标
- 能解释“第1章 初识Kafka”的25个目录节点，并绘制它们之间的数据面、控制面与持久化边界。
- 能比较正常、压力、再均衡、broker故障和跨网络故障轨迹，判断确认、偏移量、ISR和业务结果是否一致。
- 能设计并复现需求到Kafka抽象映射、分区键样本、端到端消息轨迹与多集群边界表，用分位延迟、吞吐、滞后、日志与消息ID对账支持结论。
- 能分析“把Kafka当成普通队列，只看能否发送与接收，忽略保留日志、分区顺序和消费者位置”为何失败，并写出停止、恢复、回退与责任交接条件。
从一条记录的生命周期开始
先预测：带键、值、标头和时间戳的记录进入生产者后落到哪个分区，何时组成批次，哪个broker确认，副本何时进入或离开ISR，消费者何时处理并提交下一偏移量。随后再预测broker重启、网络延迟、再均衡或事务中止时，最后可见记录和业务结果应是什么。观察结果之前必须留下预测。
Kafka的高吞吐来自顺序追加、批处理、压缩、页缓存和分区并行；可靠性来自复制、确认、幂等或事务与消费提交的组合。任何调参都可能同时改变延迟、吞吐、资源和交付语义，本页不接受只报告单一峰值。
核心词汇与版本边界
↡发布订阅是“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”中的第1个核心概念，定义必须同时给出状态、边界、失败语义和可观测证据、↡消息批次是“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”中的第2个核心概念，定义必须同时给出状态、边界、失败语义和可观测证据、↡主题分区是“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”中的第3个核心概念，定义必须同时给出状态、边界、失败语义和可观测证据、↡broker集群是“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”中的第4个核心概念，定义必须同时给出状态、边界、失败语义和可观测证据、↡数据生态系统是“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”中的第5个核心概念，定义必须同时给出状态、边界、失败语义和可观测证据 构成本页词汇。每个词都要回答：它属于客户端还是broker，作用于主题、分区、副本或消费者位置中的哪一层，何时创建与推进，超时、重试、故障或版本变化后留下什么证据。
原书目录逐节点重构
发布与订阅消息系统
目录节点 1/25。 “发布与订阅消息系统”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“本章输入与契约”进入“发布与订阅消息系统”，再到“如何开始”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
如何开始
目录节点 2/25。 “如何开始”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“发布与订阅消息系统”进入“如何开始”，再到“独立的队列系统”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
独立的队列系统
目录节点 3/25。 “独立的队列系统”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“如何开始”进入“独立的队列系统”，再到“Kafka登场”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
Kafka登场
目录节点 4/25。 “Kafka登场”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“独立的队列系统”进入“Kafka登场”，再到“消息和批次”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
消息和批次
目录节点 5/25。 “消息和批次”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“Kafka登场”进入“消息和批次”，再到“模式”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
模式
目录节点 6/25。 “模式”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“消息和批次”进入“模式”，再到“主题和分区”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
主题和分区
目录节点 7/25。 “主题和分区”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“模式”进入“主题和分区”，再到“生产者和消费者”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
生产者和消费者
目录节点 8/25。 “生产者和消费者”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“主题和分区”进入“生产者和消费者”，再到“broker和集群”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
broker和集群
目录节点 9/25。 “broker和集群”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“生产者和消费者”进入“broker和集群”，再到“多集群”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
多集群
目录节点 10/25。 “多集群”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“broker和集群”进入“多集群”，再到“为什么选择Kafka”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
为什么选择Kafka
目录节点 11/25。 “为什么选择Kafka”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“多集群”进入“为什么选择Kafka”，再到“多个生产者”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
多个生产者
目录节点 12/25。 “多个生产者”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“为什么选择Kafka”进入“多个生产者”，再到“多个消费者”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
多个消费者
目录节点 13/25。 “多个消费者”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“多个生产者”进入“多个消费者”，再到“基于磁盘的数据保留”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
基于磁盘的数据保留
目录节点 14/25。 “基于磁盘的数据保留”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“多个消费者”进入“基于磁盘的数据保留”，再到“伸缩性”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
伸缩性
目录节点 15/25。 “伸缩性”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“基于磁盘的数据保留”进入“伸缩性”，再到“高性能”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
高性能
目录节点 16/25。 “高性能”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“伸缩性”进入“高性能”，再到“平台特性”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
平台特性
目录节点 17/25。 “平台特性”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“高性能”进入“平台特性”，再到“数据生态系统”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
数据生态系统
目录节点 18/25。 “数据生态系统”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“平台特性”进入“数据生态系统”，再到“起源故事”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
起源故事
目录节点 19/25。 “起源故事”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“数据生态系统”进入“起源故事”，再到“LinkedIn的问题”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
LinkedIn的问题
目录节点 20/25。 “LinkedIn的问题”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“起源故事”进入“LinkedIn的问题”，再到“Kafka的诞生”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
Kafka的诞生
目录节点 21/25。 “Kafka的诞生”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“LinkedIn的问题”进入“Kafka的诞生”，再到“走向开源”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
走向开源
目录节点 22/25。 “走向开源”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“Kafka的诞生”进入“走向开源”，再到“商业化”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
商业化
目录节点 23/25。 “商业化”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“走向开源”进入“商业化”，再到“命名”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
命名
目录节点 24/25。 “命名”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“商业化”进入“命名”，再到“开始Kafka之旅”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
开始Kafka之旅
目录节点 25/25。 “开始Kafka之旅”服务于“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”。先说明它接收的状态、配置或记录，再画出跨客户端、broker、分区、副本、磁盘或外部系统的边界；结论必须能够从配置、指标、日志、偏移量和消息样本中复核。
机制轨迹从“命名”进入“开始Kafka之旅”，再到“本章输出与验收”。逐步记录请求所属线程或进程、读取与写入的状态、确认发生的位置、超时与重试分支，以及失败后由谁接管。尤其区分“请求已发出”“broker已确认”“消费者已处理”和“业务结果已对账”，这些不是同一个完成点。
实验固定主题、分区键、消息ID和负载，只改变acks、批次、消费者数量、故障时点或网络条件之一。比较吞吐、P95/P99、消费者滞后、ISR、磁盘和最终消息集合，用“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”判定；若证据冲突，回到本节点缩小故障窗口，不用平均值掩盖尾部与丢失。
机制模型：数据面、控制面与存储
数据面从生产者序列化开始，经分区器、记录累加器与网络请求进入分区首领；追随者拉取后，高水位限定消费者可见范围。消费端通过poll取得记录，处理完成点和提交偏移量必须分别标记。记录键决定分区时，调整分区数可能改变后续映射，因此顺序承诺必须写到契约中。
控制面管理集群成员、控制器、分区首领、ISR、配置、配额和消费者群组。控制器或群组协调器切换期间会存在旧纪元、重试与最终一致窗口；客户端不能把一次元数据响应当作永久真相。状态机图必须标出纪元或generation，防止旧成员继续提交。
存储面以分区日志片段、偏移索引和时间索引为核心。删除策略按保留窗口移除旧片段，压实策略保留每个键的最新值并处理删除标记；它们不等于数据库行更新。磁盘、页缓存、批次压缩和副本获取共同决定吞吐与恢复时间。
独立证据与生产交接
目录证据保存O'Reilly第2版目录、本页节点与页面标题映射；环境证据保存Kafka与Java版本、broker和客户端配置、主题分区副本状态；运行证据保存消息生成规则、分区键、负载、分位延迟、吞吐、滞后、ISR与磁盘；故障证据保存注入时点、最后确认偏移量、恢复动作和最终消息集合。
性能判断同时给出生产与消费侧背压。增大批次和压缩通常提高吞吐，却会增加等待、CPU或单批失败影响；增加分区提高并行度，也增加文件句柄、控制面与再均衡成本。所有对比固定消息大小、键分布、副本与确认语义。
恢复判断从业务对账结束。broker重新加入、ISR恢复、消费者继续poll、MirrorMaker继续复制或Streams任务重启都只是阶段；还需核对每个消息ID的出现次数、顺序约束、状态存储和外部结果，并确认旧成员或旧站点不再错误写入。
本章回顾
重新完成“从发布订阅需求推导消息、批次、模式、主题、分区、生产者、消费者、broker、集群和多集群的完整抽象”：先固定第2版目录与版本，再从拓扑和状态机推导配置，通过基线、压力与故障实验测量，最后交付需求到Kafka抽象映射、分区键样本、端到端消息轨迹与多集群边界表。只有“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”及反例都能被独立重放，本页才算完成。
复习与运行验收
练习
问题 1：为什么“第1章 初识Kafka”必须覆盖25个目录节点？
问题 2：本页最小不变量是什么？
问题 3：怎样构造最小反例？
问题 4：为什么不能用新版本功能替代第2版目录？
问题 5：如何验证性能结论？
问题 6：独立交接需要什么？
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 发布订阅
发布订阅在本页指向Kafka第2版中的具体状态、协议或操作边界；适用范围由“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”及故障反例共同限定。
- 消息批次
消息批次在本页指向Kafka第2版中的具体状态、协议或操作边界；适用范围由“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”及故障反例共同限定。
- 主题分区
主题分区在本页指向Kafka第2版中的具体状态、协议或操作边界；适用范围由“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”及故障反例共同限定。
- broker集群
broker集群在本页指向Kafka第2版中的具体状态、协议或操作边界；适用范围由“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”及故障反例共同限定。
- 数据生态系统
数据生态系统在本页指向Kafka第2版中的具体状态、协议或操作边界；适用范围由“同一分区内记录顺序和偏移量单调可解释，生产者与消费者通过持久日志解耦，扩容不会暗中改变键的顺序契约”及故障反例共同限定。