Kafka 的定位
Kafka 最初由 LinkedIn 开发，后捐给 Apache 基金会，现在被广泛视为 分布式消息引擎 + 流处理平台。
一句话定位：高吞吐、可持久化、分布式的发布‑订阅消息系统。
它主要解决三类问题：
历史版本对比
Kafka 正在经历一个重要的架构演进------逐步移除对 ZooKeeper 的依赖，转向自研的 KRaft (Kafka Raft) 模式。这不仅是安装方式的差异，更代表了Kafka未来的架构方向，理解这一点对你后续的学习和选型很有帮助。
为适应新版本的变化，本文以KRaft (Kafka Raft) 模式进行讲解。
基础入门
本文基于Kafka-3.8.0版本进行讲解
一、核心概念详解
1. 消息队列中的三个角色：生产者、消费者、Broker
（1）生产者（Producer）
负责创建消息并发送到 Kafka 集群。
可以指定消息发往哪个 Topic ，以及发送到哪个 Partition（分区）（例如按 key 哈希或轮询）。
发送时可选择确认机制（acks 参数）：等待 0 / 1 / all个副本确认（幂等性）。
生产者具有批量发送、压缩、重试等能力。
（2）消费者（Consumer）
负责从 Kafka 集群读取消息，订阅一个或多个主题，并拉取数据。
通过 offset（偏移量）记录自己消费到了哪条消息。可手动提交 offset，也支持自动提交。
多个消费者可以组成一个 Consumer Group 消费者组，共同分担一个主题的消息读取，实现负载均衡和水平扩展。
（3）Broker
一台 Kafka 服务器就是一个 Broker，可以保存多个 Topic 的不同分区。
它负责接收来自生产者的消息、分配偏移量、持久化存储消息，并响应消费者的拉取请求。
多个 Broker 组成 Kafka 集群，其中一个指定为 Controller（控制器），负责管理分区分配、副本故障转移等，以提高容量和可靠性。
三者协作流程：生产者 → 发送消息到 → Broker（主题/分区） → 消费者拉取消息。
2. 核心存储与分组：Topic、Partition、Consumer Group
（1）Topic（主题）
消息的逻辑分类容器，类似数据库中的"表"。
生产者将消息发往某个主题，消费者从订阅的主题中读取消息。
一个主题可以被切分成多个 Partition 分区 分布在不同的 Broker 上，实现并行读写。
（2）Partition（分区）
分区是物理上的存储单元（一个文件夹），每个主题被分成一个或多个分区。
不同 Partition 可以分布在不同的 Broker 上，实现并行写入（Producer 可同时向多个 Partition 发消息）。
写入消息时，若未指定 KEY 分区键 ，默认采用轮询方式将消息均衡写入各分区。
消息在分区内有序，但不同分区之间不保证全局顺序。
每个分区可以有多个 Replica 副本（见后文 Replica）。
（3）Consumer Group（消费者组）
一个 Consumer Group 包含多个消费者 Consumer 实例（可以跨机器）。
一组共同消费一个或多个主题的消费者。
组内消费者负责一或多个分区，且一个分区只能被同组内的一个消费者消费（避免重复处理）。
如果消费者数量超过分区数，多出的消费者将闲置（不工作）。
不同消费者组之间互不影响，各自独立消费同一主题的全部消息。
注 ：Kafka 中的"发布/订阅"是指多个消费组 之间的关系，而点对点是针对同一个消费组内而言的。所以 Kafka 能同时支持两种模型，全靠 Consumer Group 这个抽象。
3. 关键标识：Offset、Replica、Leader/Follower、ISR
（1）Offset（偏移量）
分区内消息的唯一序号，从0开始递增/追加（append‑only）。
Offset 由 Broker 端维护（消息写入后生成），标识每条消息在该分区中的位置。
消费者通过提交 offset 来记录已经处理到哪条消息，从而实现断点续传。
消费者只能按 offset 递增顺序消费（不能跳过，但可以重置到更早的 offset）。
消费者可以手动或自动提交 offset，存储在 Kafka 内部主题 __consumer_offsets 中。
（2）Replica（副本）
每个 Partition 分区可以有多个副本（包括一个 Leader 副本和若干个 Follower副本）。
所有副本都保存相同的消息数据（异步同步）。
副本机制保证高可用--当 Leader 所在的 Broker 宕机时，Follower 可以接替成为新 Leader。
副本数不宜过多（通常 2~3 个），因为会增加网络和磁盘开销。
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 以 副本因子=3 为例： Topic 的1个 Partition 会有 1 个 Leader + 2 个 Follower。 写流程：Producer 向 Leader 发送消息；Leader 写入本地日志后，Follower 发送 Fetch 请求同步数据。 读流程：Consumer 只从 Leader 拉取消息（默认），保证数据一致性。 故障转移：如果 Leader 挂掉，Controller 会从 ISR 中选出新的 Leader。 ISR 动态维护：如果一个 Follower 落后太多（比如超过 replica.lag.time.max.ms），会被踢出 ISR；赶上了再重新加入。 |
（3）Leader / Follower
每个 Partition 分区可以有多个副本（包括一个 Leader 副本和若干个 Follower副本）。
Leader 副本 负责处理该分区的所有读写请求（生产者、消费者都只访问 Leader）。
其余 Follower 副本 只被动地从 Leader 同步数据，不对外提供服务。
当 Leader 失效，会从 **ISR（同步副本列表）**中选举出一个 Follower 成为新 Leader。
这种设计简化了分布式协调（只有 Leader 负责读写），同时保证了数据一致性。
（4）ISR
与 Leader 保持同步的副本集合，只有 ISR 中的 Follower 才能被选为新的 Leader。
如果一个 Follower 落后太多（比如超过 replica.lag.time.max.ms），会被踢出 ISR；赶上了再重新加入。
一句话总结：Topic 是逻辑容器，Partition 是物理单元；Offset 是消息在分区内的序号；Replica 是分区的冗余备份，Leader 负责读写，Follower 负责同步。
4.存储结构：Segment 文件（段存储）
虽然我们通常说 "消息存在 Partition 里" ，但 Partition 在磁盘上又被拆分成多个 Segment（段），避免单个文件过大。
每个 Partition 对应一个文件夹，命名规则：topic名称-分区编号，例如 my_topic-0。
文件夹内包含一组 Segment，每个 Segment 由三个文件组成：
Segment 的切分条件（满足其一即滚动到新 Segment）：
-
当前
.log文件大小达到segment.bytes（默认 1GB）。 -
当前 Segment 非活动时间达到
segment.ms（默认 7 天）。
为什么要用 Segment？
-
方便删除老数据：直接删除整个 Segment 文件夹，避免在超大文件中做删除操作。
-
加速查询：通过
.index二分查找，快速定位 offset 对应的物理位置。
5.消息模型
传统消息队列有两种常见模型：
（1）点对点（Point‑to‑Point）
-
一条消息只能被一个消费者消费，消费后消息被删除（或标记为已消费）。
-
典型应用：任务队列（如 RabbitMQ 的 Queue）。
-
Kafka 如何实现？让所有属于同一个 Consumer Group 的消费者读取同一个 Topic，则每条消息只会被该组内的一个 Consumer 处理 → 点对点模式。
（2）发布/订阅（Publish‑Subscribe）
-
一条消息可以被多个独立的消费者消费，就像广播。
-
典型应用：新闻订阅、事件通知。
-
Kafka 如何实现？让不同 Consumer Group 消费同一个 Topic，每个 Group 都会收到完整的消息 → 发布/订阅模式。