Kafka数据丢失原因及解决方案

这篇具有很好参考价值的文章主要介绍了Kafka数据丢失原因及解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Kafka包括Producer、Broker、Consumer,因此从这三个方面分析。

Producer端

丢失原因:Kafka在Producer端的消息发送采用的是异步发送的方式(还有同步发送,但是同步发送会导致消息阻塞、需要等待),丢失数据是因为消息没有到达Broker端,原因可能是网络波动导致没有回调和数据消息太大超出Broker承受范围,导致Broker拒收消息。

解决方法:更换调用方式,不使用异步发送,使用带回调通知函数的方法进行发送消息,网络波动和消息过大,可以调整Producer端重试次数和消息大小。

丢失原因:Kafka默认ack设置为1,会存在数据丢失问题。(ack为0也会存在丢数据问题)

解决方法:修改ack设置为-1。(可以结合幂等性做到Exactly Once)

Broker端

丢失原因:数据从Producer端push过来后,Broker端需要将数据持久化存储到磁盘中,消息存储是异步存储的,即按照一定的消息数量和间隔时间进行存储,数据会先放在 PageCache 中,如果在存储的时候Broker宕机,此时选举了一个落后Leader Partition 很多的 Follower Partition 成为新的Lerder Partition,那么落后的消息就会丢失。

解决方法:修改参数,设置有资格成为Leader的Follower(落后太久的不要),设置分区数≥3(Leader宕机后可以有Follower补上),设置消息至少要被写入成功到ISR多少个副本才算“已提交”。

Consumer端

丢失原因:Consumer拉取消息后最终处理完需要提交 Offset,提交Offset有以下三种方式:

  1. 自动提交Offset。
  2. 拉取消息后,先提交offset、再处理消息,如果此时处理消息的时候宕机,由于Offset已提交,Consumer重启后会从之前已提交的offset 下一个位置开始消费,之前未处理的消息不会被再次处理,对于Consumer来说消息已经丢失。
  3. 拉取消息后,先处理消息、再提交Offset,如果此时在提交之前宕机,由于Offset没有提交,Consumer重启后会从上次的Offset重新拉取消息,不会丢失数据,但会出现重复消费的情况,这里只能业务自己保证幂等性。

方式2会导致数据丢失。

解决方法:使用先拉取消息、再处理消息、再提交offset的方法,并且设置参数 enable.auto.commit = false 使用手动提交位移的方式。文章来源地址https://www.toymoban.com/news/detail-629424.html

到了这里,关于Kafka数据丢失原因及解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 94、Kafka消息丢失的场景及解决方案

    1、ack=0,不重试 producer发送消息完,不管结果了,如果发送失败也就丢失了。 2、ack=1,leader crash producer发送消息完,只等待 leader 写入成功就返回了,leader crash了,这时follower没来及同步,消息丢失, 3、unclean .leader .election .enable 配置true 允许选举ISR以外的副本作为leader,会导

    2024年02月16日
    浏览(44)
  • 一文读懂kafka消息丢失问题和解决方案

    今天分享一下kafka的消息丢失问题,kafka的消息丢失是一个很值得关注的问题,根据消息的重要性,消息丢失的严重性也会进行放大,如何从最大程度上保证消息不丢失,要从生产者,消费者,broker几个端来说。 kafka生产者生产好消息后,会将消息发送到broker节点,broker对数据

    2024年02月08日
    浏览(49)
  • kafka乱序消费可能的原因和解决方案

    Kafka乱序消费可能的原因有以下几个: 分区顺序:Kafka中的消息按照分区进行存储和分发,每个分区内的消息是有序的,但不同分区之间的消息顺序是无法保证的。如果消费者在多个分区上进行并行消费,并且不处理消息的顺序,那么消费顺序可能会混乱。 消费者并发度:当

    2024年01月25日
    浏览(33)
  • Kafka rebalance 的几种原因与解决方案

    网上有很多文章讲述 Kafka rebalance 的原理,本文是列举常见的几种 rebalance 场景。 rebalance 期间,当前 consumer group 的所有 consumer 都要暂停消费,开销较大。因此应该尽量减少 rebalance ,而 relalance 的原因通常是 consumer 数量变化,常见的几种情况如下: 如果一个 consumer 刚启动,

    2024年02月01日
    浏览(52)
  • Kafka消息发送失败的常见原因及解决方案

    1.1、网络故障 网络故障是Kafka消息发送失败的最常见原因之一。当网络出现故障时,Kafka就无法将消息发送到目标主题或分区。 解决方法: - 检查网络连接是否正常。 - 增加Kafka生产者的重试次数和超时时间。 1.2、分区副本不可用 如果Kafka生产者将消息发送到一个不可用的分

    2024年02月03日
    浏览(63)
  • Kafka数据重复问题解决方案

    通常,消息消费时候都会设置一定重试次数来避免网络波动造成的影响,同时带来副作用是可能出现消息重复。 幂等性指: 幂等性使用示例: 为了更好理解,需要了解下Kafka幂等机制 这种设计针对解决了两个问题: 那什么时候该使用幂等: 事务使用示例:分为生产端 和

    2024年02月07日
    浏览(53)
  • RabbitMq消息丢失原因及其解决方案

    我们首先了解下一条消息从生产到消费的整个流程如下: 生产--MQ Broker -- 消费。所以这三个环节都有丢失消息的可能。 1.1、生产者丢失消息 生产者将数据发送到rabbitmq的时候,可能因为网络问题导致数据就在半路给搞丢了。 1.使用事务(性能差) ​ RabbitMQ 客户端中与事务机

    2024年02月08日
    浏览(45)
  • MQ消息丢失的可能原因与解决方案

    当我们使用消息队列(MQ)作为分布式系统中的核心组件时,消息丢失是一个常见的问题。消息丢失可能导致数据不一致或功能故障,因此对于许多应用程序来说是不可接受的。本文将介绍几种常见的MQ消息丢失的原因,并提供相应的解决方案。 生产者在发送消息时可能会遇

    2024年02月15日
    浏览(39)
  • Kafka数据倾斜到某一个分区解决方案

    我们使用Kafka时,某时需要消息消费是有序的,因此在生产者投递消息时,可能会指定分区,或者指定Key,此时可能会导致数据倾斜到某一个分区。 由于Kafka消费的特性,即一个消费组,那怕此时消费组有2个以上消费者,此时同一个主分区,只能被一个消费者消费,当生产消

    2024年02月13日
    浏览(56)
  • 带你了解RabbitMQ:消息丢失、重复、积压的原因及其解决方案

    前言 首先说一点,企业中最常用的实际上既不是RocketMQ,也不是Kafka,而是RabbitMQ。 RocketMQ很强大,但主要是阿里推广自己的云产品而开源出来的一款消息队列,其实中小企业用RocketMQ的没有想象中那么多。 深层次的原因在于兔宝在中小企业普及更早,经受的考验也更久,很容

    2024年02月04日
    浏览(36)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包