关于MQ的几件小事(三)如何保证消息不重复消费

1.幂等性

幂等(idempotent、idempotence)是一个数学与计算机学概念,常见于抽象代数中。
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变。例如,“setTrue()”函数就是一个幂等函数,无论多次执行,其结果都是一样的.更复杂的操作幂等保证是利用唯一交易号(流水号)实现.

简单来说,幂等性就是一个数据或者一个请求,给你重复来了多次,你得确保对应的数据是不会改变的,不能出错。

2.出现重复消费场景

(1)首先,比如rabbitmq、rocketmq、kafka,都有可能会出现消息重复消费的问题。因为这个问题通常不是由mq来保证的,而是消费方自己来保证的。
(2)举例kafka来说明重复消费问题
kafka有一个叫做offset的概念,就是每个消息写进去,都有一个offset代表他的序号,然后consumer消费了数据之后,每隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了,下次就算重启,kafka就会让消费者从上次消费到的offset来继续消费。

但是万事总有例外,如果consumer消费了数据,还没来得及发送自己已经消费的消息的offset就挂了,那么重启之后就会收到重复的数据。

3.保证幂等性(重复消费)

要保证消息的幂等性,这个要结合业务的类型来进行处理。下面提供几个思路供参考:
(1)、可在内存中维护一个set,只要从消息队列里面获取到一个消息,先查询这个消息在不在set里面,如果在表示已消费过,直接丢弃;如果不在,则在消费后将其加入set当中。
(2)、如何要写数据库,可以拿唯一键先去数据库查询一下,如果不存在在写,如果存在直接更新或者丢弃消息。
(3)、如果是写redis那没有问题,每次都是set,天然的幂等性。
(4)、让生产者发送消息时,每条消息加一个全局的唯一id,然后消费时,将该id保存到redis里面。消费时先去redis里面查一下有么有,没有再消费。
(5)、数据库操作可以设置唯一键,防止重复数据的插入,这样插入只会报错而不会插入重复数据。

上一篇《如何保证消息队列的高可用

下一篇《如何防止数据队列数据丢失

原文地址:https://www.cnblogs.com/jack1995/p/10908805.html

时间: 2024-10-03 13:04:06

关于MQ的几件小事(三)如何保证消息不重复消费的相关文章

关于MQ的几件小事(一)消息队列的用途、优缺点、技术选型

1.为什么使用消息队列? (1)解耦:可以在多个系统之间进行解耦,将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯,只要该操作不是需要同步的,就可以改为使用MQ进行不同系统之间的联系,这样项目之间不会存在耦合,系统之间不会产生太大的影响,就算一个系统挂了,也只是消息挤压在MQ里面没人进行消费而已,不会对其他的系统产生影响. (2)异步:加入一个操作设计到好几个步骤,这些步骤之间不需要同步完成,比如客户去创建了一个订单,还要去客户轨迹系统添加一条轨迹.去库存系统更新库存.去客户系统修改

关于MQ的几件小事(六)消息积压在消息队列里怎么办

1.大量消息在mq里积压了几个小时了还没解决 场景:几千万条数据在MQ里积压了七八个小时,从下午4点多,积压到了晚上很晚,10点多,11点多.线上故障了,这个时候要不然就是修复consumer的问题,让他恢复消费速度,然后傻傻的等待几个小时消费完毕.这个肯定不行.一个消费者一秒是1000条,一秒3个消费者是3000条,一分钟是18万条,1000多万条. 所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概1小时的时间才能恢复过来. 解决方案:" 这种时候只能操作临时扩容,以更快的速

关于MQ的几件小事(四)如何保证消息不丢失

1.mq原则 数据不能多,也不能少,不能多是说消息不能重复消费,这个我们上一节已解决:不能少,就是说不能丢失数据.如果mq传递的是非常核心的消息,支撑核心的业务,那么这种场景是一定不能丢失数据的. 2.丢失数据场景 丢数据一般分为两种,一种是mq把消息丢了,一种就是消费时将消息丢了.下面从rabbitmq和kafka分别说一下,丢失数据的场景, (1)rabbitmq A:生产者弄丢了数据 生产者将数据发送到rabbitmq的时候,可能在传输过程中因为网络等问题而将数据弄丢了. B:rabbit

