线上告警！Kafka积压百万消息，我们是这样快速止血的

针对将积压消息转发到新主题进行快速消费的主流救火方案，其核心是通过数据迁移与资源扩容并行，实现消费能力的瞬时弹性提升。该方案的本质是创建一个临时的、高吞吐的“消费缓冲区”，将压力从原业务消费链路上剥离，从而为修复原消费者或处理积压数据争取时间。虽然需要编写转发和消费代码，但因其效果显著，已成为处理大规模积压的标准应急操作。

方案架构与核心步骤

此方案通常包含三个核心角色：转发消费者 (Dumper)、新主题 (Backlog-Topic) 和临时消费者 (Emergency-Consumer)。其数据流与职责如下表所示：

组件	核心职责	关键设计要点
转发消费者 (Dumper)	1. 从积压原主题高速拉取消息。 2. 将消息（或经简单处理）写入新主题。	• 逻辑极简，仅做转发。 • 可多实例并行，对应原主题分区数。 • 关闭自动提交，手动管理偏移量。
新主题 (Backlog-Topic)	作为临时缓冲池，承载积压消息。	• 分区数需远大于原主题（如2-3倍），为并行消费提供空间。 • 根据数据量设置合理的保留时间。
临时消费者 (Emergency-Consumer)	消费新主题中的消息，进行最终处理（如落库）。	• 实例数可弹性扩缩，最大可达新主题分区数。 • 处理逻辑应轻量、幂等。

具体实施步骤如下：

1. 创建高分区新主题

首先，需要创建一个分区数充足的新主题，这是提升并行消费能力的基础。分区数建议设置为原积压主题分区数的整数倍（例如3倍），以便后续可以启动大量临时消费者实例进行并行消费。

# 使用Kafka命令创建新主题，例如设置30个分区
bin/kafka-topics.sh --create \
    --topic backlog-emergency-topic \
    --partitions 30 \
    --replication-factor 2 \
    --bootstrap-server localhost:9092

2. 编写并部署转发程序 (Dumper)

转发程序的核心是高速、无损地将消息从旧主题搬运到新主题。它应该是一个独立的服务，可以快速启动多个实例，每个实例消费原主题的一个或多个分区。

// 示例：高性能转发消费者核心逻辑
public class EmergencyMessageDumper {
    
    public static void main(String[] args) {
        Properties consumerProps = new Properties();
        consumerProps.put("bootstrap.servers", "localhost:9092");
        consumerProps.put("group.id", "emergency-dumper-group"); // 独立的消费组
        consumerProps.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
        consumerProps.put("value.deserializer", "org.apache.kafka.common.serialization.ByteArrayDeserializer");
        consumerProps.put("enable.auto.commit", "false"); // 关闭自动提交，精确控制
        consumerProps.put("max.poll.records", "1000"); // 单次拉取大量记录

        Properties producerProps = new Properties();
        producerProps.put("bootstrap.servers", "localhost:9092");
        producerProps.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        producerProps.put("value.serializer", "org.apache.kafka.common.serialization.ByteArraySerializer");
        producerProps.put("linger.ms", "5"); // 适当批量发送提升吞吐
        producerProps.put("batch.size", "1048576"); // 1MB批次大小

        try (KafkaConsumer<String, byte[]> consumer = new KafkaConsumer<>(consumerProps);
             KafkaProducer<String, byte[]> producer = new KafkaProducer<>(producerProps)) {
            
            consumer.subscribe(Collections.singletonList("original-backlog-topic"));
            
            while (true) {
                ConsumerRecords<String, byte[]> records = consumer.poll(Duration.ofMillis(1000));
                for (ConsumerRecord<String, byte[]> record : records) {
                    // 核心转发操作：保持原消息Key和Value，发送至新主题
                    ProducerRecord<String, byte[]> newRecord = new ProducerRecord<>(
                        "backlog-emergency-topic",
                        record.partition(), // 可选：可以重新分配分区策略
                        record.key(),
                        record.value()
                    );
                    producer.send(newRecord);
                }
                // 批量处理完成后，手动提交偏移量，确保至少一次语义
                consumer.commitSync();
            }
        }
    }
}

