obsidian-sync/日常学习/中间件/MQ/kafka/kafka幂等.md

 当kafka producer 向 broker 中的 topic发送数据时，可能会因为网络抖动等各种原因，造成 producer 收不到 broker 的 ack 确认信息。此时 producer：
 1. producer 可以选择忽略没有收到 ack 确认消息，不做任何进一步处理：此时有可能会丢失消息。（之所以说有可能，是因为消息有可能没有写到 broker 的topic 中，但也有可能已经正确地写到了 broker 的 topic 中，只是回调的 ack 消息因网络抖动 producer 没有收到；）
 2. producer 也可以选择多次尝试重发消息，直到收到ack 确认消息或重试最大次数到达: 此时有可能会造成消息的重复写，即 broker 端的 topic 中，重复地存储了重试发送的这些消息；

- producer 重发没有收到 ack 确认的消息, 也可能会造成 broker 端 topic 的 partition 中 消息的顺序混乱，即因失败重发的消息在部分没有失败不需要重发的消息之后。
- 因 producer 重发没有收到 ack 确认的消息造成数据重复的问题，可以参见如下示意图，图中 message 7/8/9/10 即为重复的消息 

KAFKA 的幂等生产者即 idempotent producer，就是解决上述问题的：**它可以确保消息被正确地投递到 broker端，不会丢失没有重复，而且是以正确的顺序存储在 topic 的各个 partition 中**


# 幂等原理

首先需要说明下，在启用幂等生产者的情况下，消息失败时的重新发送，是由 kafka client 自动实现的，对我们来讲是透明的，我们不需要在代码中重试发送
其内部工作原理如下：

- 在 producer 端，每个 producer 都被 broker 自动分配了一个 Producer Id (PID)， producer 向 broker 发送的每条消息，在内部都附带着该 pid 和一个递增的 sequence number；
- 在 broker 端，broker 为每个 topic 的每个 partition 都维护了一个当前写成功的消息的最大 PID-Sequence Number 元组；
- 当 broker 收到一个比当前最大 PID-Sequence Number 元组小的 sequence number 消息时，就会丢弃该消息，以避免造成数据重复存储；
- 当 broker 失败重新选举新的 leader 时, 以上去重机制仍然有效：因为 broker 的 topic 中存储的消息体中附带了 PID-sequence number 信息，且 leader 的所有消息都会被复制到 followers 中。当某个原来的 follower 被选举为新的 leader 时，它内部的消息中已经存储了PID-sequence number 信息，也就可以执行消息去重了。

![[Pasted image 20231127102152.png]]