实战:如何防止mq消费方消息重复消费、rocketmq理论概述、rocketmq组成、普通消息的发送

简介: 实战:如何防止mq消费方消息重复消费如果因为网络延迟等原因,mq无法及时接收到消费方的应答,导致mq重试。(计算机网络)。在重试过程中造成重复消费的问题

实战:如何防止mq消费方消息重复消费

如果因为网络延迟等原因,mq无法及时接收到消费方的应答,导致mq重试。(计算机网络)。在重试过程中造成重复消费的问题解决思路:

1)如果消费方是做数据库操作,那么可以把消息的id,在重试的情况下,会触发主键冲突,从而避免数据出现脏数据。(也可以先用消息id或其他唯一标识去查找表是否存在数据,存在,不插入;不存在,插入)

2)如果消费方不是做数据库操作,可以借助第三方应用,如redis,来记录消费记录。每次消息被消费完成的时候,把当前消息的id作为key存入redis,每次消费前,先去redis查询有没有该消费记录

理论概述

rocketmq是消息中间件,是一种队列,先进先出。

主要实现异步功能生产者使用封装rocketmq的sendMsg发送消息到消息中间件完成了发送消息的过程。

消费者从mq中获取消息,进行消费。生产者和消费者之间是低耦合的,独立的完成自己的任务。

完成了异步和解耦

WHY?

解决了什么问题


之前如果一个订单服务分别调用支付服务、物流服务、库存服务等等里面的方法,如果说其中一个服务挂了,那么整个业务就无法执行的--------一般非核心业务。

那么mq实现解耦功能,让核心业务和非核心业务解耦,让各个服务解耦。这样即使一些比如物流服务挂了,支付业务还是能正常执行,后面对物流服务做一个补偿机制。


流量削峰,rockmq天生为高并发的秒杀服务的。没有使用mq的普通情况,多少请求就会到A系统,如果秒杀每秒5000次请求过去了,这个时候mysql说我最大只能每秒200请求,多了我受不了,系统接口直接查询慢或者卡住了直到超时。那么所有人都卡在这里,无法选出前200秒秒杀成功的用户。并且太多的请求堆积在A系统,最终可能导致A系统的崩溃。


而mq来了,你生产者可以生产出每秒5000次,5000次消息到mq了,mq本身是高并发请求接受率比较高的系统,可以解决高峰问题,生产者任务完成了,你没有事了。而我消费者一个服务一秒只能最大消费200请求,拉取消息200,先来的先消费,我这一秒只消费200,其他的消息你再等一等,我现在没空。知道所有消息消费完毕。


秒杀请求可以请求过来,但是要先到的200个我让你这一秒秒杀成功,后来的库存还有就可以消费,库存没有就秒杀结束。

保证了A系统的稳定性,“用时间换空间”。


维护性良好生产者业务改动的较少,一般改不同消费者去消费消息。很方便做到一些消息业务删除,增加,修改。

没有使用mq的以前模式,那么改动可能消费者服务改一下,生产者服务改一下,严格意义没有所谓的生产者、消费者一说。


补充:集群:多个服务器服务一个任务

微服务:一个服务对应一个任务,是分布式的一种方式。

rocketmq组成

rocketmq:
  accessKey: LTAI4FzV************
  secretKey: UzhGN*************************
  nameSrvAddr: localhost:8100;localhost:8100
  consumerGroups:
  - groupId: GID-********
    consumers:
      - topic: TOPIC-*****
        tag: DING-****
        beanName: one**************Listener
  - groupId: GID-***********
    consumers:
      - topic: TOPIC-*****
        tag: AD-*******
        beanName: user*********Listener

Group:分组,对消费者用处较大,比如分为物流组、库存组,每个消费者消费自己所在的组,互不干扰,相对独立进行。

Topic:主题,一类消息的主题或分类,电商可能衣服是个主题、鞋子是主题;也有根据业务服务来定义的,比如报告服务一类主题、采集服务一类主题、品牌服务一类主题。

消费队列:topic可以生成一条消息队列,也可以多条消息队列。


一个queue被一个consumer消费,并且messageQueue1---->consumer1,messageQueue2---->consumer2

提高了消费并发度。

tag:topic基础在还可以在分类,比如topic是手机,tag可以进一步细分苹果手机。

可以让指定消费者只消费苹果手机。

普通消息的发送

同步发送

确保发送成功,一些重要的消息,短信通知,应用消息通知,发送消息后,需要同步响应后再次发送消息。


异步发送

发送数据量大,对响应速度敏感的场景。

发送消息后不用等响应,接着可以发送消息。不会阻塞发送消息线程

单向发送

速度快,对可靠性要求不高

由于在 oneway 方式发送消息时没有请求应答处理,一旦出现消息发送失败,则会因为没有重试而导致数据丢失。

若数据不可丢,建议选用同步或异步发送方式。

普通消息

有集群消费和广播消费两种

集群消费用的多些,保证数据完整性。

全局消息

一个生产者-----》一个消费者

先进先出

部分顺序消息

一个生产者----->多个消费者

每个消费者对应消费不同的QueueX

所以称局部按照先进先出的原则来的。

延时消息

18个等级

message.setDelayTimeLevel(3);

定时

应用在付款关闭倒计时等

还有批量消息、过滤消息等操作。

来一个消费一个

普通消息属性关系

Offset:偏移量


