Kafka笔记

Kafka
中间件
发布日期:   2024-09-08
更新日期:   2025-08-03
文章字数:   11.5k
阅读时长:   41 分
阅读次数:  

Kafka 复习

什么是Kafka

Apache Kafka是一个高性能的分布式流处理平台，最初由LinkedIn公司内部开发用于处理大规模实时数据流，后来于2011年成为Apache基金会的开源项目。它作为一个强大的消息中间件，专门设计用于处理高容量、低延迟的实时数据流处理场景。Kafka架构优雅且可扩展，能够无缝地处理数百万条消息，同时保持毫秒级的传输延迟。它具有分布式、可分区、可复制的特性，不仅提供了极高的吞吐量和可靠性，还支持数据持久化和容错能力，使其成为现代数据管道和流处理应用的基础组件。

Kafka的核心概念

  • Producer（生产者）：发布消息到Kafka的客户端应用程序
  • Consumer（消费者）：订阅并处理来自Kafka的消息流的客户端应用程序
  • Topic（主题）：Topic 是 Kafka 中对消息进行逻辑分类的单元。所有发布到 Kafka 集群的消息都必须归属于某一个 Topic。
  • Partition（分区）：每个topic可以分为多个分区，允许并行处理，提高吞吐量
  • Broker（代理）：一个独立的 Kafka 服务器实例被称为一个 Broker。多个 Broker 组合在一起构成一个 Kafka 集群。
  • Consumer Group（消费者组）：一组协同工作的消费者，共同消费主题中的消息
  • Offset（偏移量）：分区内每条消息的唯一标识符
  • Zookeeper：管理和协调Kafka broker的服务

Kafka的特点

  • 高吞吐量：能够处理数百万条消息
  • 低延迟：消息传递的延迟可以控制在毫秒级
  • 可扩展性：可以无缝扩展为处理更多数据
  • 持久性：消息被持久化到磁盘，防止数据丢失
  • 容错性：在节点失败的情况下继续运行
  • 高并发：支持数千个客户端同时读写
  • 实时处理：能够实时处理流数据

Kafka的应用场景

  • 消息队列：作为传统消息中间件的替代
  • 日志收集：收集分布式系统中的日志
  • 流处理：实时处理数据流
  • 事件溯源：记录状态变更事件
  • 活动跟踪：跟踪用户行为和活动
  • 指标监控：收集和监控运营数据

一个服务器只能有一个 Broker 吗？

这是一个关于“理论”与“最佳实践”的问题。

  • 从理论上讲：不是。
    你完全可以在一台物理或虚拟服务器上，启动多个不同的 Broker 进程。只要你为每个 Broker 进程配置不同的端口号（例如 9092, 9093, 9094）、不同的 broker.id 和不同的数据存储目录，它们就可以在同一台机器上共存。
  • 从生产实践上讲：是的，最佳实践是一台服务器只运行一个 Broker 实例。
    为什么呢？
    1. 资源隔离： Kafka 是一个重度依赖磁盘 I/O 和内存的系统。将一个服务器的全部资源（CPU、内存、磁盘、网络带宽）都分配给一个 Broker 实例，可以避免多个 Broker 实例之间争抢资源，从而获得最稳定和可预测的性能。
    2. 简化运维： 一台服务器对应一个 Broker，使得监控、管理和故障排查都变得非常简单明了。如果一台服务器上的某个 Broker 出了问题，你立刻就能定位到是哪台机器。
    3. 故障隔离： 如果一台服务器因为硬件故障宕机了，你只会损失一个 Broker。如果你在一台服务器上运行了三个 Broker，那一次宕机就会同时损失三个 Broker，对集群的冲击更大。

小结：在生产环境中，标准的最佳实践是一台服务器只部署和运行一个 Broker 实例，以确保资源隔离和简化运维。虽然技术上可以在一台服务器上运行多个 Broker，但这是一种不被推荐的做法。

Topic 只能存在于多 Broker 组合中的其中一个是吗？

  • **准确地说：一个 Topic 的数据，不仅可以，而且通常就应该分布在集群中的多个 Broker 上。**这是通过 Topic 的 分区（Partition）机制 来实现的，这也是 Kafka 得以实现高吞吐量的关键。

我们用一个具体的例子来说明：
假设你有一个由 3 个 Broker 组成的 Kafka 集群（Broker 1, Broker 2, Broker 3）。

现在，你创建了一个名为 order-topic 的主题，并设定它有 3 个分区（我们称之为 P0, P1, P2）。

Kafka 在创建这个 Topic 时，会自动将这些分区尽可能均匀地分布到集群的所有 Broker 上，以实现负载均衡。一个可能的结果是：

  • order-topic 的分区 P0 被存放在 Broker 1 上。
  • order-topic 的分区 P1 被存放在 Broker 2 上。
  • order-topic 的分区 P2 被存放在 Broker 3 上。

这样做的好处是：
当生产者往 order-topic 发送大量消息时，这些消息可以被同时发往三个不同的分区（P0, P1, P2），也就是同时写入了三台不同的服务器（Broker 1, 2, 3）。消费者也可以同时从这三个分区读取数据。这样一来，读写的压力就被分摊到了整个集群，而不是集中在一台机器上，从而极大地提升了性能。

所以，Topic 是一个逻辑概念，它的物理存储（即它的所有分区）是分散在整个集群的多个 Broker 上的。

