Kafka-Exactly-Once#

三种消息语义：

Kafka Exactly-Once 的两层实现：

1. 生产者幂等性（Idempotent Producer）

enable.idempotence=true  # Kafka 3.0 起默认开启（3.0.0/3.1.0 有 bug KAFKA-13598 未真正生效，3.0.1/3.1.1/3.2.0 修复）；与 acks/retries/in.flight 配置冲突且未显式开启时会自动关闭

• 每个 Producer 分配唯一的 PID（Producer ID）
• 每条消息附带单调递增的 Sequence Number
• Broker 根据 <PID, Partition, SeqNum> 去重，重复的消息不会被写入
• 范围：仅保证单 Producer、单 Partition、单 Session 的幂等

2. 事务（Transactional Producer + Consumer）

// 生产者
producer.initTransactions();
producer.beginTransaction();
try {
    producer.send(record1);
    producer.send(record2);
    producer.sendOffsetsToTransaction(offsets, groupMetadata); // 提交消费位移
    producer.commitTransaction();
} catch (Exception e) {
    producer.abortTransaction();
}

// 消费者
props.put("isolation.level", "read_committed"); // 只读已提交的消息

• 生产者需配置唯一的 transactional.id，用于跨会话（重启后）恢复身份并隔离「僵尸」旧实例（epoch 递增）
• 引入 Transaction Coordinator 和 __transaction_state 内部 Topic
• 将消息写入 + Offset 提交放在同一个事务中
• 消费者设置 isolation.level=read_committed，只读取已提交事务的消息
• 范围：保证跨 Partition、跨 Topic 的原子性

实际应用场景：

• Kafka Streams 内部使用事务实现 Exactly-Once 流处理（配置 processing.guarantee=exactly_once_v2；旧值 exactly_once/exactly_once_beta 在 3.0 废弃、4.0 移除）
• 消费-处理-生产（consume-transform-produce）模式

Kafka的Exactly-Once精确一次语义分两个层面实现。第一层是生产者幂等性，通过enable.idempotence=true开启后，每个Producer会被分配一个PID，每条消息附带单调递增的Sequence Number，Broker根据PID加Partition加SeqNum三元组去重，重复的消息不会被写入。但这只能保证单Producer、单Partition、单Session内的幂等。第二层是事务机制，通过initTransactions和beginTransaction将多条消息写入和offset提交放在同一个事务中，引入Transaction Coordinator和内部的__transaction_state Topic来管理事务状态，消费端设置isolation.level为read_committed只读取已提交事务的消息，这样就能保证跨Partition、跨Topic的原子性。Kafka Streams内部就是用事务来实现consume-transform-produce模式的Exactly-Once流处理。但需要强调的是，Kafka的Exactly-Once只管到Broker层面不重复写入，消费端的业务处理仍然需要做幂等性保证来兜底，比如通过数据库唯一键或Redis去重。

追问方向：

• “Kafka 幂等生产者和事务的区别？”→ 幂等生产者只保证单分区单会话内不重复（通过 PID+SequenceNumber 去重）；事务可跨分区跨 Topic 保证原子性，用于 consume-transform-produce 场景
• “Exactly-Once 对性能有多大影响？”→ 幂等生产者几乎无额外开销（Broker 端去重）；事务模式需要额外的 TransactionCoordinator 交互和两阶段提交，吞吐量下降约 3%-20%，延迟略增
• “消费端怎么配合实现端到端 Exactly-Once？”→ 设置 isolation.level=read_committed 只读已提交事务消息，配合消费者手动提交 offset 到事务中；或消费端自身做幂等（唯一 ID 去重/数据库唯一索引）

易错点：

• ❌ 开了幂等 Producer 就是端到端 Exactly-Once——幂等只保证单个 Producer 会话内、单分区不重复；Producer 重启（没配 transactional.id）或跨分区写都不在保证范围内，消费端处理也不在
• ❌ transactional.id 每次启动随机生成——它必须在实例重启后保持不变，Broker 才能通过 epoch 隔离旧实例（僵尸 Producer）；随机生成等于没有隔离
• ❌ Kafka 事务能覆盖写数据库等外部系统——事务只覆盖 Kafka 内部的「读-处理-写」；写 MySQL、调外部接口仍要靠业务幂等，或把 offset 和结果放进同一个数据库事务提交