消息队列(1)

本文探讨了消息队列在异步处理、解耦、削峰限流中的应用,介绍了其优势、常见问题及主流MQ中间件。深入剖析了高可用性、重复消费避免、消息丢失控制和有序消费等关键概念。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1 消息队列

1.1 什么是消息队列

消息队列,一般我们会简称它为MQ(Message Queue),简单理解为:把要传输的数据放在队列中。
在这里插入图片描述

  • 把数据放到消息队列叫做生产者
  • 从消息队列里边取数据叫做消费者

1.2 为什么需要消息队列(使用消息队列的优势)

场景举例:开发一个电商系统。
初始状态很简单,就是一个订单系统,下单——支付——结束。

异步

但是后期需要增加新需求,如优惠系统,积分系统,这样采用单体的形式耗时就会增加,需要消息队列中间件,即我下单系统只需要关注是否下单成功,不用管优惠系统的业务,将下单成功的消息写入到队列中即可。优惠系统需要什么从消息队列中取即可。
单体的系统如下:扩展后花费500ms
在这里插入图片描述
整个订单系统需要等待优惠、积分、短信等模块完成后才结束。
事实上,积分、优惠、发短信等行为不应该影响下订单这个动作。
使用消息队列后下单系统还是100ms
在这里插入图片描述

解耦

你一个订单流程,你扣积分,扣优惠券,发短信,扣库存。。。等等这么多业务都串联在一起,一个出现了问题,后面都受到影响,需要无数个try catch,代码冗长。又或者需要添加新的系统如抽奖系统,那么不应该还需要订单系统添加上抽奖系统的业务,而是抽奖系统自己知己消费消息队列中的数据,自己独立的一个系统。
采用上述的消息队列形式,即订单系统只管理好自己,短信系统出现问题应该由短信系统自己修改bug,添加短信业务功能等都不应该影响我的下单系统。这样各个系统就都解耦了。

削峰/限流

现在我们每个月要搞一次大促,大促期间的并发可能会很高的,比如每秒3000个请求。假设我们现在有两台机器处理请求,并且每台机器只能每次处理1000个请求。那多出来的1000个请求,可能就把我们整个系统给搞崩了…所以,有一种办法,我们可以写到消息队列中:
在这里插入图片描述
系统B和系统C根据自己的能够处理的请求数去消息队列中拿数据,这样即便有每秒有8000个请求,那只是把请求放在消息队列中,去拿消息队列的消息由系统自己去控制,这样就不会把整个系统给搞崩。

1.3 使用消息队列需要注意的问题

如何解决消息重复消费、消息丢失、消息的顺序消费等

1.4 主流的消息队列中间件

目前在市面上比较主流的消息队列中间件主要有,Kafka、ActiveMQ、RabbitMQ、RocketMQ 等这几种。

在这里插入图片描述

2 消息队列的高可用,重复消费、消息丢失、消息顺序、分布式事务

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值