一个生产Broker的最佳实践是一个Partition吗？

先说结论：一个 Broker 只承载一个 Partition”在生产环境中是不现实且低效的。

正确的生产实践恰恰相反：一个 Broker 通常会、也应该会承载成百上千个分区。

为什么会是这样？

  1. 资源利用率问题：
    一个分区（本质上就是磁盘上的几个日志文件）远不足以利用满一台现代服务器的强大资源（多核CPU、几十G内存、高吞吐磁盘阵列、万兆网卡）。如果一台强大的服务器（Broker）只为一个分区服务，那将是极大的资源浪费，就像用一辆大卡车只运送一封信。
  2. 成本和可扩展性问题：
    为了获得高吞吐量，一个 Topic 可能需要几十甚至几百个分区。如果一个 Broker 只能放一个分区，那么一个拥有 100 个分区的 Topic 就需要 100 个 Broker，也就是 100 台服务器！这在成本和运维上都是不可行的。
    而现实中，我们可以用一个 10 台 Broker 的集群，轻松承载起成百上千个分区（这些分区可以来自不同的 Topic）。

重新理解“方便管理”和“故障隔离”

  • 方便管理和定位问题： 这正是“一台服务器一个Broker”这个原则解决的。如果监控系统显示 Broker 5 的CPU使用率100%，你不需要思考是哪个进程导致的，直接登录到承载 Broker 5 的那台服务器去排查问题即可。
  • 故障隔离： 这不是通过减少 Broker 上的分区数来实现的，而是通过我们之前深入讨论的副本机制 (Replication) 来实现的。
    • 假设一个 Broker 上承载了 100 个分区的 Leader。当这台 Broker 宕机时，Kafka 的高可用机制会启动，将这 100 个 Leader 的角色自动、快速地转移到它们各自的副本（Follower）所在的、其他健康的 Broker 上。
    • 系统虽然会经历一次短暂的“重平衡”抖动，但数据不会丢失，服务也会迅速恢复。这才是 Kafka 在分区层面实现故障隔离的方式。

结论

所以，我们需要建立一个清晰的、分层的生产架构认知：

  1. 物理层： 一台服务器 → 运行一个 Broker 进程。（为了资源隔离和管理）
  2. 逻辑层： 一个 Broker → 同时管理多个分区。（为了资源利用率和成本效益）
  3. 高可用层： 一个分区的多个副本（Leader 和 Followers）→ 必须分布在不同的 Broker 上。（为了故障转移和数据安全）

分区 (Partition) - Kafka 高性能的基石

1. 技术定义

每个 Topic 都可以被划分为一个或多个分区（Partition），分区（Partition）是一个逻辑概念，它的物理存在形式是副本（Replica），而每一个副本的本质，就是一个有序的、只能追加写入的日志文件（Append-only Log）。

当声称在要将消息写入 分区0 时，Kafka 内部会把它翻译成：“找到 分区0 的 Leader 副本，然后把消息追加到那个副本对应的日志文件的末尾

2. 分区的核心特性

  • 有序性 (Ordering): 在单个 Partition 内部，消息是严格按照其被写入的顺序进行存储和读取的。这意味着，如果你发送消息 M1，然后发送 M2 到同一个 Partition，那么消费者也一定会先读到 M1，再读到 M2。这是 Kafka 提供的最重要的顺序保证。
  • 不可变性 (Immutability): 一旦消息被写入 Partition，它就不能被修改。这种设计简化了系统，并提高了性能。
  • 偏移量 (Offset): Partition 中的每一条消息都有一个唯一的、从 0 开始单调递增的序列号，这个序列号被称为 Offset。Offset 唯一地标识了 Partition 中的一条消息。消费者通过 Offset 来追踪自己消费到了哪个位置。

3. 为什么要设计分区？

设计分区的核心目的有两个：

  • 可伸缩性/水平扩展 (Scalability)：
    • 存储层面： 一个 Topic 的数据可以被分散存储在集群的多个 Broker 上（如我们上一步所讨论的）。这打破了单台服务器的磁盘容量和 I/O 性能的限制。如果数据量增长，你可以通过增加 Broker 节点来水平扩展整个集群的存储能力。
    • 性能层面： 读写操作可以并行地在多个 Broker 上的多个 Partition 上进行，极大地提高了整个 Topic 的总吞吐量。
  • 并行处理 (Parallelism)：
    • 分区的存在，使得消费者可以实现并行消费。一个消费者组（Consumer Group）可以有多个消费者实例，每个实例负责消费一个或多个 Partition。这样，一个 Topic 的总消费负载就被分摊到了多个消费者上，大大提高了数据处理能力。

总结一下第三步的关键点：

Topic 是一个逻辑概念，而 Partition 是物理上的实现。一个 Topic 由多个 Partition 组成，这些 Partition 分布在不同的 Broker 上。消息在单个 Partition 内是有序的，并通过 Offset 进行唯一标识。分区的设计是 Kafka 实现高吞吐量和高可伸缩性的核心原因。

副本 (Replika) 与 Leader/Follower 模型 - Kafka 可靠性的保障

1. 技术定义

  • 副本 (Replica): Kafka 允许为每个分区（Partition）创建多个数据副本，这些副本被分布在集群中不同的 Broker 上。这就是副本机制。副本的数量是可以配置的，这个数量被称为副本因子 (Replication Factor)。例如，如果副本因子为 3，那么每个分区就会有 1 个主副本和 2 个次副本。

