2. Kafka 消息投递语义：At-most-once、At-least-once、Exactly-once 及其对死信的影响

消息投递语义（Message Delivery Semantics）定义了 Producer 向 Broker 发送消息以及 Consumer 从 Broker 消费消息时，系统在故障场景下对消息“是否丢失”或“是否重复”的保证程度。理解这三种语义是设计死信队列（DLQ）策略的前提——不同的语义决定了消息何时、以及为何会进入死信队列。

2.1 三种投递语义核心对比

2.2 At-most-once 语义

工作机制： Producer 发送消息后不等待 Broker 确认（acks=0），或 Consumer 在消费后立即提交偏移量，无论处理是否成功。

• Producer 端： acks=0，不重试（retries=0）。
• Consumer 端： 启用 enable.auto.commit=true 且 auto.commit.interval.ms 很短，或手动提交偏移量在业务处理之前。
• 适用场景： 日志采集、监控指标等允许少量丢失的数据。
• 死信风险： 消息在到达 Broker 前丢失，或 Consumer 崩溃导致未处理的消息被跳过，这些消息永远不会进入 DLQ，造成“静默丢失”。

2.3 At-least-once 语义

工作机制： Producer 等待 Broker 确认（acks=1 或 all），失败时重试；Consumer 在处理完业务逻辑后再提交偏移量。

• Producer 端： acks=1 或 acks=all，retries>0，enable.idempotence=false（默认）。
• Consumer 端： 手动提交偏移量（enable.auto.commit=false），在处理成功后调用 commitSync() 或 commitAsync()。
• 适用场景： 订单处理、支付通知、报表数据导出等不允许丢失的业务。
• 死信风险： 重复消息可能多次进入 DLQ。例如，Consumer 处理成功但提交偏移量前崩溃，重启后重新消费同一消息，再次进入 DLQ。需要在 Consumer 侧实现幂等性或去重逻辑。

// At-least-once 消费示例：处理成功后再提交偏移量
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        try {
            processRecord(record);  // 业务处理
            // 处理成功后手动提交偏移量
            consumer.commitSync(Collections.singletonMap(
                new TopicPartition(record.topic(), record.partition()),
                new OffsetAndMetadata(record.offset() + 1)
            ));
        } catch (Exception e) {
            // 发送到死信队列
            sendToDLQ(record, e);
            // 即使发送到 DLQ，也提交偏移量，避免无限重试
            consumer.commitSync();
        }
    }
}

2.4 Exactly-once 语义

工作机制： 通过幂等性 Producer 和事务性 API 实现端到端的精确一次语义。

• Producer 端： 设置 enable.idempotence=true，acks=all，transactional.id 唯一标识。
• Consumer 端： 设置 isolation.level=read_committed，只读取已提交的事务消息。
• 适用场景： 金融交易、库存扣减、对账系统等对数据一致性要求极高的场景。
• 死信风险： 事务内的消息如果处理失败，整个事务回滚，消息不会进入 DLQ。通常需要在事务外单独处理失败消息，或将 DLQ 写入操作也纳入同一事务（需支持两阶段提交）。

2.5 三种语义对死信队列的完整影响

2.6 投递语义选择决策树

在实际生产环境中，选择哪种投递语义取决于业务对数据一致性和性能的权衡。以下决策树可帮助快速判断：

1. 业务是否允许消息丢失？
   • 是 → 考虑 At-most-once（日志、监控）
   • 否 → 进入下一步
2. 业务是否允许消息重复？
   • 是 → 考虑 At-least-once（报表导出、通知）
   • 否 → 进入下一步
3. 业务是否要求端到端精确一次？
   • 是 → 考虑 Exactly-once（金融、库存）
   • 否 → 仍可使用 At-least-once + 幂等 Consumer

2.7 不同语义下的 DLQ 配置示例

// At-least-once 语义下的 Producer 配置（推荐用于报表导出）
Properties props = new Properties();
props.put("bootstrap.servers", "kafka1:9092,kafka2:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "all");                 // 等待所有副本确认
props.put("retries", "3");                // 失败重试 3 次
props.put("retry.backoff.ms", "500");     // 重试间隔 500ms
props.put("enable.idempotence", "false"); // 不启用幂等性（允许重复）

// Exactly-once 语义下的 Producer 配置（用于金融级场景）
Properties exactlyOnceProps = new Properties();
exactlyOnceProps.put("bootstrap.servers", "kafka1:9092,kafka2:9092");
exactlyOnceProps.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
exactlyOnceProps.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
exactlyOnceProps.put("acks", "all");
exactlyOnceProps.put("retries", "5");
exactlyOnceProps.put("enable.idempotence", "true");   // 启用幂等性
exactlyOnceProps.put("transactional.id", "txn-report-001"); // 事务 ID
exactlyOnceProps.put("transaction.timeout.ms", "60000");    // 事务超时

2.8 投递语义与死信队列的故障排查要点