大数据-53 Kafka 架构精讲：Producer、Broker、Consumer 全流程解析

点一下关注吧！！！非常感谢！！持续更新！！！

🚀 AI篇持续更新中！（长期更新）

AI炼丹日志-30-新发布【1T 万亿】参数量大模型！Kimi‑K2开源大模型解读与实践，持续打造实用AI工具指南！📐🤖

💻 Java篇正式开启！（300篇）

目前2025年07月28日更新到： Java-83 深入浅出 MySQL 连接、线程、查询缓存与优化器详解 MyBatis 已完结，Spring 已完结，Nginx已完结，Tomcat已完结，分布式服务正在更新！深入浅出助你打牢基础！

📊 大数据板块已完成多项干货更新（300篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！ 大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT案例 详解

章节内容

上节我们完成的内容：

• 生产消费结构
• Kafka 基本概念介绍
• Kafka 消费模式
• Kafka 核心API 介绍
• Kafka 优势
• Kafka 基本架构

核心概念深入解析

架构设计与核心特性

Kafka 采用分布式发布-订阅消息系统的架构设计，主要包含以下核心特性：

1. 高吞吐量：单机可支持每秒数十万条消息的写入和读取
2. 低延迟：消息传输延迟可控制在毫秒级别
3. 水平扩展：通过增加节点可线性提升系统容量
4. 持久化存储：消息可配置保留策略，默认保留7天

关键组件详解

1. 分区(Partition)：

   • 每个主题(Topic)可划分为多个分区
   • 分区是Kafka并行处理的基本单位
   • 示例：一个名为"user_activity"的主题可划分为10个分区，提高并发处理能力

2. 复制(Replication)：

   • 每个分区可设置多个副本(通常为3个)
   • 包含1个Leader副本和多个Follower副本
   • 提供数据冗余和高可用性保障

3. 消费模型(Consumer Model)：

   • 支持消费者组(Consumer Group)模式
   • 每个分区只能被组内一个消费者消费
   • 支持多种消息投递语义：至少一次(At-least-once)、至多一次(At-most-once)、精确一次(Exactly-once)

典型应用场景

1. 实时数据流处理：

   • 构建实时分析管道
   • 实现流式ETL处理
   • 示例：电商平台实时用户行为分析

2. 日志聚合：

   • 集中收集分布式系统日志
   • 提供统一的日志存储和查询
   • 示例：微服务架构下的请求链路追踪

3. 事件溯源(Event Sourcing)：

   • 作为事件存储中心
   • 支持事件重放和系统状态重建
   • 示例：金融交易系统的审计追踪

扩展能力与可靠性

Kafka 通过以下机制保证系统的高可用性和扩展性：

• 自动故障转移：当Leader副本失效时，自动选举新的Leader
• 分区再平衡：自动调整分区在集群中的分布
• 消费者组协调：动态调整分区与消费者的分配关系

这些特性使得Kafka成为构建现代数据管道的理想选择，特别适合需要处理海量实时数据的场景。

基本工作流程

Kafka 的基本工作流程是一个分布式消息处理系统，其核心组件包括生产者(Producer)、Broker(消息代理)和消费者(Consumer)。整个流程可以详细描述如下：

1. 生产者发送消息

• 生产者应用通过 Kafka 客户端库连接到 Kafka 集群
• 生产者指定目标主题(Topic)发送消息
• 每条消息可以包含：
  • 消息键(Key)：可选字段，用于决定消息路由到哪个分区
  • 消息值(Value)：实际的消息内容
  • 时间戳：记录消息产生时间
• 生产者可以配置不同的确认机制(acks)：
  • acks=0：不等待确认
  • acks=1：等待leader确认
  • acks=all：等待所有副本确认

示例：一个电商系统可能将订单创建消息发送到"orders"主题，使用用户ID作为消息键，确保同一用户的消息进入同一分区。

2. Broker处理消息

• Broker接收到消息后执行以下操作：
  1. 根据分区策略决定目标分区：
     • 如果指定了消息键，使用哈希算法确定分区
     • 如果未指定键，采用轮询或粘性分区策略
  2. 将消息追加到分区日志文件末尾
  3. 根据配置的副本因子(replication factor)将消息复制到其他Broker
  4. 返回确认响应给生产者
• 消息以顺序追加方式写入，不可修改
• 分区日志按时间或大小策略进行清理

3. 消费者消费消息

• 消费者通过消费者组(Consumer Group)机制订阅主题
• 每个消费者组：
  • 可以包含多个消费者实例
  • 组内消费者均匀分配分区