2. Leader 与 Follower 的角色分工

一个分区的多个副本之间，并不是平等的，它们有明确的主从关系。

  • Leader (领导者 / 主副本)：
    • 职责： 每个分区在任意时刻，有且仅有一个副本是 Leader。它负责处理所有来自客户端（生产者和消费者）的读和写请求。
    • 类比： 它是唯一对外营业的“正本”柜台。
  • Follower (跟随者 / 次副本)：
    • 职责： Leader 以外的其他副本都是 Follower。Follower 不与客户端直接交互。它们唯一的任务就是被动地、持续地从 Leader 那里拉取最新的数据，以保持和 Leader 的数据同步。
    • 类比： 它们是内部使用的“备份”柜台，只负责抄写正本柜台的数据，不对外服务。

3. 数据同步与故障转移的流程

这个主从模型是如何工作的？

  • 数据写入流程 (正常情况):
    1. 生产者发送一条消息到某个分区。
    2. 请求被直接发送到该分区的 Leader 所在的 Broker 上。
    3. Leader 将消息写入自己的本地日志。
    4. 各个 Follower 定期向 Leader 发送拉取请求，将 Leader 的新消息复制到自己的本地日志中。
  • 故障转移流程 (Leader 宕机):
    1. 分区的 Leader 所在的 Broker 突然宕机。
    2. Kafka 控制器 (Controller) 检测到这个情况。
    3. 控制器会从所有与 Leader 保持“同步”的 Follower 列表中，选举出一个新的 Leader。
    4. 选举成功后，这个曾经的 Follower 就成为了新的 Leader，开始对外提供读写服务。客户端会被告知新的 Leader 地址。整个过程对用户来说是无感知的，是自动完成的。

现在，我们用一个非常具体、直观的例子来说明这个过程。

场景设定：

  • 集群： 我们有一个由 3 台服务器组成的 Kafka 集群，分别是 Broker 1、Broker 2 和 Broker 3。
  • Topic： 我们创建一个名为 payment_topic 的主题，用来处理支付消息。
  • 分区和副本： 为了让例子简单清晰，我们假设 payment_topic 只有 1 个分区，就是 Partition 0。我们设置副本因子为 3，这意味着 Partition 0 会有 1 个 Leader 和 2 个 Follower。

阶段一：正常运行

系统启动后，Kafka 会自动进行选举和分配。一个可能的结果是：

  • Partition 0 的 Leader 被分配在了 Broker 1 上。
  • Partition 0 的两个 Follower 分别被分配在了 Broker 2 和 Broker 3 上。

现在，一个生产者要发送一条支付消息：{ "paymentId": "abcde", "amount": 50 }

  1. 生产者的请求被直接发送到 Broker 1（因为它是 Leader）。
  2. Broker 1 收到消息，将它写入自己的磁盘。
  3. Broker 2 和 Broker 3 上的 Follower，像往常一样，从 Broker 1 拉取数据，发现有一条新消息，于是也把这条消息写入各自的磁盘。
  4. 当数据成功同步到足够数量的副本后（这个数量可以配置），Broker 1 向生产者返回一个“发送成功”的确认。

在这个阶段，所有读写都由 Broker 1 处理，Broker 2 和 3 只是默默地在后台备份。

阶段二：故障发生

突然，Broker 1 所在的服务器因为电源故障，宕机了！

现在的情况是：

  • Partition 0 的 Leader 消失了。
  • 生产者和消费者无法再连接到 Broker 1。

阶段三：自动故障转移 (Failover)

Kafka 的高可用机制现在开始启动：

  1. 集群的控制器 (Controller)（通常是集群中的某一个 Broker）通过心跳机制，很快就发现 Broker 1 失联了。
  2. 控制器立刻查看 Partition 0 的 Follower 列表，发现 Broker 2 和 Broker 3 上的副本都处于“同步”状态。
  3. 控制器在这两个 Follower 中发起一次新的选举。假设选举结果是 Broker 2 胜出。
  4. 控制器发布命令：“从现在起，Broker 2 成为 Partition 0 的新 Leader！”
  5. Broker 2 的角色从 Follower 转变为 Leader。Broker 3 保持 Follower 不变，但它现在开始从新的 Leader（Broker 2）那里同步数据。
  6. Kafka 会通知生产者客户端：“payment_topic 的 Partition 0 的 Leader 地址已经变更为 Broker 2。”

结果：

  • 现在，当生产者要发送下一条消息 { "paymentId": "fghij", "amount": 80 } 时，它会直接将请求发送到 Broker 2。
  • 整个系统恢复了正常读写，整个切换过程是自动的，通常在几秒钟内完成，保证了服务的连续性。

Kafka 实现高并发的四大核心支柱

磁盘的高效利用

  • 顺序读写：传统数据库为了更新数据，需要进行大量的随机磁盘读写，这非常慢，因为磁头需要不停地移动寻道。而 Kafka 的设计是日志追加 (Append-only Log)，所有新消息都只是简单地追加到文件的末尾。这种顺序写入的方式，速度几乎和写内存一样快，因为它省去了代价高昂的磁头寻道时间。
  • 操作系统页缓存的利用：Kafka 并不自己去设计复杂的缓存机制，而是把这个工作巧妙地“甩锅”给了操作系统。数据写入磁盘时，实际上是先写入了操作系统的页缓存（Page Cache），这是一个位于内存中的高速缓存区，然后由操作系统在后台异步地将数据刷到磁盘上。读取数据时，如果数据恰好在 Page Cache 中（对于热门数据很常见），就可以直接从内存中读取，避免了磁盘I/O。

