kafka 什么是生产者的幂等性和事务？如何保证消息只被发送一次？

生产者的幂等性 (Idempotence)

幂等性是指一个操作无论执行一次还是多次，其结果都是相同的。在 Kafka 生产者的场景下，它确保即使生产者因网络问题等原因重试发送消息，该消息也只会被 Broker（消息代理）写入一次。

工作原理：

1. 生产者ID (PID) 和序列号 (Sequence Number)：当启用幂等性后，Kafka Broker 会为每个生产者实例分配一个唯一的生产者 ID (PID)。 生产者在发送每一批消息时，会为每个分区附加一个从0开始单调递增的序列号。
2. Broker 端的去重：Broker 会为每个分区记录下特定 PID 已成功写入的最高序列号。当 Broker 接收到新消息时，会检查其序列号：
   • 如果收到的序列号比记录的序列号大 1，说明是新消息，Broker 会接收它并更新记录的序列号。
   • 如果收到的序列号小于或等于记录的序列号，说明这是一条重复的消息（由生产者重试导致），Broker 会直接丢弃它，但仍然会像成功处理一样返回确认（ACK）给生产者。

如何启用幂等性：
只需在生产者的配置中设置一个参数即可：

enable.idempotence=true

启用幂等性后，生产者会自动将以下参数设置为保证消息可靠性的安全值：

• acks 会被设置为 all (或 -1)，确保消息被所有同步副本确认。
• retries 会设置为一个非常大的值 (Integer.MAX_VALUE)，以进行充分的重试。

幂等性的局限性：

• 单会话，单分区：幂等性只能保证单个生产者会话内，发送到单个分区的消息不会重复。 如果生产者进程重启，会获得新的 PID，幂等性保证就会失效。
• 无法跨分区原子操作：它无法保证需要原子性写入多个分区的操作。例如，在一个“消费-处理-生产”的应用中，如果处理一条消息后需要向两个不同的分区发送结果，幂等性无法保证这两次发送要么都成功，要么都失败。

生产者的事务 (Transactions)

为了克服幂等性的局限性，Kafka 引入了事务机制。事务提供了更强大的原子性保证，可以确保跨多个分区和主题的消息写入操作成为一个不可分割的单元——要么全部成功提交，要么全部失败回滚。

工作原理：

1. 事务ID (Transactional ID)：你必须为生产者配置一个唯一的、持久的 transactional.id。 这个 ID 能让 Broker 识别不同会话（即使生产者重启）的同一个逻辑生产者。 这解决了幂等性在生产者重启后失效的问题。
2. 事务协调器 (Transaction Coordinator)：在 Broker 端有一个名为“事务协调器”的组件，负责管理事务的状态。
3. 事务的原子性：生产者可以使用 beginTransaction(), commitTransaction(), 和 abortTransaction() 等 API 来管理事务的边界。在一个事务内发送的所有消息，都会被标记为待处理状态。
   • 提交 (Commit)：当生产者调用 commitTransaction()，协调器会执行一个两阶段提交协议，确保所有属于该事务的消息都对消费者可见。
   • 中止 (Abort)：如果发生错误或生产者调用 abortTransaction()，协调器会确保所有属于该事务的消息都被标记为已中止，消费者将永远不会读到这些消息（需要消费者设置 isolation.level="read_committed"）。
4. 僵尸隔离 (Zombie Fencing)：通过 transactional.id 和一个内部的 epoch 机制，Kafka 能够“隔离”掉旧的、可能因网络分区等原因仍在运行的生产者实例，防止它们提交无效的事务，从而保证数据一致性。

如何启用事务：

1. 设置 transactional.id:

   transactional.id=<YOUR_UNIQUE_TRANSACTIONAL_ID>
   

2. 启用事务会自动启用幂等性，所以不需要再显式设置 enable.idempotence=true。
3. 在消费端，需要将 isolation.level 配置为 read_committed，这样消费者就只能读取到已提交事务的消息。

总结：如何保证消息只被发送一次？

要实现端到端的“精确一次”处理（Exactly-Once Semantics, EOS），即消息从生产到消费的整个流程只被处理一次，需要结合使用 Kafka 的多种特性：

1. 对于简单的、仅需保证单分区不重复的场景：启用生产者的幂等性 (enable.idempotence=true) 就足够了。这可以有效防止因网络重试导致的消息重复。

2. 对于复杂的、需要原子性写入多个分区或“消费-处理-生产”模式的场景：必须使用事务。

   • 在生产者端配置一个唯一的 transactional.id。
   • 使用事务 API (beginTransaction, commitTransaction 等) 来包裹你的生产逻辑以及消费偏移量的提交。这样可以将“读取消息、处理消息、写入结果、提交消费偏移量”这几个步骤捆绑在一个原子事务中。
   • 在消费者端设置 isolation.level="read_committed" 来确保只消费已成功提交的事务消息。

通过幂等性和事务的结合使用，Kafka 能够在分布式系统中提供强大的“精确一次”交付保证。