目录
前言:
消息丢失的场景
生产者消息丢失
Broker消息丢失
消费者消息丢失
消息丢失问题排查
无消息丢失配置:
参考资料:
前言:
使用消息中间件时,我们遇到最头疼的事就消息丢失,小则影响程序错误,大则影响到某个重要业务失败。如果kafka配置不当或者使用不当,是很有可能出现消息丢失的。本篇博文重点探讨主要的kafka消息丢失的场景及我们应该如何配置kafka参数来避免消息的丢失。
消息丢失的场景
消息丢失无非分为3种,生产端消息丢失、kafka-broker端消息丢失、服务端消息丢失。
Kafka对于消息丢失这件事,只做了如下承诺,kafka只对已提交的消息做有限度的持久化保证。
生产者消息丢失
那生产者丢失,大多数就是因为,生产者不确定消息是否已经提交成功。如果使用不带
回调通知的send方法的话producer.send(msg),就无法保证消息被成功。所以我们应该使用带回调函数的send方法producer.send(msg,callback),这样我们就可以监听消息的发送情况,然后做有效的重试,确保消息都发送成功。
Broker消息丢失
对于kafka服务器端消息丢失,相对来说概率是比较小的,kafka作为一个成熟的中间件,经受业界的认可,但是需要注意,消息在borker中是由存在时长的,超过这个时间,默认会删除这些消息,另外对于分区的副本数也要进行合理设计,避免因为某一台机器的硬盘别破坏掉后,导致消息丢失。
消费者消息丢失
消费者消费丢失,大多数的场景为位移提交出现了问题,比如在消费者异步多线程消费消息,其中有个处理失败,位移提交失败,就会导致这个线程处理的消息丢失。
消息丢失问题排查
对于消息丢失的问题,首先,我们应该建立完整的日志,在消息发送前和发送后 、消费前后分别计日志, 建立告警机制。
无消息丢失配置:
- 不要使用producer.send(msg),而要使用producer.send(msg, callback)。记住,一定要使用带有回调通知的send方法。
- 设置acks = all。acks是Producer的一个参数,代表了你对“已提交”消息的定义。如果设置成all,则表明所有副本Broker都要接收到消息,该消息才算是“已提交”。这是最高等级的“已提交”定义。
- 设置retries为一个较大的值。这里的retries同样是Producer的参数,对应前面提到的Producer自动重试。当出现网络的瞬时抖动时,消息发送可能会失败,此时配置了retries > 0的Producer能够自动重试消息发送,避免消息丢失。
- 设置unclean.leader.election.enable = false。这是Broker端的参数,它控制的是哪些Broker有资格竞选分区的Leader。如果一个Broker落后原先的Leader太多,那么它一旦成为新的Leader,必然会造成消息的丢失。故一般都要将该参数设置成false,即不允许这种情况的发生。
- 设置replication.factor >= 3。这也是Broker端的参数。其实这里想表述的是,最好将消息多保存几份,毕竟目前防止消息丢失的主要机制就是冗余。
- 设置min.insync.replicas > 1。这依然是Broker端参数,控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于1可以提升消息持久性。在实际环境中千万不要使用默认值1。
- 确保replication.factor > min.insync.replicas。如果两者相等,那么只要有一个副本挂机,整个分区就无法正常工作了。我们不仅要改善消息的持久性,防止数据丢失,还要在不降低可用性的基础上完成。推荐设置成replication.factor = min.insync.replicas + 1。
- 确保消息消费完成再提交。Consumer端有个参数enable.auto.commit,最好把它设置成false,并采用手动提交位移的方式。就像前面说的,这对于单Consumer多线程处理的场景而言是至关重要的。
参考资料:
极客时间课程《kafka核心技术与实战》第11课文章来源:https://www.toymoban.com/news/detail-595875.html
无消息丢失配置如何实现?文章来源地址https://www.toymoban.com/news/detail-595875.html
到了这里,关于kafka无消息丢失配置的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!