I/O优化：减少一切不必要的操作

  • 零拷贝（Zero-Copy）：
    • 在传统的数据发送流程中，数据需要从磁盘拷贝到内核空间（页缓存），再从内核空间拷贝到用户应用程序空间，然后应用程序再把数据拷贝回内核的 Socket 缓存区，最后才发送到网卡。这个过程涉及到多次数据拷贝和CPU上下文切换。
    • 而Kafka使用了零拷贝技术，允许数据直接从内核空间的页缓存，发送到网卡，全程不经过用户应用程序。这极大地减少了数据拷贝次数和CPU开销，是Kafka实现超高数据发送性能的秘密武器之一。
  • 批处理（Batching）：它体现在生产者和消费者两端。
    • 生产者侧： 生产者不会来一条消息就立刻发送一条，而是会将多条消息收集成一个批次 (Batch)，然后再统一发送给 Broker，大大减少了网络请求的开销。
    • 消费者侧： 消费者也是一次性从 Broker 拉取一个批次的数据回来处理，而不是一条一条地去请求。

并行化架构设计

**分区机制 (Partitioning):：**这是 Kafka 实现水平扩展和高并发的根本。一个 Topic 被分成多个分区，这些分区可以被分布在不同的 Broker 服务器上。

  • 写并行： 生产者可以同时向多个分区写入数据。
  • 读并行： 消费者组内的多个消费者可以同时消费不同的分区。
  • 一个 Topic 的总吞吐量，理论上是所有分区的吞吐量之和。如果觉得吞吐量不够，最直接的办法就是增加 Topic 的分区数（并相应增加消费者数量），以此来水平扩展整个系统的处理能力。

精简的协议与数据结构

  • 二进制协议: Kafka 客户端和服务器之间使用非常精简的二进制协议进行通信，开销小，序列化和反序列化效率高。
  • 简单的日志结构: 分区的数据文件就是简单的日志文件，查询时通过 Offset 进行，这是一个简单的数学计算，不需要像数据库那样复杂的索引结构，因此查找效率非常高。

小结

Kafka之所以能实现这么高的并发和吞吐能力，主要得益于它在四个方面的精妙设计：

第一，是对磁盘的极致高效利用。 它通过采用顺序读写（Append-only Log）的方式，将慢速的磁盘随机I/O变成了接近内存速度的顺序I/O。同时，它充分利用了操作系统的页缓存（Page Cache），实现了读写的进一步加速。

第二，是极致的I/O优化。 它使用了‘零拷贝’技术，在数据发送时避免了不必要的内核与用户空间的数据复制，大大降低了CPU开销。此外，无论是生产者还是消费者，都采用了‘批处理’的设计，将多次小的网络请求合并为一次大的请求，极大地提升了效率。

第三，是它的并行化架构。 Kafka通过‘分区’机制，将一个Topic的数据打散到多个Broker上，实现了读写的并行处理。Topic的整体吞吐量可以通过增加分区数来水平扩展。

第四，是它精简的底层设计。 它使用了高效的二进制通信协议，并且其核心的数据结构（日志文件）非常简单，通过Offset进行数据定位，查询效率很高。

总的来说，Kafka并非凭空变快，而是通过这一系列精妙的设计，将压力分解、将操作合并、将数据流优化，最终实现了看似不可思议的高吞吐能力。”

Kafka 消费之后的消息会被删除吗？

答：绝对不会。这是 Kafka 与传统消息队列（如 RabbitMQ）最核心、最本质的区别之一。

  • 传统消息队列： 消息被消费（并确认）后，通常会从队列中删除，因为它被视为一个“待办事项”，办完了就销毁。
  • Kafka： 消费行为本身，绝对不会导致 Kafka 删除消息。

为什么不删除？
在 Kafka 的世界里，数据被看作是一条事实记录流（Stream of Facts），而不是一次性的任务。消费者（Consumer）更像是一个“读者”，它只是从日志的某个位置（我们称之为 Offset）开始读取数据。

  • 消费者的消费进度，仅仅是移动它自己的书签（Offset）。
  • 多个不同的消费者组（比如“实时风控组”、“数据分析组”、“日志监控组”）可以独立地、反复地消费同一份数据，它们的消费进度互不影响。一个组读完了，另一个组可能才刚开始读。

那么，数据到底什么时候被删除？

数据删除只和 Topic 配置的“数据保留策略 (Log Retention Policy)”有关。Kafka 提供两种主要的保留策略：

  1. 基于时间的保留 (Time-based Retention):
    • 这是最常用的策略。你可以为一个 Topic 设置一个保留时长，比如 7 天。
    • 配置示例： retention.ms=604800000 (7天的毫秒数)
    • 效果： Kafka 会启动一个后台线程，定期检查并自动删除那些发布时间超过 7 天的旧数据，无论这些数据是否被消费过。
  2. 基于大小的保留 (Size-based Retention):
    • 你也可以为一个 Topic 设置一个总的存储大小阈值，比如 50 GB。
    • 配置示例： retention.bytes=53687091200 (50 GB的字节数)
    • 效果： 当这个 Topic 的总数据量将要超过 50 GB 时，Kafka 会从最老的数据开始删除，以确保总大小不超过这个限制。

