2. Kafka 基础回顾：核心概念与消息模型
在排查 Kafka 堆积与 Redis 热 Key 联动故障之前，必须牢固掌握 Kafka 的基础架构。本节将围绕 Topic、Partition、Consumer Group 三大核心概念，梳理消息模型与偏移量管理机制，为后续的积压诊断和 Redis 联动分析打下理论基础。
2.1 核心概念：Topic、Partition、Consumer Group
Kafka 是一个分布式流处理平台，其核心抽象是 Topic（主题）。Topic 是消息的逻辑分类，每个 Topic 可被进一步划分为多个 Partition（分区），以实现水平扩展和并行消费。多个 Consumer 可以组成一个 Consumer Group（消费组），共同消费一个 Topic 的消息。
| 概念 | 定义 | 关键特性 |
|---|---|---|
| Topic | 消息的逻辑分类，类似数据库中的表 | 可配置分区数、副本数；消息按 Topic 存储 |
| Partition | Topic 的物理分片，每个分区是一个有序、不可变的消息序列 | 分区内消息有唯一偏移量；分区数决定并行度 |
| Consumer Group | 一组 Consumer 实例，共同消费一个或多个 Topic | 组内每个分区只能被一个 Consumer 消费；组间独立 |
关键理解： Partition 是 Kafka 并行处理的最小单元。一个 Topic 的分区数决定了该 Topic 的最大消费并行度。在堆积场景下，分区数不足往往是消费能力瓶颈的直接原因。
2.2 消息模型：生产者、Broker、消费者
Kafka 的消息传递遵循 发布-订阅 模型，核心角色包括 Producer（生产者）、Broker（服务节点）和 Consumer（消费者）。消息从 Producer 发布到指定 Topic，由 Broker 持久化存储，再被 Consumer 拉取消费。
2.3 偏移量管理：Offset 与消费进度
Offset（偏移量） 是 Partition 内每条消息的唯一递增序号。Consumer 通过提交 Offset 来记录消费进度。Kafka 提供了两种偏移量提交方式：自动提交 和 手动提交。
| 提交方式 | 机制 | 适用场景 | 风险 |
|---|---|---|---|
| 自动提交 | Consumer 每隔 auto.commit.interval.ms（默认 5s）自动提交当前拉取的最大 Offset |
对数据一致性要求不高、允许少量重复消费的场景 | 可能造成消息丢失或重复；堆积时偏移量跳跃大 |
| 手动提交 | 业务代码显式调用 commitSync() 或 commitAsync() 提交 Offset |
需要精确控制消费进度、保证 at-least-once 语义 | 提交频率过高影响性能；提交失败可能导致重复消费 |
堆积场景警示： 当 Kafka 发生消息堆积时，Consumer 的 Offset 提交行为会直接影响 Redis 的写入模式。如果 Consumer 批量拉取大量消息后一次性提交 Offset，可能导致短时间内对 Redis 产生密集的写入请求，从而触发热 Key 问题。这是后续联动排查的核心线索。
2.4 消费组再均衡与分区分配
当 Consumer Group 内的成员发生变化（加入、离开、崩溃）时，Kafka 会触发 再均衡（Rebalance） 操作，重新分配分区给各个 Consumer。分区分配策略决定了每个 Consumer 负责哪些分区。
- Range 策略： 按 Topic 分区序号范围分配，可能导致分区分配不均。
- RoundRobin 策略： 轮询分配，尽量使每个 Consumer 分配到的分区数相等。
- Sticky 策略： 在再均衡时尽量保持已有的分区分配，减少不必要的分区移动。
实践建议： 在堆积场景下，频繁的再均衡会打断消费流程，加剧堆积。建议使用 Sticky 策略 并合理设置
session.timeout.ms 和 heartbeat.interval.ms，避免因网络抖动导致不必要的再均衡。
2.5 消息可靠性语义
Kafka 提供了三种消息传递语义，理解它们对于设计可靠的消费逻辑至关重要：
| 语义 | 描述 | 实现方式 |
|---|---|---|
| At-most-once | 消息最多被消费一次，可能丢失 | Consumer 在拉取消息后立即提交 Offset，再处理业务 |
| At-least-once | 消息至少被消费一次，可能重复 | Consumer 先处理业务，再提交 Offset；失败时重新拉取 |
| Exactly-once | 消息精确地被消费一次，不丢不重 | Kafka 事务 + 幂等性 Producer；或外部存储去重 |
2.6 小结：Kafka 基础与 Redis 联动排查的关联
理解 Kafka 的 Topic、Partition、Consumer Group 和偏移量管理，是诊断消息堆积的前提。在后续章节中，我们将看到：
- 分区数不足 导致消费并行度不够，消息在 Kafka 端堆积。
- 偏移量提交策略不当 导致 Consumer 频繁拉取大量消息，对下游 Redis 产生突发写入压力。
- 再均衡频繁 打断消费流程，进一步加剧堆积，形成恶性循环。
学习提示： 建议在本地搭建 Kafka 环境，使用
kafka-consumer-groups.sh 命令查看消费组偏移量滞后（LAG），这是后续排查堆积的第一手工具。