• 消费过程：
  1. 消费者定期从分配的分区拉取消息
  2. 处理消息后提交偏移量(offset)
  3. 支持多种提交方式：
     • 自动提交
     • 手动同步提交
     • 手动异步提交
• 偏移量管理：
  • 存储在Kafka内部主题__consumer_offsets中
  • 支持重置偏移量以重新处理消息
  • 提供精确一次(exactly-once)语义支持

示例场景：一个支付处理系统可能有多个消费者实例组成消费者组，共同处理"payments"主题的消息，每个实例处理分配给它的分区中的消息，确保高效并行处理。

Producer

生产者创建消息。 该角色将消息发布到Kafka的Topic中，Broker接收到生产者的消息之后，Broker将消息追加到当前的 segment 文件中。 一般情况下，一个消息会被发布到一个特定的主题上：

• 默认情况下通过轮询把消息均衡的发布到主题的所有分区上
• 在某些情况下，生产者会把消息直接写到指定的分区，这通常是通过消息键和分区器来实现的，分区器为键的一个散列值，并将其映射到指定的分区上。这样可以保证同一个键的消息会被写到同一个分区上。
• 生产者也可以使用自定义分区器，根据不同的业务规则将消息映射到分区。

生产者是负责将数据发送到 Kafka 的组件。生产者可以是任何产生数据的应用程序，如日志记录系统、传感器、数据库变更日志等。Kafka 生产者以发布-订阅模式工作，将消息发送到一个或多个 Kafka 主题。

关键特性如下：

• 异步发送： 生产者可以以异步方式发送消息，允许继续处理其他任务而无需等待消息的发送结果。
• 分区策略： 生产者可以通过设置消息的键（Key）来控制消息的分区，这对于保证同一键的消息顺序处理非常重要。
• 确认机制（Acknowledgment）： 生产者可以设置不同的消息确认机制，如等待所有分区副本收到消息（acks=all）或只等待领导者副本确认（acks=1），以平衡性能和可靠性。

Consumer

消费者读取消息

• 消费者订阅一个或者多个主题，并按照消息生成顺序读取它们
• 消费者通过检查消息偏移量来区分已经读过的消息，偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在ZooKeeper或Kafka上。
• 消费者是消费组的一部分，群组保证每个分区只能被同一个消费者使用。
• 如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新消费。

消费者是从 Kafka 主题中读取消息的组件。消费者通常被组织在消费者组中，以便多个消费者可以协同处理来自同一主题的消息。每个消费者组内的消费者分摊处理不同的分区，从而提高了系统的吞吐量和可扩展性。

关键特性如下：

• 消费者组： 每个消费者组内的消费者从主题的不同分区中读取消息。同一分区的消息不会被同一消费者组内的多个消费者处理，但可以被-不同的消费者组处理。
• 手动或自动提交偏移量： 消费者可以手动或自动提交消息的偏移量（Offset），以确保在故障恢复时能够从正确的位置重新开始读取。

Broker

一个独立的Kafka服务器称为Broker

• 如果某Topic有N个Partition，集群有N个Broker，每个Broker存储该Topic的一个Partition
• 如果某Topic有N个Partition，集群有（N+M）个Broker，那么其中有N个Broker存储该Topic的一个Partition
• 如果某Topic有N个Partition，集群中Broker数目少于N个，那么一个Broker存储该Topic的一个或多个Partition。在实际的生产环境中，尽量避免这种情况的发生，这种情况很容易导致Kafka集群数据不平衡。

Broker 是 Kafka 集群中的一个实例，它负责接收生产者发送的消息，将其存储到磁盘，并为消费者提供数据。一个 Kafka 集群通常由多个 Broker 组成，每个 Broker 负责管理一部分分区。

关键特性如下：

• 分布式架构： 多个 Broker 共同工作以实现数据的存储和处理。Kafka 集群通过分区和复制来实现数据的高可用性和可靠性。
• Leader 和 Follower： 每个分区都有一个领导者（Leader）和多个跟随者（Follower）。生产者和消费者都与分区的领导者进行交互，而跟随者负责复制数据，以提供冗余。

Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。 物理上不同的Topic的消息分开存储 主题就好比数据库的表，尤其是分库分表之后的逻辑表。

主题是 Kafka 中用于存储和分类消息的逻辑通道。每个主题可以有多个分区，消息在分区内是有序的，但在不同的分区之间可能是无序的。

关键特性如下：