通常，你可以同时设置这两个参数，任何一个条件先被触发，都会导致数据被删除。

消费者组 (Consumer Group) 和消费过程

消费者组 (Consumer Group) - Kafka 如何实现并行处理

1. 技术定义

  • 消费者组 (Consumer Group): 一个消费者组由一个或多个消费者实例（进程）组成。它们共享同一个 group.id，并作为一个整体，共同来消费一个或多个 Topic 的数据。

2. 核心工作原则（这是关键）

Kafka 通过消费者组来实现两件事：负载均衡和并行消费。它遵循一条黄金法则：

一个 Topic 的同一个分区，在任意时刻，只能被同一个消费者组里的一个消费者实例所消费。

这条规则的作用域，仅限于单个消费者组（Consumer Group）内部。不同的消费者组之间是完全独立的、互不干扰的。

换句话说，分区是消费的最小并行单元。Kafka 会把一个 Topic 的所有分区，尽可能均匀地分配给一个消费者组里的所有成员。

3. 分配规则与场景示例

我们来看一个 Topic，名为 log_topic，它有 4 个分区（P0, P1, P2, P3）。

  • 场景 A：组里只有 1 个消费者 (C1)
    • 分配结果： 消费者 C1 会获得全部分区的消费权，即它需要自己处理 P0, P1, P2, P3 的所有消息。
  • 场景 B：组里有 2 个消费者 (C1, C2)
    • 分配结果： Kafka 会进行负载均衡。C1 可能会被分配 P0 和 P1，C2 会被分配 P2 和 P3。消费能力理论上翻了一倍。
  • 场景 C：组里有 4 个消费者 (C1, C2, C3, C4)
    • 分配结果： 这是最理想的并行状态。每个消费者刚好分配到 1 个分区。C1->P0, C2->P1, C3->P2, C4->P3。
  • 场景 D：组里有 5 个消费者 (C1, C2, C3, C4, C5)
    • 分配结果： 由于分区总共只有 4 个，根据“某一时刻一个分区只能被一个消费者消费”的原则，有 4 个消费者会被分配到分区。而第 5 个消费者 (C5) 将会处于空闲（idle）状态，接收不到任何消息。

4. 消费者组的意义

  • 高吞吐 / 并行处理： 如果你觉得消息处理得太慢，只需要在同一个消费者组里增加更多的消费者实例，就可以线性地提升处理能力（但消费者数量超过分区数就无效了）。
  • 高可用 / 故障转移： 如果组里的某个消费者实例突然宕机，它之前负责消费的分区，会被 Kafka 自动地重新分配给组里其他存活的消费者。这个过程被称为重平衡 (Rebalance)。

消费者组 (Consumer Group) 的“总控-调度”模型

  • Group Coordinator (总控中心): 这是集群中某一个 Broker 担当的角色。它专门负责管理某一个消费者组，比如维护组成员列表、监控成员心跳，以及最重要的——主持和启动重平衡 (Rebalance)，也就是“分配任务”。
  • Consumers (一线员工): 组里的每个消费者实例就是 worker。它们负责执行具体的工作（消费分区），并定期向 Coordinator 汇报心跳（表示自己还活着）。

1. “部分消费者没有分配到消息”（员工闲置问题）

这种情况确实会发生，其根本原因是：组内的消费者实例数量 > Topic 的分区数量。

  • 核心原则： Kafka 的黄金法则是，一个分区在同一时刻只能被组内的一个消费者消费。分区是最小的工作单元。
  • 举例： 一个 Topic 有 5 个分区，但你的消费组里却启动了 8 个消费者实例。
  • 结果： Coordinator 会将 5 个分区一对一地分配给 5 个消费者。剩下的 3 个消费者因为“无任务可领”，就会处于空闲 (idle) 状态，它们不会收到任何消息。

要点： 这说明通过无限增加消费者来提升处理能力是有上限的，上限就是 Topic 的分区数。

2. “消息分配不均匀”（工作量不均问题）

这种情况也很常见，通常发生在分区数不能被消费者数整除的情况下。

  • 举例： 一个 Topic 有 7 个分区，但组里有 3 个消费者。
  • 结果： Coordinator 没法做到完美平均分配。根据分配策略（比如默认的 RangeAssignor），分配结果可能是：
    • 消费者 A：负责 P0, P1, P2 (3个分区)
    • 消费者 B：负责 P3, P4 (2个分区)
    • 消费者 C：负责 P5, P6 (2个分区)
  • 后果： 消费者 A 的负载会比 B 和 C 更重。在设计系统时，需要考虑到这种不均衡的可能性。

3. “重复分配消息”（任务交接问题）

Kafka 的 Coordinator 绝对不会在同一时刻，将同一个分区分配给两个不同的消费者。这会造成严重的数据混乱。

