Kafka-ACK机制（ack应答原理、冥等性、事务）

喻师傅

已于 2024-05-16 16:08:42 修改

阅读量1.7k

点赞数 48

分类专栏： Kafka 文章标签： kafka 分布式消息队列

于 2024-05-16 15:58:53 首次发布

本文链接：https://blog.csdn.net/weixin_48935611/article/details/138961365

版权

Kafka 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

Kafka-ACK机制

在这里插入图片描述

Kafka中的ACK（Acknowledgement）机制是用于保证消息可靠传递的关键组件之一。在生产者发送消息到Kafka集群时，ACK机制决定了何时认为消息已经成功发送。这个机制非常重要，因为它影响了生产者对消息发送的信心以及消费者对消息接收的可靠性。

1.消息发送阶段：

生产者将消息发送到Kafka集群的一个主题（Topic）中的特定分区（Partition）。
在发送消息时，生产者可以指定ACK的级别，以决定何时认为消息已经成功发送。这个级别通常由acks参数控制。

2.ACK级别：

`acks=0`：

生产者不会等待来自服务端的任何确认。
消息被立即视为已发送，这意味着生产者不会等待任何确认，这是最轻量级的ACK级别，但也是最不可靠的。

`acks=1`：

生产者会在消息被领导者（Leader）接收后收到来自领导者的确认。
一旦领导者收到消息，就会立即向生产者发送确认，然后生产者就认为消息已经成功发送。
这种设置提供了一定程度的可靠性，因为只有领导者确认了消息，但是如果领导者接收消息后立即失效，消息可能会丢失。

`acks=-1`：

生产者会等待Leader和在ISR中的所有副本都收到消息后的确认。
这种设置提供了最高级别的可靠性，因为只有所有ISR中的副本都收到消息，才会发送确认。
ISR（In-Sync Replicas）：ISR 是指与 Leader 副本保持同步的 Followers 副本集合。
这意味着即使领导者失效，ISR中的其他副本也会确保消息被复制到足够多的地方，从而保证消息不会丢失。

3.生产者处理ACK：

生产者在发送消息后可以根据ACK的级别来决定下一步的操作。
如果ACK级别是acks=0，生产者不会等待确认，继续发送下一条消息。
如果ACK级别是acks=1，生产者会等待领导者的确认，然后继续发送下一条消息。
如果ACK级别是acks=-1，生产者会等待ISR中的所有副本都确认收到消息，然后继续发送下一条消息。

4.消费者处理ACK：

消费者通常会根据消息的ACK级别来决定消息何时被认为已经成功消费。
如果ACK级别是acks=0，消费者可能无法确定消息是否已经成功发送，因为生产者不会等待确认。
如果ACK级别是acks=1或acks=-1，消费者可以相对可靠地知道消息是否已经成功发送，并且可以在需要时请求重试或者处理失败。

5.数据可靠性分析

（1）ACK = 0

在这里插入图片描述

（2）ACK =1

在这里插入图片描述

（3）ACK=-1

在这里插入图片描述

Tips：

Leader收到数据，所有Follower都开始同步数据但有一个Follower，因为某种故障，迟迟不能与Leader进行同步，那这个问题怎么解决呢?

在这里插入图片描述

数据可靠性总结：

acks=0:生产者发送过来数据就不管了，可靠性差，效率高;
acks=1:生产者发送过来数据Leader应答，可靠性中等，效率中等
acks=-1，生产者发送过来数据Leader和ISR队列里面所有Follwer应答，可靠性高，效率低:
在生产环境中，acks=0很少使用:acks=1，一般用于传输普通日志，允许丢个别数据:acks=-1，一般用于传输和钱相关的数据对可靠性要求比较高的场景。

6.数据重复分析

在这里插入图片描述

冥等性

冥等性是指无论消息被发送多少次，结果都是相同的特性。
在Kafka中，冥等性确保生产者发送的消息不会因为网络问题、重试或其他原因而导致重复消息的发送。这种特性对于保证消息传递的可靠性至关重要。
冥等性的实现：在Kafka中，生产者可以通过设置enable.idempotence=true来启用冥等性。
当冥等性启用时，生产者会在消息上添加一个唯一的ID，并且记录已经发送的消息ID，以便在发生重试时避免重复发送相同的消息。
与ACK机制的关系：冥等性通常与ACK机制结合使用，以确保消息发送的幂等性。
即使在需要重试时，生产者也可以确保消息不会重复发送。
在ACK级别为acks=-1时，冥等性特别有用，因为它确保了消息只有在所有ISR副本都确认接收后才会被提交，避免了重复消息的可能性。

事务

Kafka的事务机制允许生产者发送一组相关的消息，并确保这组消息要么全部成功提交，要么全部回滚，从而实现消息传递的原子性。

0.11版本的Kafka同时引入了事务的特性，为了实现跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID，并将Producer获得的PID和Transaction ID绑定。
这样当Producer重启后就可以通过正在进行的Transaction ID获得原来的PID。

Kafka事务具有以下特性：

原子性（Atomicity）：事务要么全部成功提交，要么全部回滚，不会出现部分提交的情况。
一致性（Consistency）：事务在提交前可以确保消息的一致性，即所有消息都符合应用程序的预期状态。
隔离性（Isolation）：事务之间相互隔离，互不影响。
持久性（Durability）：已经提交的事务保证不会丢失。

事务的实现：

为了管理Transaction，Kafka引入了一个新的组件Transaction Coordinator。
Producer就是通过和Transaction Coordinator交互获得Transaction ID对应的任务状态。
Transaction Coordinator还负责将事务所有写入Kafka的一个内部Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

与ACK机制的关系：