相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
打赏
0
2
1
0
8
分享
相关文章
RocketMQ实战—10.营销系统代码优化
本文主要介绍了如何对营销系统的四大促销场景的代码进行优化,包括:全量用户推送促销活动、全量用户发放优惠券、特定用户推送领取优惠券消息、热门商品定时推送。
RocketMQ实战—8.营销系统业务和方案介绍
本文详细介绍了电商营销系统的业务流程、技术架构及挑战解决方案。涵盖核心交易与支付后履约流程,优惠券和促销活动的发券、领券、用券、销券机制,以及会员与推送的数据库设计。技术架构基于Nacos服务注册中心、Dubbo RPC框架、RocketMQ消息中间件和XXLJob分布式调度工具,实现系统间高效通信与任务管理。针对千万级用户量下的推送和发券场景,提出异步化、分片处理与惰性发券等优化方案,解决高并发压力。同时,通过RocketMQ实现系统解耦,提升扩展性,并利用XXLJob完成爆款商品推荐的分布式调度推送。整体设计确保系统在大规模用户场景下的性能与稳定性。
RocketMQ实战—8.营销系统业务和方案介绍
RocketMQ实战—9.营销系统代码初版
本文主要介绍了实现营销系统四大促销场景的代码初版:全量用户推送促销活动、全量用户发放优惠券、特定用户推送领取优惠券消息、热门商品定时推送。
RocketMQ实战—9.营销系统代码初版
RocketMQ实战—3.基于RocketMQ升级订单系统架构
本文主要介绍了基于MQ实现订单系统核心流程的异步化改造、基于MQ实现订单系统和第三方系统的解耦、基于MQ实现将订单数据同步给大数据团队、秒杀系统的技术难点以及秒杀商详页的架构设计和基于MQ实现秒杀系统的异步化架构。
RocketMQ实战—3.基于RocketMQ升级订单系统架构
RocketMQ实战—6.生产优化及运维方案
本文围绕RocketMQ集群的使用与优化,详细探讨了六个关键问题。首先,介绍了如何通过ACL配置实现RocketMQ集群的权限控制,防止不同团队间误用Topic。其次,讲解了消息轨迹功能的开启与追踪流程,帮助定位和排查问题。接着,分析了百万消息积压的处理方法,包括直接丢弃、扩容消费者或通过新Topic间接扩容等策略。此外,提出了针对RocketMQ集群崩溃的金融级高可用方案,确保消息不丢失。同时,讨论了为RocketMQ增加限流功能的重要性及实现方式,以提升系统稳定性。最后,分享了从Kafka迁移到RocketMQ的双写双读方案,确保数据一致性与平稳过渡。
RocketMQ实战—7.生产集群部署和生产参数
本文详细介绍了RocketMQ生产集群的部署与调优过程,包括集群规划、环境搭建、参数配置和优化策略。
RocketMQ实战—7.生产集群部署和生产参数
RocketMQ实战—2.RocketMQ集群生产部署
本文主要介绍了大纲什么是消息中间件、消息中间件的技术选型、RocketMQ的架构原理和使用方式、消息中间件路由中心的架构原理、Broker的主从架构原理、高可用的消息中间件生产部署架构、部署一个小规模的RocketMQ集群进行压测、如何对RocketMQ集群进行可视化的监控和管理、进行OS内核参数和JVM参数的调整、如何对小规模RocketMQ集群进行压测、消息中间件集群生产部署规划梳理。
RocketMQ实战—2.RocketMQ集群生产部署
RocketMQ实战—5.消息重复+乱序+延迟的处理
本文围绕RocketMQ的使用与优化展开,分析了优惠券重复发放的原因及解决方案。首先,通过案例说明了优惠券系统因消息重复、数据库宕机或消费失败等原因导致重复发券的问题,并提出引入幂等性机制(如业务判断法、Redis状态判断法)来保证数据唯一性。其次,探讨了死信队列在处理消费失败时的作用,以及如何通过重试和死信队列解决消息处理异常。接着,分析了订单库同步中消息乱序的原因,提出了基于顺序消息机制的代码实现方案,确保消息按序处理。此外,介绍了利用Tag和属性过滤数据提升效率的方法,以及延迟消息机制优化定时退款扫描的功能。最后,总结了RocketMQ生产实践中的经验.
RocketMQ实战—5.消息重复+乱序+延迟的处理
RocketMQ实战—4.消息零丢失的方案
本文分析了用户支付完成后未收到红包的问题,深入探讨了RocketMQ事务消息机制的实现原理及其在确保消息零丢失中的作用。首先,通过全链路分析发现消息可能在推送、存储或消费环节丢失。接着,介绍了RocketMQ事务消息机制如何通过half消息、本地事务执行及回调确认来保证消息发送成功,并详细解析了其底层原理,如half消息对消费者不可见、rollback与commit操作等。同时,对比了同步重试方案,指出其在复杂场景下的局限性。
RocketMQ实战—4.消息零丢失的方案
RocketMQ实战—1.订单系统面临的技术挑战
本文详细分析了一个订单系统的设计与技术挑战。首先,介绍了订单系统的整体架构、业务流程及负载情况,包括电商购物流程、核心和非核心业务流程,以及真实生产中的负载压力。接着,探讨了系统面临的主要技术问题:支付后发券、发红包等操作导致性能下降;退款流程复杂且易失败;与第三方系统耦合带来的不稳定;大数据团队直接查询数据库影响性能;秒杀活动时数据库压力剧增等。最后,通过放大100倍压力的方法,梳理了高并发下的技术挑战,如核心链路优化、后台线程补偿机制、第三方系统解耦、数据获取方式改进等,为订单系统的优化提供了全面的参考。
RocketMQ实战—1.订单系统面临的技术挑战
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等