您感受到的“重复”，实际上指的是我们之前讨论过的 “重复消费 (Duplicate Processing)”，它发生在 Rebalance 的过程中。

  • 场景：
    1. 消费者 A 正在处理分区 P0 的消息，它已经处理到 Offset 150，但还没来得及提交这个进度。
    2. 此时，消费者 A 突然崩溃。
    3. Coordinator 检测到 A 死亡，触发 Rebalance，将分区 P0 这个“孤儿任务”重新分配给了消费者 B。
    4. 消费者 B 接手 P0 后，它会从上一次成功提交的 Offset（比如是100）开始消费。
  • 结果： 消费者 B 会重新处理一遍 Offset 100 到 150 的消息。从旁观者角度看，消息好像被“重复分配”了，但实际上是任务被干净地交接了，只是接手者从上次的存档点开始工作而已。

4. “消费者在消费时是处于不可用状态的”

这个描述同样非常精准，它指的正是 Rebalance 期间的“Stop-the-World”现象。

在正常情况下，消费者是一直在工作的。但一旦 Rebalance 被触发（比如有成员加入或退出），就会发生以下情况：

  1. 全体暂停： Coordinator 会通知组内所有的消费者：“全体注意，停止拉取新消息，准备重新分配任务！”
  2. 放弃任务： 所有消费者会放弃对自己当前负责的分区的“所有权”。
  3. 等待分配： 所有消费者都进入等待状态，直到 Coordinator 完成新的分配方案。
  4. 恢复工作： 消费者收到新的任务分配后，才开始根据新的分配方案去消费。

这个从“暂停”到“恢复工作”的整个过程，就是消费者组的“全体不可用状态”。频繁的 Rebalance 会严重影响消费组的整体吞吐量，是生产环境中需要尽量避免的。

深入理解“某一时刻”：重平衡 (Rebalance)

什么是重平衡？

重平衡，本质上就是 Kafka 将一个 Topic 的全部分区，在同一个消费者组的所有成员之间，进行重新分配的过程。

它的最终目的是为了确保：

  1. 组里的每个消费者都分到了合理的工作量。
  2. Topic 的每个分区都有一个明确的负责人。

重平衡的三大触发场景

1. 消费者组成员数量发生变化

这完全是和消费者直接相关的。

  • 新消费者加入：
    • 场景： 你觉得消费速度太慢，于是启动了一个新的消费者实例，并让它加入到现有的消费者组中。
    • 原因： 新来的成员需要被分配工作（分区）。为了公平，不能让它闲着，所以需要从其他成员那里拿走一些分区，重新进行“大锅饭”式的分配。
  • 旧消费者离开：
    • 场景： 组里的一个消费者实例因为正常关闭或意外崩溃而下线。
    • 原因： 它之前负责的分区现在成了“孤儿”，无人处理。为了保证这些分区的数据能被继续消费，必须将它们分配给组里其他还存活的成员。我们之前讨论的 session.timeout.ms 和 max.poll.interval.ms 就是用来检测这种“意外离开”的。

2. 订阅的 Topic 分区数量发生变化

“分区导致”的情况。

  • 场景： 一个 Topic my-topic 原本有 5 个分区，一个消费者组正在稳定地消费它。这时，运维管理员为了提升吞吐量，执行命令将 my-topic 的分区数增加到了 8 个。
  • 原因： 集群中突然多出来了 3 个新的分区（P5, P6, P7），这些新分区目前没有消费者负责。为了让这些新分区的数据也能被消费，Kafka 必须触发一次重平衡，将全部的 8 个分区在所有消费者之间重新分配。

3. 订阅的 Topic 本身发生变化

  • 场景： 一个消费者组原本只订阅了 topic-A。现在你修改了消费者的代码，让它同时订阅 topic-A 和 topic-B。
  • 原因： 整个消费者组需要消费的总分区列表发生了变化（增加了 topic-B 的所有分区）。旧的分配方案已经过时，因此必须触发重平衡，以制定一个包含两个 Topic 所有分区的新分配方案。

重平衡期间会发生什么？

这是一个“Stop-the-World”的过程，对消费有一定影响：

  1. 暂停消费： 当 Rebalance 触发时，该消费组内的所有消费者都会暂停拉取和处理消息。
  2. 重新分配： 由组协调器（Group Coordinator，一个 Broker）来主持，根据分配策略，为每个消费者成员重新分配分区。
  3. 恢复消费： 分配完成后，每个消费者只消费新分配给自己的分区。

Offset 的提交机制

1. 概念回顾与定义

  • Offset (位移): 我们之前提过，分区（Partition）内的每一条消息都有一个唯一的、从 0 开始递增的序列号，这就是 Offset。它就是消息的地址。
  • 提交位移 (Commit Offset): 消费者在消费消息的过程中，需要定期地向 Kafka 集群中的一个特殊内部 Topic（名为 __consumer_offsets）报告：“对于我负责的某个分区，我已经成功处理到哪个 Offset 了”。这个“报告”或“记录”的动作，就叫做提交位移。

它的核心目的，就像在书里夹一个书签：

当消费者重启，或者分区被重新分配给另一个消费者时，新的消费者可以先去__consumer_offsets这个地方查找这个分区对应的“书签”，从而准确地知道应该从哪里开始继续阅读，以保证数据处理的连续性。

2. 两种核心的提交方式

