Kafka 核心术语详解

1. 集群架构层

Cluster（集群）

Kafka 集群由多个 Broker 组成的分布式系统，提供高可用性和水平扩展能力。

Broker（代理服务器）

Broker 是 Kafka 集群中的服务器节点，负责存储数据和处理客户端请求。每个 Broker 都有唯一的 ID，一个 Kafka 集群由多个 Broker 组成。

2. 存储架构层

Topic（主题）

Topic 是消息的逻辑分类，每个主题可以配置 M 个分区（Partition），每个分区可以配置 N 个副本（Replica）。

Partition（分区）

分区是主题的物理分割单元，每个分区的 N 个副本中只能有一个 Leader，由这个 Leader 对外提供服务（Kafka 团队正在使 Kafka 支持 Closest 副本读，而不是只有 Leader 支持读写），其他副本（Follower）从 Leader 同步数据，提供数据冗余。

Message（消息）

分区中包含若干消息，每条消息的位移（Offset）从 0 开始，依次递增。

3. 副本机制

Leader/Follower

• Leader：每个分区的主副本，负责处理所有的读写请求
• Follower：从副本，从 Leader 同步数据，提供数据冗余

ISR (In-Sync Replicas)

同步副本集合，包含与 Leader 副本保持同步的所有副本（包括 Leader 自身）。

副本加入 ISR 的条件

1. 时间同步要求：Follower 副本的数据延迟时间不能超过 replica.lag.time.max.ms（默认 10 秒）
2. 连接状态要求：
   • 在 ZooKeeper 管理的集群中：副本所在的 Broker 必须与 ZooKeeper 保持心跳连接
   • 在 KRaft 模式集群中：副本所在的 Broker 必须与 Controller 保持心跳连接
3. 活跃同步：Follower 必须持续向 Leader 发送 Fetch 请求来同步数据

副本被移出 ISR 的条件

1. 同步延迟过大：Follower 数据落后超过 replica.lag.time.max.ms 时间阈值
2. 节点失联：Broker 与集群失去连接（心跳超时）
3. 同步异常：副本在数据同步过程中出现错误

Leader 选举机制

标准情况下：只有 ISR 中的副本才有资格被选举为新的 Leader，这确保了新 Leader 拥有最新的已提交数据，避免数据丢失。

特殊情况：当 unclean.leader.election.enable=true 时，如果所有 ISR 副本都不可用，Kafka 允许从非 ISR 副本中选举 Leader。但这会有数据丢失风险，因为非 ISR 副本可能缺少部分已提交的消息。

ISR 维护机制

ISR 列表的维护涉及多个组件，并且在不同版本的 Kafka 中有重要变化：

监控和判断：

• 由 Leader 副本负责监控 Follower 的同步状态
• Leader 根据 Follower 发送的 Fetch 请求来追踪同步情况

状态更新和持久化：

• Kafka 2.7 之前：Leader 直接更新 ZooKeeper 中的状态节点 /brokers/topics/[topic]/partitions/[partitionId]/state
• Kafka 2.7 及之后：根据 KIP-497，Leader 发送 AlterISR 请求给 Controller，由 Controller 负责 ISR 状态的变更和持久化

Controller 的作用：

• 接收和处理 Leader 发送的 AlterISR 请求
• 验证 ISR 变更的合法性（如检查 Broker 是否在线）
• 持久化 ISR 变更到集群元数据存储
• 向相关 Broker 发送 LeaderAndIsr 请求同步最新状态

实时监控：可通过 JMX 指标实时监控 ISR 状态变化

4. 客户端

Producer（生产者）

Producer 是向 Kafka 主题发送消息的客户端应用程序。Producer 负责选择将消息发送到主题的哪个分区。

Consumer（消费者）

Consumer 是从 Kafka 主题读取消息的客户端应用程序。消费者可以是一个进程，也可以是一个线程。

Consumer Group（消费者组）

消费者组是由多个消费者实例组成一个组来消费一组主题。这组主题中的每个分区只能被这个消费者组中的一个消费者消费，不能被同一个消费者组中的多个消费者消费。这种机制提升了消费端吞吐量（TPS）。

Group Coordinator（消费者组协调器）

负责管理消费者组的 Broker，处理消费者的加入、离开以及重平衡协调。

5. 位移与消费

Offset（位移）

• 分区位移：消息在分区中的位置，消息写入时，这个消息的位置就不变了
• 消费者位移：消费者的消费进度，时刻变化

High Watermark (HW)（高水位线）

高水位线是 Kafka 保证数据一致性的核心机制，表示已经被所有 ISR 副本同步的最大消息位移。

基本概念

• 定义：分区中已经被所有 ISR 副本复制的最后一条消息的位移
• 作用：确保消费者只能读取到已经完全复制的消息，避免数据不一致

HW 与 LEO 的关系

• LEO (Log End Offset)：日志结束偏移量，每个副本最后一条消息的位移
• 关系：HW ≤ min(所有 ISR 副本的 LEO)

HW 更新机制

Leader 的 HW 更新：

1. Leader 接收 Follower 的 Fetch 请求，获知各 Follower 的 LEO
2. 计算所有 ISR 副本的最小 LEO 值
3. 将 HW 更新为这个最小值

Follower 的 HW 更新：

1. Follower 向 Leader 发送 Fetch 请求
2. Leader 在 Fetch 响应中包含当前的 HW 值
3. Follower 更新自己的 HW（通常略滞后于 Leader）

数据可见性规则

• 消费者：只能读取 HW 之前的消息，保证读到的都是已提交的数据
• 生产者：根据 acks 配置决定等待策略
  • acks=1：Leader 写入即返回，不等待 HW 更新
  • acks=all：等待所有 ISR 副本确认后返回

故障恢复中的 HW

当 Leader 故障时：

1. 新 Leader 选举完成后，可能会回退 HW（因为 HW 同步存在延迟）
2. Follower 截断高于新 Leader HW 的部分日志
3. 确保所有副本的数据一致性

配置参数

• replica.lag.time.max.ms：影响 ISR 成员资格，间接影响 HW 计算
• min.insync.replicas：影响数据提交的安全性要求

Commit（位移提交）

消费者将其消费进度（位移）保存到 Kafka 内部主题 __consumer_offsets 的操作。

6. 数据持久化

Log（日志）

Kafka 使用消息日志来保存数据，一个日志就是磁盘上一个只能追加写（append-only）消息的物理文件。由于只能追加写，因此避免了缓慢的随机 I/O 操作，改为性能较好的顺序 I/O 写操作，这也是实现 Kafka 高吞吐量的一个重要手段。

Log Segment（日志段）

在 Kafka 底层，一个日志又进一步细分成多个日志段，消息追加到最新的日志段中。当一个日志段写满后，Kafka 会自动切分出一个新的日志段，并封存老的日志段。同时，Kafka 会定时检查旧的日志段是否可以被删除，从而实现定期磁盘空间回收的目的。

7. 运维概念

Rebalance（重平衡）

重平衡是指在以下情况发生时，消费者组内的消费者实例自动重新分配订阅主题分区的过程：

• 消费者组内某个消费者实例挂掉
• 新的消费者加入消费者组
• 分区数量发生变化
• 主题数量发生变化

分区分配策略

• Range：按主题逐个分配分区范围
• RoundRobin：轮询分配所有主题的分区
• Sticky：尽可能保持原有分配，减少重平衡开销