聊聊 Kafka 的生产者消费者确认机制

一、生产者确认机制

消息从生产者客户端发送至 broker 服务端 topic，需要 ack 确认。acks与min.insync.replicas是两个配置参数.其中acks是 producer 的配置参数，min.insync.replicas是 Broker 端的配置参数，这两个参数对于生产者不丢失数据起到了很大的作用

ISR

In-sync replica(ISR)称之为同步副本，ISR 中的副本都是与 Leader 进行同步的副本，所以不在该列表的 follower 会被认为与 Leader 是不同步的。该同步副本的列表是一个动态的，根据副本与 leader 同步的情况动态增删。

acks 确认机制

acks 参数指定了必须要有多少个分区副本收到消息，生产者才认为该消息是写入成功的。

• acks=0，表示生产者在成功写入消息之前不会等待任何来自服务器的响应. 换句话说，一旦出现了问题导致服务器没有收到消息，那么生产者就无从得知，消息也就丢失了.

• acks=1，表示只要集群的 leader 分区副本接收到了消息，就会向生产者发送一个成功响应的 ack，此时生产者接收到 ack 之后就可以认为该消息是写入成功的. 一旦消息无法写入 leader 分区副本(比如网络原因、leader 节点崩溃),生产者会收到一个错误响应。

• acks =all,表示只有所有参与复制的节点(ISR 列表的副本)全部收到消息时，生产者才会接收到来自服务器的响应. 这种模式是最高级别的，也是最安全的，可以确保不止一个 Broker 接收到了消息. 该模式的延迟会很高.

对于消息的发送，支持同步阻塞、异步回调两种方式，一般建议是使用后者，提高应用的吞吐量。

二、消费者确认机制

在 Kafka 中，消费者确认是通过消费者位移的提交实现的。类似 RabbitMQ 的 ACK 机制。

消费者位移

每个 consumer 实例都会为它消费的分区维护属于自己的位置信息来记录当前消费了多少条消息。这在 Kafka 中有一个特有的术语：位移(offset)。

相比较将 offset 保存在服务器端(broker)，这样虽然简单，但是有如下的问题：

1. broker 变成了有状态的，增加了同步成本，影响伸缩性。

2. 需要引入应答机制来确定消费成功。

3. 由于需要保存众多 consumer 的 offset，可能需要引入复杂的数据结构，对资源有一定的浪费。

在 Kafka 中，消费者组(Consumer Group)负责管理分发消费消息，因此将 offset 保存在消费者组中是比较合适的选择。其数据格式只需要是特定格式的整形数据即可。

offset 对于 consumer 非常重要，因为它是实现消息交付语义保证(message delivery semantic)的基石。

消息交付语义即最多一次、最少一次、精确一次。

位移提交

consumer 客户端需要定期地向 Kafka 集群汇报自己消费数据的进度，这一过程被称为位移提交(offset commit)。位移提交这件事情对于 consumer 而言非常重要，它不仅表征了 consumer 端的消费进度，同时也直接决定了 consumer 端的消费语义保证。

新版的 Kafka 由 topic 管理提交的位移，该 topic 是__consumer_offsets。默认是有 50 个分区，编号从 0 到 49。

每个位移提交请求都会往__consumer_offsets 对应分区上追加写入一条消息。消息的 key 是 group.id、topic 和分区的元组，而 value 就是位移值。

提交方式

默认情况下，consumer 是自动提交位移的，自动提交间隔是 5 秒。这就是说若不做特定的设置，consumer 程序在后台自动提交位移。通过设置 auto.commit.interval.ms 参数可以控制自动提交的间隔。

手动位移提交就是用户自行确定消息何时被真正处理完并可以提交位移。在一个典型的 consumer 应用场景中，用户需要对 poll 方法返回的消息集合中的消息执行业务级的处理。用户想要确保只有消息被真正处理完成后再提交位移。如果使用自动位移提交则无法保证这种时序性，因此在这种情况下必须使用手动提交位移。设置使用手动提交位移非常简单，仅仅需要在构建 KafkaConsumer 时设置 enable.auto.commit=false，然后调用 commitSync 或 commitAsync 方法即可。

两者的区别与优劣如下：