提交“书签”的方式主要有两种：

  • 方式一：自动提交 (Auto Commit)
    • 工作方式： 这是 Kafka 消费者的默认行为。你只需要在配置中设置 enable.auto.commit=true（默认就是 true），并设定一个时间间隔（auto.commit.interval.ms，默认是 5 秒）。消费者客户端会每隔 5 秒，自动地将它拉取到的最新 Offset 提交上去。
    • 优点： 非常简单，用户基本无感知，不用自己写提交代码。
    • 缺点（非常致命）： 时机不精确，可能导致消息丢失或重复消费。
      • 场景1（重复消费）： 你的程序在 3 秒内处理完了 100 条消息，但还没到 5 秒的提交时间点，你的程序突然崩溃了。重启后，由于上次的进度没有被提交，它只能从 100 条消息之前的位置开始重新消费，导致这 100 条消息被重复处理。
      • 场景2（消息丢失，更危险）： 你的程序拉取了 100 条消息，还没开始处理，5 秒的提交时间就到了，客户端自动把这 100 条消息的进度提交了。紧接着，你的程序在处理第 10 条消息时崩溃了。重启后，由于进度已经被提交，它会从第 101 条消息开始消费，导致第 10 到 100 条消息永远没有被处理，造成了数据丢失。
  • 方式二：手动提交 (Manual Commit)
    • 工作方式： 在配置中设置 enable.auto.commit=false，然后在你的代码逻辑中，在你确认消息已经被业务逻辑完全成功处理之后（比如，数据已经成功写入数据库），再手动调用提交方法来更新 Offset。
    • 优点： 控制权完全在开发者手中，非常可靠。 你可以确保只有当业务逻辑成功完成后，才去移动“书签”。这极大地保证了消息处理的准确性。
    • 常用的手动提交方法：
      • commitSync() (同步提交): 它会阻塞程序，直到位移被成功提交才继续往下走。如果提交失败会一直重试。简单可靠，但会牺牲一点性能。
      • commitAsync() (异步提交): 它不会阻塞程序，提交请求后立刻返回。性能更高，但如果提交失败，它不会自动重试，需要开发者在回调函数中自行处理。

1. 解构消费者的位置指针：四个核心 Offset

为了精确控制消费，我们需要了解消费者在工作时涉及的四种“位移”或“指针”：

  • Committed Offset (已提交位移):
    • 定义： 这是我们之前讨论的“书签”。它被持久化地存储在 Kafka 的 __consumer_offsets 主题中。它代表消费者组确认已经成功处理完成的最后一个 Offset + 1。
    • 作用： 这是消费者故障恢复的依据。当消费者重启或 Rebalance 后，它会从这个位置开始消费。
  • Current Offset / Position (当前消费位置):
    • 定义： 这是一个内存中的指针，代表消费者下一次调用 poll() 方法时应该获取的消息的起始位置。
    • 关系： 消费者调用 poll() 拉取一批数据后，这个 Position 指针就会向前移动。所以，Position 总是领先于 Committed Offset。(Position >= Committed Offset)
  • Log End Offset (LEO，日志末端位移):
    • 定义： 这不属于消费者，而是分区（Partition）本身的属性。它代表该分区中下一条待写入消息的 Offset。可以理解为分区当前“最末尾”的位置。
    • 作用： 消费者通过比较自己的 Committed Offset 和分区的 LEO，可以计算出消费延迟 (Lag)，即还有多少消息没被消费。Lag = LEO - Committed Offset。
  • Start Offset / Beginning Offset (起始位移):
    • 定义： 这也是分区本身的属性，代表该分区中现存的最旧的一条消息的 Offset。
    • 作用： 通常是 0，但如果因为数据保留策略删除了旧数据，这个值就会变大。

2. auto.offset.reset：什么时候 Kafka 会‘找不到 Offset’？

触发时机（找不到 Offset 的两种情况）：

  1. 全新的消费者组： 一个全新的 group.id 第一次启动，它在 Kafka 中没有任何历史记录，自然也就没有已提交的 Committed Offset。
  2. 位移已过期： 消费者提交了 Offset（比如 500），然后下线了很长时间（例如一周）。在这一周里，Kafka 的数据保留策略已经将旧数据删除，现在分区里最老的 Start Offset 已经是 1000 了。当这个消费者再次上线时，它想从 500 开始消费，但这个位置的数据早已不存在，因此“找不到 Offset”。

当这些情况发生时，auto.offset.reset 参数就决定了消费者的行为：

  • earliest：“从头读起”。消费者会从该分区当前可用的最早的 Offset (Start Offset) 开始消费；但是需要注意的是，earliest 会存在重复处理的可能性。
    • 情况一：正常下线（先 Commit，后下线）
      • 处理完成： 消费者处理完一批消息（比如到 Offset 150）。
      • 成功提交： 调用 commitSync() 或 commitAsync() 成功，将“书签”更新到 151。
      • 服务下线： 程序正常关闭。
      • 重新上线： 程序重启后，去 Kafka 读取“书签”，发现是 151。
      • 结果： 从 Offset 151 开始消费，一切正常，没有重复，也没有遗漏。
    • 情况二：异常下线（来不及 Commit 就下线）
      • 处理完成： 消费者处理完一批消息（比如到 Offset 150），数据已经写入数据库。
      • 提交前崩溃： 在更新“书签”到 151 之前，程序因意外（如服务器断电、进程被强制杀死）而崩溃。
      • 重新上线： 程序重启后，去 Kafka 读取“书签”，发现书签还停留在上一次成功提交的位置（比如 Offset 100）。
      • 结果： 消费者只能从旧的“书签”位置 100 开始重新拉取数据。因此，它会再一次处理 100 到 150 的消息，这就造成了重复处理。
  • latest：（默认值）“只读新的”。消费者会直接跳到分区的最末尾 (Log End Offset) 开始消费。它会忽略掉所有在它启动之前就已经存在的数据。
  • none：“直接报错”。如果找不到有效的 Offset，消费者会直接抛出 NoOffsetForPartitionException 异常，将问题交给程序自己处理。