• 多订阅者支持： 多个消费者组可以同时订阅同一个主题，并且每个组都可以独立处理主题中的消息。
• 数据保留策略： 主题中的数据可以基于时间或大小来配置保留策略，Kafka 会自动删除旧的数据，以释放存储空间。

Partition

• 主题可以被分为若干个分区，一个分区就是一个提交日志
• 消息以追加的方式写入分区，然后以先入先出的顺序读取
• 无法在整个主题范围内保证消息的有序，但可以保证消息在单个分区内的顺序
• Kafka通过分区来实现数据冗余和伸缩性
• 在需要严格保证消息的顺序的场景下，需要将Partition数目设置为1

分区是主题的物理分片，每个分区在磁盘上存储一部分消息。分区允许 Kafka 将数据分散在集群中的多个 Broker 上，从而实现横向扩展。

关键特性如下：

• 顺序性保证： 在一个分区内，消息是有序的。这对于需要按顺序处理数据的应用场景非常重要。
• 并行处理： 不同分区的消息可以被不同的消费者并行处理，从而提高吞吐量。

Replicas

Kafka使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本，那些副本被保存在Broker上，每个Broker可以保存成百上千属于不同主题和分区的副本。 副本有以下的两种类型：

• 首领副本：每个分区都有一个首领副本，为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。
• 跟随者副本：首领以外的副本都是跟随副本，跟随者副本不处理来自客户端的请求，它们唯一的任务就是从首领那里复制消息，保持与首领一致的状态。如果首领发生奔溃，其中一个跟随者就会被提升为新首领。

Offset

生产者

消息写入的时候，每一个分区都有一个Offset，这个Offset就是生产者的Offset，同时也是这个分区的最新最大的Offset。 有些时候没有指定某一个分区的Offset，这个工作Kafka帮我们完成。

偏移量是 Kafka 中每条消息在分区内的唯一标识符。消费者通过维护偏移量来跟踪它们已经读取的消息位置。

关键特性如下：

• 持久化： 偏移量可以由 Kafka 自动管理，也可以由消费者手动提交到 Kafka，确保在故障恢复时能够从正确的位置继续处理。
• 按需读取： 消费者可以随时指定从某个偏移量开始读取数据，从而支持数据的回溯性处理。

消费者

这是某个分区的Offset情况，生产者写入的Offset是最新最大值12，当ConsumerA进行消费时，从0开始消费，一直消费到9，消费者的Offset就记录9，ConsumerB就记录在11。 等下一次消费的时候，他们可以选择从上一次消费的位置消费，也可以从头开始消费。

副本相关

副本类型

Kafka通过副本来保证高可用，副本分为：首领副本（Leader）和追随者副本（Follower）。

• Leader 副本：每个分区都有一个 Leader 副本。Leader 副本负责处理所有对该分区的读写请求。也就是说，当生产者（Producer）发送消息到 Kafka 时，这些消息首先被写入 Leader 副本；当消费者（Consumer）从 Kafka 读取消息时，它们从 Leader 副本中获取数据。
• Follower 副本：除了 Leader 副本外，分区还可以有一个或多个 Follower 副本。Follower 副本不处理读写请求，而是被动地从 Leader 副本复制数据，保持与 Leader 的数据一致性。如果 Leader 副本所在的 Broker 出现故障，Kafka 会从剩下的 Follower 副本中选择一个新的 Leader，继续处理请求。

工作机制

• 同步复制：Follower 副本会以同步的方式从 Leader 副本中拉取数据，确保所有副本数据一致。当数据被写入 Leader 副本时，Kafka 会等待至少一个 Follower 副本成功复制数据后，才确认写入操作完成。
• 副本分配：Kafka 在创建主题（Topic）时，可以配置分区的副本数量（replication factor）。副本分配策略会尽可能将副本分布在不同的 Broker 上，以减少单点故障的风险。

副本优势

• 高可用性：由于 Kafka 允许每个分区有多个副本，即使某个 Broker 失效，只要其他 Broker 上有有效的副本，Kafka 仍能继续提供服务。
• 容错性：Kafka 的副本机制能够有效防止数据丢失。在 Broker 失效时，可以快速切换 Leader 副本，确保数据的持续可用性。

副本管理

• ISR（In-Sync Replica）集合：这是一个关键的概念，指当前与 Leader 副本保持同步的所有副本的集合。如果某个 Follower 副本在特定时间内未能跟上 Leader 的步伐，它将被暂时从 ISR 集合中移除。
• Leader 选举：当现有的 Leader 副本失效时，Kafka 会从 ISR 集合中选择一个新的 Leader，确保服务的连续性。