集群架构

敖正炀
163 阅读4分钟

Kafka 集群架构是一个高度分布式的系统，设计目标是为大规模数据流处理提供高吞吐、低延迟、高可用性和持久化存储。

1. 核心组件

1.1 Broker（代理节点）

  • 角色：Kafka 集群由多个 Broker 组成，每个 Broker 是一个独立的 Kafka 服务器（进程），负责数据存储、消息读写和副本同步。

  • 功能：

    • 接收生产者（Producer）发送的消息并持久化到磁盘。
    • 处理消费者（Consumer）的拉取请求，返回消息。
    • 管理分区的副本同步（Leader/Follower 机制）。
    • 与其他 Broker 协作实现集群元数据同步。

1.2 Topic（主题）

  • 角色：逻辑上的数据分类单元，生产者向 Topic 发送消息，消费者从 Topic 订阅消息。

  • 分区（Partition） ：

    • 每个 Topic 被划分为多个分区，分区是数据存储和并行处理的基本单位。

    • 分区内的消息按顺序追加（不可变日志结构），通过 偏移量（Offset） 唯一标识每条消息的位置。

    • 分区的作用：

      • 水平扩展：允许 Topic 的数据分布在多个 Broker 上。
      • 并行消费：消费者组（Consumer Group）中不同消费者可同时消费不同分区。

1.3 Producer（生产者）

  • 角色：向 Kafka Topic 发送消息的客户端。

  • 关键机制：

    • 分区选择策略：通过轮询、哈希（Key-based）或自定义策略决定消息写入哪个分区。
    • 批量发送（Batching） ：合并多条消息后发送，减少网络开销。
    • 可靠性配置：通过 acks 参数控制消息持久化级别（0/1/all）。

1.4 Consumer（消费者）

  • 角色：从 Topic 订阅并消费消息的客户端。

  • 关键机制：

    • 消费者组（Consumer Group） ：多个消费者组成一个组，共同消费一个 Topic 的所有分区，实现负载均衡。
    • 位移（Offset）管理：记录消费者在每个分区的消费进度，支持自动提交（enable.auto.commit）或手动提交。
    • 重平衡（Rebalance） ：当消费者加入/离开组时，重新分配分区所有权。

1.5 ZooKeeper 或 KRaft（元数据管理）

  • ZooKeeper（旧版本） ：

    • 存储集群元数据（Broker 列表、Topic 配置、分区 Leader、ISR 等）。
    • 协调 Controller 选举和 Broker 心跳检测。

  • KRaft（Kafka 2.8+） ：

    • 通过内置的 Raft 协议实现元数据管理，替代 ZooKeeper。
    • 简化架构，提升元数据操作的性能和一致性。

1.6 Controller（控制器）

  • 角色：集群中唯一的 Controller Broker，负责核心管理任务。

  • 功能：

    • 分区 Leader 选举（例如 Leader 故障时重新选举）。
    • 监控 Broker 存活状态（通过 ZooKeeper 或 KRaft）。
    • 触发副本同步和分区重分配。

2. 集群架构图

+------------------------------------------------------------------+
|                          Kafka Cluster                           |
|  +-----------+     +-----------+     +-----------+     +--------+|
|  |  Broker1  |<--->|  Broker2  |<--->|  Broker3  |<--->| BrokerN||
|  +-----------+     +-----------+     +-----------+     +--------+|
|    |  Partition0    |  Partition1    |  Partition2    |          |
|    |  (Leader)      |  (Follower)    |  (Follower)    |          |
|    +----------------+----------------+----------------+          |
+------------------------------------------------------------------+
          ↑               ↑               ↑               ↑
          |               |               |               |
      +---+----+    +-----+----+    +-----+----+    +-----+----+
      |Producer|    |Consumer1 |    |Consumer2 |    |ConsumerN |
      +--------+    +----------+    +----------+    +----------+

3. 数据存储与副本机制

3.1 分区副本（Replica）

  • 每个分区有多个副本（由 replication.factor 配置），分布在不同的 Broker 上。

  • 副本角色：

    • Leader 副本：处理所有读写请求，保证数据一致性。
    • Follower 副本：异步从 Leader 拉取数据，作为备份。

3.2 ISR（In-Sync Replicas）

  • Leader 维护一个 ISR 列表，包含所有与 Leader 数据同步的副本。
  • 同步条件：Follower 需在 replica.lag.time.max.ms（默认 10 秒）内追上 Leader。
  • 数据提交：生产者配置 acks=all 时，需等待所有 ISR 副本确认写入。

3.3 日志存储（Log Segment）

  • 消息按顺序追加到分区的日志文件中，分为多个 Segment（默认 1GB）。
  • Segment 文件包括 .log（数据）和 .index（索引），支持快速查找。

4. 高可用性与容错

4.1 Leader 选举

  • Controller 监控 Broker 状态，若 Leader 副本宕机，从 ISR 中选举新 Leader。
  • Unclean Leader 选举：若 ISR 为空且允许非同步副本成为 Leader（unclean.leader.election.enable=true），可能丢失数据。

4.2 故障恢复

  • Broker 宕机：Controller 触发分区 Leader 重新选举，Follower 副本接管。
  • 数据恢复：Follower 副本从 Leader 拉取缺失数据，直至追上 ISR。

5. 集群扩展与负载均衡

  • 水平扩展：通过增加 Broker 提升集群吞吐量和存储容量。
  • 分区重分配：使用 kafka-reassign-partitions.sh 工具均衡分区分布。
  • 动态配置：支持在线修改 Topic 配置（如分区数、副本因子）。

6. ZooKeeper vs. KRaft 模式对比

特性ZooKeeper 模式KRaft 模式
元数据管理依赖外部 ZooKeeper 集群内置 Raft 协议，自管理元数据
运维复杂度需维护 ZooKeeper 集群无需外部依赖，架构更简单
性能ZooKeeper 可能成为瓶颈（高写入场景）元数据分片处理，性能更高
适用版本Kafka 2.8 之前版本Kafka 2.8+（生产推荐 3.0+）

7. 典型应用场景

  1. 日志聚合：收集分布式系统日志，供实时分析或离线处理。
  2. 事件驱动架构：解耦微服务，通过消息传递触发下游操作。
  3. 流处理：与 Kafka Streams、Flink 等框架集成，实现实时数据处理。
  4. 消息队列：替代传统 MQ（如 RabbitMQ），支持高吞吐场景。

总结

Kafka 集群通过分布式 Broker、分区副本、ISR 机制和 Controller 协调，实现了高吞吐、高可用和容错能力。随着 KRaft 模式的成熟，Kafka 正逐步简化架构，减少对外部组件的依赖。

avatar
文章
阅读
粉丝