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

🚀 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)：

2. 每个主题(Topic)可划分为多个分区

3. 分区是 Kafka 并行处理的基本单位

4. 示例：一个名为"user_activity"的主题可划分为 10 个分区，提高并发处理能力

5. 复制(Replication)：

6. 每个分区可设置多个副本(通常为 3 个)

7. 包含 1 个 Leader 副本和多个 Follower 副本

8. 提供数据冗余和高可用性保障

9. 消费模型(Consumer Model)：

10. 支持消费者组(Consumer Group)模式

11. 每个分区只能被组内一个消费者消费

12. 支持多种消息投递语义：至少一次(At-least-once)、至多一次(At-most-once)、精确一次(Exactly-once)

典型应用场景

1. 实时数据流处理：

2. 构建实时分析管道

3. 实现流式 ETL 处理

4. 示例：电商平台实时用户行为分析

5. 日志聚合：

6. 集中收集分布式系统日志

7. 提供统一的日志存储和查询

8. 示例：微服务架构下的请求链路追踪

9. 事件溯源(Event Sourcing)：

10. 作为事件存储中心

11. 支持事件重放和系统状态重建

12. 示例：金融交易系统的审计追踪

扩展能力与可靠性

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 接收到消息后执行以下操作：

• 根据分区策略决定目标分区：

• 如果指定了消息键，使用哈希算法确定分区

• 如果未指定键，采用轮询或粘性分区策略

• 将消息追加到分区日志文件末尾

• 根据配置的副本因子(replication factor)将消息复制到其他 Broker

• 返回确认响应给生产者

• 消息以顺序追加方式写入，不可修改

• 分区日志按时间或大小策略进行清理

3. 消费者消费消息

• 消费者通过消费者组(Consumer Group)机制订阅主题

• 每个消费者组：

• 可以包含多个消费者实例

• 组内消费者均匀分配分区

• 消费过程：

• 消费者定期从分配的分区拉取消息

• 处理消息后提交偏移量(offset)

• 支持多种提交方式：

• 自动提交

• 手动同步提交

• 手动异步提交

• 偏移量管理：

• 存储在 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，确保服务的连续性。