发布时间:2023-12-26 19:30
订单系统最多能处理一万次订单,但在高峰期,如果有两万此订单系统就处理不了了,只能限制订单超过一万后不允许用户下单,使用消息队列做缓冲,我们可以取消这个限制,把订单散成一段时间来处理,有时用户可能在下单几十秒后才能收到下单成功的操作,但总比不能下单的体验要好
以电商应用为例,应有应用中有订单系统,库存系统,物流系统,支付系统,用户创建订单后,任何一个子系统出现故障,都会造成下单操作异常,当转变成基于消息队列后,系统之间的调用问题就会减小很多,例如物流系统因为发生故障,需要几分钟来修理,在这几分钟内,物流系统要处理的内存被缓存在消息队列中,用户下单操作可以正常的完成,当物流系统恢复后,继续处理即可,用户感受不到物流系统的故障,提升系统的可用性
有些服务器之间的调用是异步的,使用消息队列,A调用B服务,只需要监听B处理完成的消息,当B处理完成后,会发送一条消息给MQ,MQ会把消息转发给A服务,这样A服务既不用循环调用B的查询Api,也不用提供callback api。同样B服务也不用做这些操作
rabbit是一个消息中间件:它接受并转发消息。
生产者
产生数据,发送消息,的程序是生产者
交换机
一方面它接受来自生产者的消息,另一方面他将消息推送到队列中。交换机必须确切知道如何处理它接受的消息,是将这些消息推送到特定队列还是推送到多个队列,亦或者把消息丢弃,这个得由交换机类型决定
队列
队列是RabbitMQ内部使用的一种数据结构
消费者
消费者大多时候是等待接收消息的程序
--------------------设计模式简单实现-----rabbit-mq (简单实现)_-小五-的博客-CSDN博客
图片参考官网 RabbitMQ Tutorials — RabbitMQ
简单模式:一个生产者,一个消费者,不涉及Exchange(交换机)
工作模式:一个生产者,多个消费者,消息被多个消费者竞争接收
(隐患:高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关
(syncronize)
发布订阅:一个生产者,多个消费者,消息复制多份,每个消费者接收相同的消息
路由模式:一个生产者,多个消费者,多个消费者根据路由类型分摊处理消息,减轻单个客户端的负载压力
主题模式:一个生产者,多个消费者,多个消费者根据路由类型分摊处理消息,此处的路由的*号做模糊匹配
头交换机模式:一个生产者,多个消费者,在消息头添加条件,匹配才被消费者接收使用
7 发布商确认
死信,无法消费的消息,有了死信自然就有了死信队列
应用场景:为保证订单业务数据不丢失,需使用死信队列,用户在商城下单成功并点击去支付后在指定时间没有支付时自动消失
死信来源:
消息TTL过期
队列达到了最大长度
消息被拒绝
延迟队列,队列内部是有序的,最重要的特性体现在它的延迟属性上,简单来说,用来存放需要在指定时间被处理的元素的队列
应用场景:
订单在十分钟之内未支付自动取消
新店铺,在10天内没上传过商品,则自动发送消息提醒
用户注册,三天没登录则进行短信提醒
当MQ服务停掉后消息生产者发送过来的消息不丢失,需要将队列消息都标记为持久化
整合:
RabbirMQ官网
尚硅谷课件
RabbitMQ七种工作模式_weixin_40877204的博客-CSDN博客