2. Kafka 核心概念回顾：Topic、Partition、Consumer Group、Offset 在支付链路中的角色

在深入诊断支付场景的并发瓶颈与消息堆积之前，必须重新审视 Kafka 的四大核心抽象——Topic、Partition、Consumer Group、Offset。它们在支付链路中并非简单的“队列”或“游标”，而是直接决定了吞吐上限、顺序保证、故障恢复与积压水位的关键因素。

2.1 Topic：支付业务的逻辑隔离单元

Topic 是 Kafka 中消息的逻辑分类。在支付系统中，通常按业务阶段或事件类型划分 Topic，例如：

• payment-order：支付订单创建事件
• payment-callback：支付渠道回调结果
• payment-reconciliation：对账差异事件
• payment-risk：风控审核结果

每个 Topic 独立配置分区数、副本数、保留策略。支付回调 Topic 通常要求高持久性（副本数 ≥ 3）和短保留时间（如 7 天），而对账 Topic 则需要长保留（如 30 天）以支持跨月核对。

2.2 Partition：并发与顺序的权衡核心

Partition 是 Kafka 并行度的基本单位。每个 Partition 内部保证消息有序，但不同 Partition 之间不保证全局顺序。在支付链路中，这一特性需要谨慎对待：

分区数直接影响最大消费并行度。支付场景中，分区数通常设置为消费者线程数的 2~3 倍，以应对突发流量和再均衡时的消费能力下降。

2.3 Consumer Group：消费能力伸缩与再均衡

Consumer Group 是 Kafka 实现点对点消费的抽象。同一 Group 内的消费者共同消费一个 Topic 的所有分区，每个分区只能被 Group 内的一个消费者消费。支付链路中，Consumer Group 的设计直接影响：

• 消费吞吐：Group 内消费者数量 ≤ 分区数时，增加消费者可线性提升吞吐；超过分区数时，多余消费者闲置。
• 再均衡影响：消费者加入或离开时触发 Rebalance，期间所有消费者暂停消费。支付场景中，Rebalance 可能导致秒级至分钟级的消费中断，加剧消息堆积。
• 消费隔离：不同业务模块使用不同的 Group。例如“支付回调处理组”和“对账处理组”各自独立消费同一个 Topic，互不影响。

2.4 Offset：精确回溯与堆积监控的锚点

Offset 是消息在 Partition 内的唯一序号，从 0 开始递增。Consumer 通过提交 Offset 记录消费进度。在支付链路中，Offset 承担三个关键角色：

Offset 提交方式直接影响数据一致性与性能：

• 自动提交（enable.auto.commit=true）：默认每 5 秒提交一次。支付场景中不推荐，因为消费者崩溃时可能丢失最近 5 秒的 Offset，导致重复消费或漏消费。
• 手动提交（enable.auto.commit=false）：在业务逻辑处理完成后显式提交。支付回调处理必须在数据库事务提交后再提交 Offset，确保“至少一次”语义。

// 支付回调消费者手动提交 Offset 示例
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        // 1. 处理支付回调业务逻辑（更新订单状态、记录流水）
        processPaymentCallback(record.value());
        
        // 2. 业务处理成功后，手动提交 Offset
        consumer.commitSync(Collections.singletonMap(
            new TopicPartition(record.topic(), record.partition()),
            new OffsetAndMetadata(record.offset() + 1)
        ));
    }
}

2.5 四大概念在支付链路中的协同关系

下图展示了 Topic、Partition、Consumer Group、Offset 在支付回调场景中的完整协作流程：