Kafka 核心概念回顾：Topic、Partition、Consumer Group、Offset、消息确认机制

在深入 Kafka 堆积与 Redis 连接池耗尽场景之前，必须重新校准 Kafka 的核心抽象。堆积的本质是 生产速度 > 消费速度，而消费速度受制于分区分配、偏移量提交与确认语义。本节将逐一拆解这些概念，并建立它们与性能调优的关联。

2.1 Topic 与 Partition：并行度的物理边界

Topic 是逻辑消息通道，Partition 是物理存储与并行消费的最小单元。每个 Partition 内部维护一个有序、不可变的消息序列，新消息追加到尾部，消费者从指定位置拉取。

2.2 Consumer Group 与分区分配策略

Consumer Group 是 Kafka 实现点对点与发布订阅两种模型的核心机制。Group 内所有消费者协同消费订阅 Topic 的全部 Partition，每个 Partition 只分配给 Group 内的一个消费者。

• 点对点模式： 所有消费者属于同一 Group，消息被消费一次。
• 发布订阅模式： 每个消费者属于独立 Group，消息被广播到所有 Group。

分区分配策略对比

2.3 Offset：消费进度的唯一凭证

Offset 是 Partition 内消息的序号，消费者通过提交 Offset 来记录消费进度。Kafka 将 Offset 保存在内部 Topic __consumer_offsets 中（默认 50 个分区）。

• 自动提交（enable.auto.commit=true）： 每隔 auto.commit.interval.ms（默认 5 秒）提交一次。堆积场景下可能导致重复消费或丢失消费。
• 手动提交（enable.auto.commit=false）： 业务代码显式调用 commitSync() 或 commitAsync()。推荐在堆积场景使用，精确控制提交时机。

// 手动同步提交示例
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000));
    for (ConsumerRecord<String, String> record : records) {
        processRecord(record);  // 业务处理
    }
    try {
        consumer.commitSync();  // 处理完成后提交
    } catch (CommitFailedException e) {
        log.error("Offset commit failed", e);
    }
}

2.4 消息确认机制：acks 与 min.insync.replicas

生产端确认机制决定了消息写入的持久性与延迟。在堆积场景下，acks 配置直接影响生产者的吞吐量。

min.insync.replicas 配合 acks=all 使用，定义最少需要同步的副本数。例如设置为 2，则至少 2 个副本写入成功才返回确认。

2.5 概念关联：堆积场景下的关键链路

将上述概念串联起来，形成堆积场景下的核心链路：

1. 生产者 以高吞吐写入 Topic，acks=all 保证数据不丢。
2. Partition 作为并行单元，分区数不足时形成写入瓶颈。
3. Consumer Group 内消费者数量 ≤ Partition 数，否则消费者闲置。
4. Offset 提交 过于频繁或失败，导致重复消费或消费停滞。
5. 消息确认 延迟过高，生产者重试，进一步加剧堆积。