kafka rabbitMQ及rocketMQ队列的消息可靠性保证分析

 更新时间:2022年05月09日 16:28:28   作者:冯子玉  
这篇文章主要介绍了kafka rabbitMQ及rocketMQ队列的消息可靠性保证分析,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

1.消息丢失

1.生产者发送失败

所有消息队列都可能发生的问题

  • 生产者发送消息后,队列未成功接收(网络原因或其他)而生产者不知情,消息丢失
  • 生产者发送消息后,队列接收成功->生产者确认,但消息并未持久化,队列崩溃,消息丢失

针对这类问题,三种消息队列都提供了生产者消息发送确认的模式,例如将kafka的acks参数设置为大于0,将rabbitMQ的信道设置为confirm模式。而在rocketMQ中会返回消息发送状态码。其中rabbitMQ和rocketMQ还提供了生产者事务操作。

只有某些消息队列才会发生的问题

  • kafka和rabbitMQ在集群状态下当前首领不可用时会进行首领选举。在kafka中,如果把acks设置为1(只要首领节点收到生产者发送的消息即确认发送成功)时,若当前首领收到的消息但还未同步至从任一节点就崩溃了,kafka会在还来不及判定的非同步从节点中选举出首领,这时消息丢失,解决方式是将acks设置未all,即全部从节点同步成功再确认。而在rabbitMQ中,新加入的镜像节点不会同步在此之前的消息,当老的消息还未完全消费完,老节点全部崩溃时,新节点被选举为首领时,会丢失所有未消费的旧消息(目前好像没有什么好的解决方式)。
  • kafka中,即使及时的将所有未同步消息的节点成功判定未非同步节点,也要在消息丢失和系统不可用之间做出权衡,如果不希望消息丢失,则在首领节点恢复前整个系统不可用,通过参数unclean.leader.election.enable可以设置非同步副本是否能成为首领节点。

  • rocketMQ集群环境下,broker主从使用异步复制模式时,若master节点崩溃且数据无法恢复,会丢失还未同步至从节点的部分消息,解决方式是使用同步双写的方式同步消息,但会降低吞吐率。

2.消费者消费失败

与生产者类似,若消费者在消费消息失败时未告知消息队列,此消息丢失。kafka,rabbitMQ,rocketMQ都提供了相似的消费成功确认机制来解决这个问题,rabbitMQ通过auto_ack参数设置自动确认或手动确认。

而rocketMQ和kafka通过消息偏移量来控制信息消费,rocketMQ在pull模式下需要自己维护偏移量。

3.队列因为自身体原因丢失数据

这个很好理解,例如rabbitMQ默认将消息保存再内存中,如果队列崩溃,消息自然丢失

2.消息顺序

1.kafka

kafka保证同一分区内消息的顺序,也就是说,如果要让某一topic内消息全部有序,只能为该topic设置一个分区,这会降低该主题的吞吐量。通常使用消息的key值将消息散布到不同分区上,以此保证消息的局部有序性,但这种局部有序性的保证仅仅在消息写入分区时是有序的才能保证,例如生产者按顺序消息写入消息A,消息B,消息A写入失败,消息B写入成功,生产者重发消息A且成功,这时候两个消息的顺序就颠倒了,解决方式是设定max.in.flight.requests.per.connection为1,指定生产者在收到消息成功发送的确认之前不允许发送其他信息,但这种方式也会严重降低吞吐量。

另一个问题是kafka默认的分区器使用散列算法将消息的key值映射到对映的分区上,如果增加了分区,key值映射的分区可能会与之前的不一致。在kafka中,一个分区只能被一个消费者消费,保证了消息消费的局部有序性。

2.rocketMQ

rocketMQ的队列(Message Queue)与kafka的分区在概念上相似,所以rocketMQ在消息有序性的保证上自然也是基于队列(Message Queue)的,同kafka一样,如果要让某一主题内的消息有序,必须将此主题内的独写队列数量设为1,但和kafka一样,这种操作会大量降低该主题的吞吐量。

rocketMQ中在发送消息时传入自定义的MessageQueueSelector保证消息生产的局部有序性,在消费消息时push模式下通过MessageListenerOrderly保证顺序消费。