关键点：转发程序应避免复杂的业务逻辑，其唯一目标就是尽快搬移数据。可以启动多个该程序实例，通过消费组机制分摊原主题各分区的消费压力。

3. 编写并弹性部署临时消费者

临时消费者负责消化新主题中的消息。其处理逻辑应根据最终目标来定：如果只是为了清空Kafka，可以简单落地到数据库或文件；如果还需要业务补偿，则可能包含简化的业务逻辑。

// 示例：临时消费者批量落库逻辑
@KafkaListener(topics = "backlog-emergency-topic",
               containerFactory = "batchFactory",
               concurrency = "10") // 并发消费者数，可接近分区数
public void consumeEmergencyBatch(List<ConsumerRecord<String, String>> records) {
    List<EmergencyMessage> messageList = new ArrayList<>();
    for (ConsumerRecord<String, String> record : records) {
        // 1. 极简转换，避免复杂业务处理
        EmergencyMessage msg = convertToEntity(record);
        messageList.add(msg);
    }
    // 2. 批量插入数据库，极大提升效率
    emergencyMessageService.batchInsert(messageList);
    // 3. 可记录进度，但无需事务性保证，消费速度优先
    log.info("Batch processed {} messages.", records.size());
}

同时，需要为这个临时消费者服务配置弹性伸缩能力。在Kubernetes环境中，可以基于Kafka消费延迟（Lag）指标配置HPA（Horizontal Pod Autoscaler），实现自动扩缩容。

# 示例：K8s HPA配置，基于消费延迟指标扩缩容
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: emergency-consumer-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: emergency-consumer
  minReplicas: 5
  maxReplicas: 30 # 最大副本数可接近或等于新主题分区数
  metrics:
  - type: External
    external:
      metric:
        name: kafka_consumer_lag
        selector:
          matchLabels:
            topic: backlog-emergency-topic
            consumerGroup: emergency-consumer-group
      target:
        type: AverageValue
        averageValue: 1000 # 当平均每个分区积压超过1000条时开始扩容

方案优势与注意事项

优势

1. 业务解耦与保护：将积压消息转移到独立主题，避免了对正常业务消费链路的持续冲击，原消费者组可以暂停或修复。
2. 弹性与并行度：新主题的高分区数为启动大量临时消费者实例提供了基础，可以实现消费能力的线性提升，这是解决积压最有效的手段。
3. 处理策略灵活：临时消费者可以采用与原始业务不同的处理策略，例如只入库不计算、降低处理标准等，一切以速度优先。

注意事项与潜在风险

1. 消息顺序与语义：如果原业务依赖消息的分区内顺序，在转发时需注意。示例代码中直接使用了原分区号，但这仅在临时主题分区数不小于原主题且采用相同分区策略时才有效。更通用的做法是根据消息Key进行转发，确保同一Key的消息进入新主题的同一分区。
2. 资源与成本：该方案需要额外的计算资源（运行转发和临时消费者）和存储资源（新主题的磁盘空间），属于用资源换时间的权衡。
3. 数据一致性：需确保转发过程不丢消息。示例中采用手动提交偏移量（commitSync）和生产者发送后不立即关闭的方式，提供了至少一次（at-least-once）的保证。最终处理可能需要幂等设计来应对重复消息。
4. 收尾工作：积压处理完毕后，需要有流程来核对原主题和新主题的消息总量，确保数据完整。然后逐步下线临时服务，并可能需将临时库中的数据与业务主库进行核对与合并。

总结，通过编写代码将积压消息转发到高分区新主题，并配套弹性临时消费者的方案，是一种经典的“空间换时间”和“解耦”的应急处理模式。它通过架构上的隔离与资源的弹性投入，能够快速形成对海量积压消息的“消化能力”，为后续根因排查和系统修复赢得宝贵时间窗口，是处理Kafka百万级消息积压中最主流且有效的技术手段之一。

---

参考来源

• ios 消息转发实现_mob64ca12e9cad4的技术博客_51CTO博客
• 深入解析Kafka主题分区与消息发送_kafka发送分区检查-优快云博客
• 如何使用API将主题消息添加到消息中？