Kafka 数据丢失分析

最新推荐文章于 2025-03-28 08:09:24 发布

原创最新推荐文章于 2025-03-28 08:09:24 发布 · 1.7k 阅读

3 ·

CC 4.0 BY-SA版权

Kafka 专栏收录该内容

4 篇文章

订阅专栏

问题：Kafka如何处理消息丢失的问题?

对于一般相当重要的数据的传输，对于Kafka 而言，需要考虑数据丢失性的问题的了。因此，如果保证Kafka 处理数据丢失的问题尤为重要。

从 Kafka学习笔记可以知道：Kafka是由三个部分组成：生产者 Producer、Broker节点服务器和消费者 Consumer。

Producer：消息生产者，向Broker推送消息的客户端。
Broker：一台Kafka服务器就是一个Broker。一个集群由多个Broker组成，一个Broker可以容纳多个 topic。
Consumer：消息消费者，向Broker拉去消息的客户端。

所以，在 Kafka 可能丢失数据的场景中，需要从这个三个组件分别来分析处理。

消费者 Consumer 丢失数据消息。

Kafka Consumer 是消息的消费者，其主要从 Broker 服务器获取数据，然后消费掉。这里 Consumer 丢失数据的情况一般是：消费者 Consumer 从 Broker 获取数据，默认情况下消费者 Consumer 会自动提交一个 offset 给 Broker 。但是如果消费者 Consumer 在消费在返回 offset 给 Broker 时，但是还未消费消息时，当前消费者 Consumer 突然崩溃了，那么 offset -1 到 offset 之间的数据还未被消费，数据还未被处理。当其他消费者 Consumer 接手工作时，Broker由于获取的是 offset 的消息，所以会将 offset +1 的数据发送过来，但是 offset 与 offset +1 之间的数据由于消费者 Consumer 崩溃而未被消费。

因此，需要将 offset 的的返回时间设置的相当短 auto.commit.interval.ms ，消费者 Consumer 频繁的、密集的将 offset 返回给 Broker。这是一种处理方式。但是如果消费的时间还是远小于这个返回的时间，那么数据消息依然会丢失。那么可以将自动提交 offset 改成手动模式。

手动模式（enable.auto.commit=false），即需要先关闭自动提交模式，由消费者 Consumer 自己处理完数据后在提交 offset，这样就能保证数据消息至少能被消费一次（涉及到重复消费的问题）。在正常模式下，每条数据消息只会被消费一次，但是如果消费者 Consumer 在消费完成后，手动提交之前，就崩溃了。那么这种情况就会发生数据消息至少被再次消费。也就是说这条数据消息因为不可控的原因被消费了多次。因此，对于多次消费的消息，只需要保证幂等性。

Broker 丢失数据消息

Broker 丢失数据比较直接，如果只有一个 Broker节点保存一条数据消息，如果当前Broker 节点突然挂掉了，那么消费者 Consumer 无法获取当前 Broker 数据而出现了数据丢失。

所以，针对 Broker 丢失数据情况，必须考虑备份。保证数据消息可以备份在多台 Broker 节点上。如果Kafka 集群考虑了备份方式来保护数据消息，但是如果Leader 已经获取了数据，但是还没有同步到其他 Broker 上进行备份，此时 Leader 突然崩溃，集群重新选取 Leader，然后 follower 根据新选出来的 leader进行同步备份。但是由于崩溃的 Leader 没有将数据消息同步出来，此时集群就出现了数据的丢失。

因此，为了防止 Broker 数据的丢失，需要考虑几个参数：

topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本；
设置min.insync.replicas参数：这个保证至少还以一个或一个以上 follower 节点与 leader 进行感知。不然 follower 全部挂了，如果 leader 再出问题，将会丢失数据。
设置acks=all，这个是保证每条数据被发送到 Broker上时，必须保证所有 follower都完成同步，才能认为数据写成功了。
设置retries=MAX，这就要求数据消息如果写入失败的话，就无线重试，直到数据写成功为止。

基于上述 4 点配置，就能保证Kafka Broker 不会丢失数据。