3.rabbitMQ

对于rabbitMQ,我没有找到相关的资料,个人猜测,rabbitMQ同一队列内消息的有序性应该是有保障的,但大多数人会在生产者和消费者中增加消息有序性判断

3.消息重复

几乎所有的消息队列中都未能提供不重复消息的保证,而且消息重复与消息丢失几乎是二选一的问题,大多数情况下我们选择保证消息不丢失而容忍一部分消息重复,最广泛的解决消息重复的方式是在消费者端对消息进行验证或者保证消费的幂等性

以上就是kafka rabbitMQ及rocketMQ队列的消息可靠性保证分析的详细内容,更多关于kafka rabbitMQ rocketMQ消息队列的资料请关注脚本之家其它相关文章!

相关文章

  • Git回退到指定版本三种方法及常见的错误

    Git回退到指定版本三种方法及常见的错误

    在Git中回退到指定版本并不是删除或撤销之前的提交,而是创建一个新的提交,该提交包含指定版本的内容,这篇文章主要给大家介绍了关于Git回退到指定版本三种方法及常见的错误,需要的朋友可以参考下
    2024-03-03
  • 2019最新的Pycharm激活码(推荐)

    2019最新的Pycharm激活码(推荐)

    PyCharm 是一款功能强大的 Python 编辑器,具有跨平台性。这篇文章给大家介绍2019最新的Pycharm激活码,需要的朋友一起看看吧
    2019-10-10
  • Web 开发中遇到的UTF-8编码的问题总结

    Web 开发中遇到的UTF-8编码的问题总结

    一个网站如果需要国际化,就需要将编码从GB2312转成UTF-8,其中有很多的问题需要注意,如果没有转换彻底,将会有很多的编码问题出现!
    2010-02-02
  • git工具常用命令及ssh操作方法

    git工具常用命令及ssh操作方法

    这篇文章主要介绍了git工具常用到的命令以及非常详细的ssh操作方法,有需要的朋友可以借鉴参考下,希望可以有所帮助,祝大家能够多多进步,早日升职加薪
    2021-09-09
  • gitlab分支合并冲突的处理过程

    gitlab分支合并冲突的处理过程

    这篇文章主要介绍了gitlab分支合并冲突的处理过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2024-01-01
  • ApacheJMeter压力测试工具使用安装教程

    ApacheJMeter压力测试工具使用安装教程

    本文主要介绍了Apache JMeter的安装使用教程,Apache JMeter是开源软件,100%纯Java应用程序,旨在加载测试功能行为和测量性能。它最初设计用于测试Web应用程序,但后来扩展到其他测试功能
    2021-09-09
  • UTF-8 BOM 可能导致样式错乱的解决方法

    UTF-8 BOM 可能导致样式错乱的解决方法

    utf-8 是一种在web应用中经常使用的一种 unicode 字符的编码方式,使用 utf-8 的好处在于它是一种变长的编码方式,对于 ANSII 码编码长度为1个字节,这样的话在传输大量 ASCII 字符集的网页时,可以大量节约网络带宽。
    2009-06-06
  • Web开发人员常用速查手册 英文集合推荐

    Web开发人员常用速查手册 英文集合推荐

    不管你是多么优秀的程序员,你都不可能记住一切。在你编写程序的过程中碰到问题需要查阅手册的时候,若有现成的手册可参考则可以为你节省很多时间。
    2011-04-04
  • 通过Cursor工具使用GPT-4的方法详解

    通过Cursor工具使用GPT-4的方法详解

    Cursor 是集成了 GPT-4 的 IDE 工具,目前免费并且无需 API Key,支持 Win、Mac、Linux 平台,可以按要求生成代码,或者让 AI 帮助优化代码,分析代码,这篇文章主要介绍了通过Cursor工具使用GPT-4的方法,需要的朋友可以参考下
    2023-05-05
  • 2013年CIO需要知道的八句格言

    2013年CIO需要知道的八句格言

    2013年CIO需要知道的八句格言,更简单更努力
    2012-12-12

最新评论