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

目录
  • 1.消息丢失
    • 1.生产者发送失败
    • 2.消费者消费失败
    • 3.队列因为自身体原因丢失数据
  • 2.消息顺序
    • 1.kafka
    • 2.rocketMQ
    • 3.rabbitMQ
  • 3.消息重复

1.消息丢失

1.生产者发送失败

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

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

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

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

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

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

2.消费者消费失败

与生产者类似,若消费者在消费消息失败时未告知消息队列,此消息丢失。kafkarabbitMQrocketMQ都提供了相似的消费成功确认机制来解决这个问题,rabbitMQ通过auto_ack参数设置自动确认或手动确认。而rocketMQkafka通过消息偏移量来控制信息消费,rocketMQpull模式下需要自己维护偏移量。

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

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

2.消息顺序

1.kafka

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

(0)

相关推荐

  • RabbitMQ,RocketMQ,Kafka 事务性,消息丢失,消息顺序性和消息重复发送的处理策略

    目录 消息队列常见问题处理 分布式事务 什么是分布式事务 常见的分布式事务解决方案 基于MQ实现的分布式事务 本地消息表-最终一致性 MQ事务-最终一致性 RocketMQ中如何处理事务 Kafka中如何处理事务 RabbitMQ中的事务 消息防丢失 生产阶段防止消息丢失 RabbitMQ中的防丢失措施 Kafka中的防丢失措施 RocketMQ中的防丢失措施使用SYNC的发送消息方式,等待broker处理结果 存储阶段 RabbitMQ中的防丢失措施 Kafka中的防丢失措施 RocketMQ

  • 面试中canvas绘制图片模糊图片问题处理

    目录 问题:canvas绘制图片,图片变模糊 那么如何去处理这样的问题呢? 要点:两个点 解决方案 方法一 方法二 方法三 问题:canvas绘制图片,图片变模糊 设定一个一定尺寸的canvas,我这里设置的画布大小是400px*400px.当一张图片完全画到画布上的时候,大概率都会出现图片模糊的情况.我拿下面一张图片画到canvas上作为例子,看上去应该比较明显的有模糊的感觉. 单方面的去修改图片精度,换成更高清的图片,事实证明确实有一丢丢用,但是效果不是很明显.况且我当时那个图片由于是手绘的

  • 使用MQ消息队列的优缺点详解

    前言 公司的项目一直都是在使用MQ的,但是由于使用的功能很简单,所以一直都是知其然不知其所以然,作为一个程序猿有必要了解每一个使用的技术,为什么使用它?它的优点是什么?缺点是什么?等等... 使用mq的好处 解耦与复用 系统A要发送一个消息到多个系统,如果此时每增加一个系统,系统A都需要通过修改源码来增加接口,此时耦合非常高,但是如果中间使用消息队列的话,系统只需要发送一次到消息队列,别的系统就能复用该信息,当增加或删除系统调用接口的时候,不需要额外的更新代码. 异步 用户调用一个接口的时候,可

  • 大数据Kafka:消息队列和Kafka基本介绍

    目录 一.什么是消息队列 二.消息队列的应用场景 异步处理 应用耦合 限流削峰 消息驱动系统 三.消息队列的两种方式 点对点模式 发布/订阅模式 四.常见的消息队列的产品 1) RabbitMQ 2) activeMQ: 3) RocketMQ 4) kafka 五.Kafka的基本介绍 一.什么是消息队列 消息队列,英文名:Message Queue,经常缩写为MQ.从字面上来理解,消息队列是一种用来存储消息的队列 .来看一下下面的代码 上述代码,创建了一个队列,先往队列中添加了一个消息,然后

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

    目录 1.消息丢失 1.生产者发送失败 2.消费者消费失败 3.队列因为自身体原因丢失数据 2.消息顺序 1.kafka 2.rocketMQ 3.rabbitMQ 3.消息重复 1.消息丢失 1.生产者发送失败 所有消息队列都可能发生的问题 生产者发送消息后,队列未成功接收(网络原因或其他)而生产者不知情,消息丢失 生产者发送消息后,队列接收成功->生产者确认,但消息并未持久化,队列崩溃,消息丢失 针对这类问题,三种消息队列都提供了生产者消息发送确认的模式,例如将kafka的acks参数设置为

  • 分布式面试消息队列解决消息重复保证消息顺序

    目录 引言 1.面试官: 那你有考虑过消息重复问题怎么解决吗? 2.面试官: 在多集群消息架构中,如果消费端要求接收到的消息是有序的,怎么解决消息顺序消费问题? 3.面试官: 那如何做到topic不分区,能举例说明一下吗? 总结 引言 我在<项目中为什么要使用消息队列>中列举了两个使用消息队列的例子. (1)收银系统,确认收款成功,通过MQ通知给物流系统发货. (2)消费积分,用户每消费一笔给用户增加一定积分,京东豆,信用卡积分,2020年如果还没倒闭的电商平台中,可以100%的确定订单系统和

  • springboot中rabbitmq实现消息可靠性机制详解

    1. 生产者模块通过publisher confirm机制实现消息可靠性 1.1 生产者模块导入rabbitmq相关依赖 <!--AMQP依赖,包含RabbitMQ--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> <!-

  • RabbitMQ延迟队列及消息延迟推送实现详解

    这篇文章主要介绍了RabbitMQ延迟队列及消息延迟推送实现详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 应用场景 目前常见的应用软件都有消息的延迟推送的影子,应用也极为广泛,例如: 淘宝七天自动确认收货.在我们签收商品后,物流系统会在七天后延时发送一个消息给支付系统,通知支付系统将款打给商家,这个过程持续七天,就是使用了消息中间件的延迟推送功能. 12306 购票支付确认页面.我们在选好票点击确定跳转的页面中往往都会有倒计时,代表着 3

  • rabbitmq学习系列教程之消息应答(autoAck)、队列持久化(durable)及消息持久化

    目录 一.前言 二.autoAck参数的讨论 三.rabbitmq队列持久化操作 四.2019.11.04问题补充 五.2019.11.07消息的持久化 六.2022.02.09增加队列持久化说明 结语 一.前言 Boolean autoAck = false; channel.basicConsume(queue_name, autoAck ,consumer); 在simple queue 和 work queue(轮询) 处理中,我们设置的消费者的消息监听都采用 channel.basic

  • 如何利用rabbitMq的死信队列实现延时消息

    目录 前言 mq基本的消息模型 mq死信队列的消息模型 maven依赖 配置普通队列和死信队列 死信队列消费者 发送消息测试 测试成功 总结 前言 使用mq自带的死信去实现延时消息要注意一个坑点,就是mq只会检测队首的消息的过期时间,假设先放入队列10s过期消息,再放入2s过期. mq会检测头部10s是否过期,10s不过期的情况下,2s就算过去也不会跑到死信. mq基本的消息模型 mq死信队列的消息模型 简单的说就是先弄一个正常队列,然后不要设置消费者,接着给这个正常队列绑定一个死信队列,这个死

  • 使用Kotlin+RocketMQ实现延时消息的示例代码

    一. 延时消息 延时消息是指消息被发送以后,并不想让消费者立即拿到消息,而是等待指定时间后,消费者才拿到这个消息进行消费. 使用延时消息的典型场景,例如: 在电商系统中,用户下完订单30分钟内没支付,则订单可能会被取消. 在电商系统中,用户七天内没有评价商品,则默认好评. 这些场景对应的解决方案,包括: 轮询遍历数据库记录 JDK 的 DelayQueue ScheduledExecutorService 基于 Quartz 的定时任务 基于 Redis 的 zset 实现延时队列. 除此之外,

  • Springboot+rabbitmq实现延时队列的两种方式

    什么是延时队列,延时队列应用于什么场景 延时队列顾名思义,即放置在该队列里面的消息是不需要立即消费的,而是等待一段时间之后取出消费. 那么,为什么需要延迟消费呢?我们来看以下的场景 网上商城下订单后30分钟后没有完成支付,取消订单(如:淘宝.去哪儿网) 系统创建了预约之后,需要在预约时间到达前一小时提醒被预约的双方参会 系统中的业务失败之后,需要重试 这些场景都非常常见,我们可以思考,比如第二个需求,系统创建了预约之后,需要在预约时间到达前一小时提醒被预约的双方参会.那么一天之中肯定是会有很多个

  • 实战干货之基于SpringBoot的RabbitMQ多种模式队列

    目录 环境准备 安装RabbitMQ 依赖 连接配置 五种队列模式实现 1 点对点的队列 2 工作队列模式Work Queue 3 路由模式Routing 4 发布/订阅模式Publish/Subscribe 5 通配符模式Topics 总结 环境准备 安装RabbitMQ 由于RabbitMQ的安装比较简单,这里不再赘述.可自行到官网下载http://www.rabbitmq.com/download.html 依赖 SpringBoot项目导入依赖 <dependency> <gro

  • 微服务架构设计RocketMQ进阶事务消息原理详解

    目录 前言 RocketMQ事务流程概要 RocketMQ事务流程关键 实现 基础配置 引入组件 添加配置 发送半消息 执行本地事务与回查 消费消息 测试 总结 前言 分布式消息选型的时候是否支持事务消息是一个很重要的考量点,而目前只有RocketMQ对事务消息支持的最好.今天我们来唠唠如何实现RocketMQ的事务消息! Apache RocketMQ在4.3.0版中已经支持分布式事务消息,这里RocketMQ采用了2PC的思想来实现了提交事务消息,同时增加一个补偿逻辑来处理二阶段超时或者失败

随机推荐