3. 如何选择 auto.offset.reset 的值？—— 一个基于业务场景的决策指南

选择哪个值，取决于你的应用能否容忍数据丢失。

1. 选择 latest (默认值)

  • 适合的业务场景：
    • 实时监控和告警系统
    • 展示最新状态的仪表盘 (Dashboard)
    • 对时效性要求极高，但对历史数据完整性不敏感的应用
  • 决策逻辑：
    这类应用的核心是“关注当下”。如果系统中断了一小时，它最关心的是尽快跟上当前的实时数据流，而不是回头去处理一小时前的旧告警。因此，它选择“忽略历史，从最新的开始”，这是最合理的。
  • 需要承担的风险：潜在的数据丢失风险。 如果服务因为任何原因（无论是新加入还是位移过期）发生了位移重置，它会永久性地跳过所有在它离线期间产生的数据。

2. 选择 earliest

  • 适合的业务场景：
    • 数据同步任务（例如，将数据从 Kafka 同步到数据库或数据仓库）
    • 离线数据分析和报表系统
    • 所有数据完整性至关重要的核心业务系统
  • 决策逻辑：
    这类应用的核心是“一条都不能少”。数据的任何缺失都会导致最终结果的错误。因此，即使代价是可能需要处理大量历史数据，也必须选择从最早的位置开始，以确保数据的完整性。
  • 需要承担的风险：潜在的数据重复处理和启动延迟。 如果一个全新的消费组错误地配置为 earliest，它可能会试图从分区中现存的最早（可能是几天甚至几周前）的数据开始消费，这可能不是预期的行为，并可能给下游系统带来巨大压力。

3. 选择 none

  • 适合的业务场景：
    • 极其敏感的金融交易或审计系统
    • 你希望对位移丢失的情况有完全的、自定义的控制权
  • 决策逻辑：
    这类应用的核心是“杜绝任何不确定性”。earliest 和 latest 都是一种“猜测”，而 none 则拒绝猜测。它会直接抛出异常，强制程序或运维人员介入，搞清楚到底发生了什么，然后再手动决定从哪里开始消费。这是最安全、但自动化程度最低的选择。
  • 需要承担的代价：
    需要编写额外的异常处理代码，并可能需要人工介入，降低了系统的自动化程度，但换来了最高的确定性。

结论与经验法则

所以，不存在“最好”的设置，只有“最适合你的业务场景”的设置。

  • 经验法则 (Rule of Thumb):
    • 如果你的应用能容忍数据丢失，但需要尽快跟上实时流，用 latest。
    • 如果你的应用绝不能丢失任何数据，用 earliest，并为可能处理大量历史数据做好准备。
    • 如果你的应用处理的是极其敏感的数据，任何不确定性都需要报警并由人来决策，用 none。

4. 会话管理与 max.poll.interval.ms：“你还活着吗？”

Kafka 有一套心跳机制来判断消费者是否存活。

  • session.timeout.ms (会话超时): Broker（组协调器）会认为，如果一个消费者在这个时间内没有发送任何心跳，那么它就死了，会触发 Rebalance。
  • heartbeat.interval.ms (心跳间隔): 消费者客户端在后台会按照这个间隔，持续地向 Broker 发送心跳。这个值必须远小于 session.timeout.ms。

但是，心跳只能证明消费者的进程还活着，万一它卡在业务逻辑里（比如死循环），无法继续处理消息怎么办？

这就是 max.poll.interval.ms 的作用。

  • max.poll.interval.ms (处理时长上限): 这个参数定义了两次调用 consumer.poll() 方法之间的最大时间间隔。消费者的业务逻辑必须在这个时间内处理完并返回，再次调用 poll()。如果超过了这个时间，消费者客户端会主动认为自己“失联”，并离开消费组，同样也会触发 Rebalance。这可以防止“假活”的僵尸消费者拖垮整个消费进度。

4. 如何避免长时间处理导致消费者被踢出？

这是 max.poll.interval.ms 带来的实际问题：如果我的业务逻辑确实很耗时，超过了默认的5分钟怎么办？

  1. 简单粗暴：调大参数。 直接增加 max.poll.interval.ms 的值。但这会延长真正检测到消费者死亡的时间，不是最佳方案。
  2. 减少单次处理量： 调小 max.poll.records 参数，让每次 poll() 返回更少的消息，这样你的处理循环就能更快地结束。
  3. 最佳实践：解耦处理（异步化）。
    • 创建一个专门的 Kafka 消费线程，它的唯一工作就是快速地调用 poll()，将拉取到的消息塞进一个内存队列（例如 BlockingQueue）。这个线程的循环非常快，永远不会超时。
    • 另外创建一个或多个工作线程池，由它们从内存队列中取出消息，慢慢地执行耗时的业务逻辑。
    • 注意： 这种模式下，Offset 管理变得更复杂。你必须在工作线程真正处理完数据后，再由消费线程去手动提交对应的 Offset。
Kafka
  目录