关于MQ的几件小事(七)如果让你设计一个MQ,你怎么设计

其实回答这类问题,说白了,起码不求你看过那技术的源码,起码你大概知道那个技术的基本原理,核心组成部分,基本架构构成,然后参照一些开源的技术把一个系统设计出来的思路说一下就好 比如说这个消息队列系统,我们来从以下几个角度来考虑一下 (1)首先这个mq得支持可伸缩性吧,就是需要的时候快速扩容,就可以增加吞吐量和容量,那怎么搞?设计个分布式的系统呗,参照一下kafka的设计理念,broker -> topic -> partition,每个partition放一个机器,就存一部分数据.如果现在资源不

关于MQ的几件小事(二)如何保证消息队列的高可用

1.RabbitMQ的高可用 RabbitMQ基于主从模式实现高可用.RabbitMQ有三种模式:单机模式,普通集群模式,镜像集群模式. (1)单机模式: 单机模式就是demo级别的,生产中不会有人使用. (2)普通集群模式 普通集群模式就是在多台机器上启动多个rabbitmq实例,每个机器启动一个.但是创建的queue只会放在一个rabbitmq实例上面,但是其他的实例都同步了这个queue的元数据.在你消费的时候,如果连接到了另一个实例,他会从拥有queue的那个实例获取消息然后再返回给你.

MQ如何解决消息的顺序问题和消息的重复问题?

一.摘要 分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 1.消息的顺序问题 2.消息的重复问题 二.关键特性以及其实现原理 2.1.顺序消息 要实现严格的顺序消息,简单且可行的办法就是: 保证生产者 - MQServer - 消费者是一对一对一的关系 这样的设计虽然简单易行,但也会存在一些很严重的问题,比如: 1.并行度就会成为消息系统的瓶颈(吞吐量不够) 2.更多的异常处理,比如:只要消费端出现问题,就会

消费端如何保证消息队列MQ的有序消费

消息无序产生的原因 消息队列,既然是队列就能保证消息在进入队列,以及出队列的时候保证消息的有序性,显然这是在消息的生产端(Producer),但是往往在生产环境中有多个消息的消费端(Consumer),尽管消费端在拉取消息时是有序的,但各个消息由于网络等方面原因无法保证在各个消费端中处理时有序. 场景分析 先后两次修改了商品信息,消息A和消息B先后同步写入MySQL,接着异步写入消息队列中发送消息,此时消息队列生产端(Producer)按时序先后发出了A和B两条消息(消息A先发出,消息B后发出)

单例模式不是一件小事,快回来看看

上次写了一篇<单例模式那件小事,看了你不会后悔>的文章,总结了常用的单例模式的实现.本文是上文的延续,单例模式绝不是一件小事,想弄清楚,真不是那么简单的.上文提到了常用的三种单例模式的实现方法:饿汉式(除了提前占用资源,没毛病.),懒汉式(DCL优化过后,没毛病?),静态内部类式(优雅的方法,没毛病.).文末最后还提到,反射会破坏单例. 本文继续,双重检查锁定优化过后的懒汉式,真的没毛病吗?其实不是,这里涉及到java编译器编译时的一些细节,对象初始化时的写操作与写入 sSingleton 字

响应式布局这件小事

讲到响应式布局, 相信大家都有一定的了解,响应式布局是今年很流行的一个设计理念,随着移动互联网的盛行,为解决如今各式各样的浏览器分辨率以及不同移动设备的显示效果, 设计师提出了响应式布局的设计方案.今天就和大家来讲讲响应式布局这件小事,包含什么是响应式布局.响应式布局的优点和缺点以及响应式布局该怎么设计(通 过CSS3 Media Query实现响应布局). 一.什么是响应式布局? 响应式布局是Ethan Marcotte在2010年5月份提出的一个概念,简而言之,就是一个网站能够兼容多个终端—