kafka consumer 如何避免重复消费 kafka如何避免数据重复消费

转载

mob64ca1413c518 2024-08-07 08:34:31

文章标签 kafka 分布式数据消息发送 API 文章分类 架构后端开发

文章目录

Kafka

1. Kafka如何保证不丢失消息？

生产者数据的不丢失
消费者数据的不丢失
Kafka集群中的broker的数据不丢失

2. Kafka中的消息是否会丢失和重复消费？

1. 消息发送
2. 消息消费

3. Kafka 的设计是什么样的呢？
4. 数据传输的事务定义有哪三种
5. Kafka 怎么判断一个节点存活
6. 生产者是否直接将数据发送到 broker 的 leader (主节点)
7. Kafka 消费者是否可以消费指定分区消息？
8. Kafka 消息是采用 Pull 模式，还是 Push 模式？
9. Kafka 存储在硬盘上的消息格式是什么？（存疑）
10. 介绍一下kafka 的 ack 机制
11. Kafka 的消费者如何消费数据

Kafka

1. Kafka如何保证不丢失消息？

生产者数据的不丢失

如果是同步模式：

ack机制能够保证数据的不丢失，如果ack设置为0，风险很大，一般不建议设置为0。即使设置为1，也会随着leader宕机丢失数据。

producer.type=sync 
request.required.acks=1

如果是异步模式：

也会考虑ack的状态，除此之外，异步模式下的有个buffer，通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，有个选项是配置是否立即清空buffer。可以设置为-1，永久阻塞，也就数据不再生产。异步模式下，即使设置为-1。也可能因为程序员的不科学操作，操作数据丢失，比如kill -9，但这是特别的例外情况。

producer.type=async
request.required.acks=1
queue.buffering.max.ms=5000
queue.buffering.max.messages=10000 
queue.enqueue.timeout.ms = -1 
batch.num.messages=200

结论：producer有丢数据的可能，但是可以通过配置保证消息的不丢失。

消费者数据的不丢失

通过 offset commit 来保证数据的不丢失，Kafka自己记录了每次消费的offset数值，下次继续消费的时候，会接着上次的offset进行消费。

而offset的信息在Kafka0.8版本之前保存在Zookeeper中，在0.8版本之后保存到topic中，即使消费者在运行过程中挂掉了，再次启动的时候会找到offset的值，找到之前消费消息的位置，接着消费，由于 offset的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息。
唯一例外的情况是，我们在程序中给原本做不同功能的两个consumer组设置

Kafka SpoutConfig.bulider.setGroupid的时候设置成了一样的 groupid，这种情况会导致这两个组共享同一份数据，就会产生组A消费 partition1，partition2 中的消息，组B消费 partition3 的消息，这样每个组消费的消息都会丢失，都是不完整的。为了保证每个组都独享一份消息数据，groupid一定不要重复才行。

Kafka集群中的broker的数据不丢失

每个broker中的partition我们一般都会设置有replication（副本）的个数，生产者写入的时候首先根据分发策略（有partition按partition，有key按key，都没有轮询）写入到leader中，follower（副本）再跟leader同步数据，这样有了备份，也可以保证消息数据的不丢失。

2. Kafka中的消息是否会丢失和重复消费？

要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。

1. 消息发送

Kafka消息发送有两种方式：同步(sync)和异步(async)，默认是同步方式，可通过 producer.type属性进行配置。
Kafka通过配置 request.required.acks属性来确认消息的生产：

0---表示不进行消息接收是否成功的确认；
1---表示当Leader接收成功时确认；
-1---表示Leader和Follower都接收成功时确认；

综上所述，有6种消息生产的情况，下面分情况来分析消息丢失的场景：
(1) acks=0，不和 Kafka 集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；
(2) acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

2. 消息消费

Kafka 消息消费有两个 consumer 接口，Low-level API 和 High-level API：
Low-level API：消费者自己维护 offset 等值，可以实现对 Kafka 的完全控制；
High-level API：封装了对 parition 和 offset 的管理，使用简单；
如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“ 诡异”的消失了；
解决办法：
针对消息丢失：
同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；
异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；
针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。消息重复消费及解决参考：如何保证消息不被重复消费？（如何保证消息消费时的幂等性）

消息的重复消费问题，需要考虑幂等性，如果消费类型天生幂等，那么就没有必要去考虑重复消费的问题。
但是一般上 MQ 的任务都是一些比较耗时的任务，比如说调用第三方服务，此时可以采用第三方记录（redis），保存消息的唯一 id，定义消息的唯一id 以及时间戳的消费类型（待处理，过程中，失败/完成），如果是消费过程丢失，会导致消息长时间处于待处理的状态，我们可以另起一个定时任务，轮询一定时间间隔的任务，将它生产到兜底服务，由兜底服务去判断是否需要再次消费（比如说，一个 sms 服务，可以去查询当前消息 id 的短信是否已经成功发出，如果成功发出，则标记当前任务成功消费。）

3. Kafka 的设计是什么样的呢？

Kafka 将消息以主题为单位进行归纳。

将向 Kafka 主题发布消息的程序称为生产者。
将预订主题并消费消息的程序成为消费者。
Kafka 以集群的方式运行，可以由一个或多个服务组成，每个服务叫做一个 broker（中间人）。
生产者通过网络将消息发送到 Kafka 集群，集群向消费者提供消息

4. 数据传输的事务定义有哪三种

最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输；
最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输；
精确的一次（Exactly once）: 不会漏传输也不会重复传输，每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的。

5. Kafka 怎么判断一个节点存活

主要有两个条件

必须可以维护和 ZooKeeper 的连接，ZooKeeper 通过心跳机制检查每个节点的连接；
如果节点是个 follower，他必须能及时的同步 leader 的写操作，延时不能太久。

6. 生产者是否直接将数据发送到 broker 的 leader (主节点)

生产者直接将数据发送到 broker 的 leader(主节点)，不需要在多个节点进行分发，为了帮助 producer 做到这点，所有的 Kafka 节点都可以及时的告知，哪些节点是活动的，目标 topic 目标分区的 leader 在哪。这样 producer 就可以直接将消息发送到目的地了。

7. Kafka 消费者是否可以消费指定分区消息？

Kafka 消费消息时，向 broker 发出 “fetch” 请求去消费特定分区的消息，同时，consumer 还指定消息在日志中的偏移量（offset），这样就可以消费从这个位置开始的消息。
消费者拥有了 offset 的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的。

8. Kafka 消息是采用 Pull 模式，还是 Push 模式？

Kafka 遵循了一种大部分消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从 broker 拉取消息。

9. Kafka 存储在硬盘上的消息格式是什么？（存疑）

消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和 CRC32 校验码。

版本号: 1 byte
CRC 校验码: 4 bytes
具体的消息: n bytes

10. 介绍一下kafka 的 ack 机制

在Kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常被收到。
可以通过设置request.required.acks 决定 ack 策略。

0: 生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱。当 server 挂掉的时候就会丢数据；
1：服务端会等待 ack 值。leader 副本确认接收到消息后发送 ack 。如果 leader 挂掉后，不确保是否复制完成，也就是说新 leader 可能会丢失数据；
-1：同样在 1 的基础上，服务端会等所有的 follower 的副本收到数据后， leader 才会发出的 ack，这样数据就不会丢失。