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有以下三种方式:
- 自动提交Offset。
- 拉取消息后,先提交offset、再处理消息,如果此时处理消息的时候宕机,由于Offset已提交,Consumer重启后会从之前已提交的offset 下一个位置开始消费,之前未处理的消息不会被再次处理,对于Consumer来说消息已经丢失。
- 拉取消息后,先处理消息、再提交Offset,如果此时在提交之前宕机,由于Offset没有提交,Consumer重启后会从上次的Offset重新拉取消息,不会丢失数据,但会出现重复消费的情况,这里只能业务自己保证幂等性。
方式2会导致数据丢失。文章来源:https://www.toymoban.com/news/detail-629424.html
解决方法:使用先拉取消息、再处理消息、再提交offset的方法,并且设置参数 enable.auto.commit = false 使用手动提交位移的方式。文章来源地址https://www.toymoban.com/news/detail-629424.html
到了这里,关于Kafka数据丢失原因及解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!