4. 生产者可靠性：幂等性与事务性生产者

在 Kafka 消息可靠性体系中，生产者端是数据进入集群的第一道关口。本章聚焦生产者的两种核心可靠性机制——幂等性与事务性，并剖析常见发送失败场景的根因与应对策略。

4.1 幂等性（enable.idempotence）原理

幂等性解决的是“消息重复”问题。当生产者因网络抖动、Broker 端超时等原因重试发送时，可能导致同一条消息被写入多次。开启幂等性后，Kafka 保证每条消息在分区内仅被持久化一次，即使重试也不会产生重复。

4.1.1 核心机制：Producer ID + 序列号

• Producer ID（PID）：每个生产者会话启动时，由 Broker 分配一个全局唯一的 PID。
• 序列号（Sequence Number）：生产者为每个分区维护一个单调递增的序列号，从 0 开始。
• 去重校验：Broker 端为每个 (PID, Partition) 对缓存最近 5 个序列号。若收到序列号 ≤ 已提交的最大序列号，则判定为重复消息，直接丢弃。

4.1.2 幂等性适用边界

4.2 事务性生产者（transactional.id）配置

事务性生产者在幂等性基础上，实现了跨分区、跨会话的原子写入。它通过 transactional.id 标识一个事务上下文，即使生产者崩溃重启，也能保证事务状态不丢失。

4.2.1 核心组件与配置

4.2.2 事务生命周期 API

// 1. 初始化事务
producer.initTransactions();

// 2. 开启事务
producer.beginTransaction();

try {
    // 3. 发送消息到多个分区
    producer.send(new ProducerRecord<>("topic-a", "key1", "value1"));
    producer.send(new ProducerRecord<>("topic-b", "key2", "value2"));

    // 4. 提交事务
    producer.commitTransaction();
} catch (Exception e) {
    // 5. 中止事务
    producer.abortTransaction();
}

4.3 常见发送失败场景与排查

即使配置了幂等性或事务，生产者在高并发、网络异常、Broker 故障等场景下仍可能遇到发送失败。以下列出典型场景及根因分析。

4.3.1 失败场景分类

4.3.2 事务性生产者 fencing 机制

当两个生产者实例使用相同的 transactional.id 时，后启动的实例会通过 epoch 递增 将旧实例“围堵”（fencing），旧实例后续所有事务操作都会抛出 ProducerFencedException。这是防止僵尸生产者写入的关键设计。

4.4 压测中的可靠性验证要点

• 幂等性验证：在压测中注入网络抖动（如通过 TC 工具模拟丢包），对比开启/关闭幂等性时的消息重复率。
• 事务原子性验证：在事务提交前强制 Kill 生产者进程，检查目标分区是否出现部分写入（应无脏数据）。
• Fencing 测试：启动两个相同 transactional.id 的生产者，验证旧生产者是否被正确围堵，新生产者是否正常写入。
• 超时边界测试：设置极短的 transaction.timeout.ms（如 5s），观察事务超时后的自动中止行为。