1.1 开发中消息队列应用场景:

1、任务异步处理

将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。提高了应用程序的响应时间。

2、应用程序解耦合

MQ相当于一个中介,生产方通过MQ与消费方交互,它将应用程序进行解耦合。

1.2 消息队列优点:

1.消息队列是应用程序之间的通信方法;

2.在项目中,可将一些无需即时返回且耗时的操作提取出来,进行异步处理,而这种异步处理的方式大大的节省了服务器的请求响应时间,从而提高系统吞吐量

3.可以实现程序之间的解耦合。

1.3 实现MQ的2种方式:

MQ是消息通信的模型;实现MQ的大致有两种主流方式:AMQP,JMS

AMQP:

AMQP是一种协议,更准确的说是一种binary wire-level protocol(链接协议)。这是其和JMS的本质差别,AMQP不从API层进行限定,而是直接定义网络交换的数据格式。

JMS:

JMS即Java消息服务(JavaMessage Service)应用程序接口,是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。

AMQP JMS 区别

  • JMS是定义了统一的接口,来对消息操作进行统一;AMQP是通过规定协议来统一数据交互的格式

  • JMS限定了必须使用Java语言;AMQP只是协议,不规定实现方式,因此是跨语言的。

  • JMS规定了两种消息模式;而AMQP的消息模式更加丰富

1.4 消息队列常见产品:

activeMQ,zeroMQ,RabbitMQ,RocketMQ,kafka

标签智能推荐:

RabbitMQ知识体系

参考视频:尚硅谷2021新版RabbitMQ教程丨快速掌握MQ消息中间件_哔哩哔哩_bilibili时长:11.5小时。

RabbitMQ学习01--基本概念

MQ全程MessageQueue,是在消息传输过程中保存消息的容器,多用于分布式系统之间进行通信。1、MQ的优势:1.应用解耦:系统耦合度越高,容错性就越低,可用性就越低。使用MQ将系统进行隔离,可以提高系统的容错性。2.异步提速:在用户进行操作后,将信息发送到MQ后就返回。后续的业务流程通过MQ异步进行处理。可以提高用户体验和系统吞吐量。3.削峰填谷:当大量消息集中进入系统时,可以用MQ将信息暂

MQ的适用场景、选择、术语和概念

目录前言MQ的适用场景MQ的选择MQ的术语和概念MQ的搭建导航前言MQ(MessageQueue)消息队列MQ的适用场景异步处理把一些耗时但不阻塞主流程的业务让MQ去做业务处理,提升用户体验流量削峰填谷秒杀场景,利用MQ控制流量,一旦超出阈值就丢弃请求或弹出错误页,防止应用被洪峰打死解耦微服务A服务调用B服务,B挂了,A的接口也无法正常返回,即使有Sentinel可以保护A不被B拖死,但接口依然无

RabbitMQ简单介绍及常见面试题

息,这种问题需要排查消费的逻辑是不是又问题,需要优化程序。解决思路:1.拆分MQ,生产者一个MQ,消费者一个MQ,写一个程序监听生产者的MQ模拟消费速度(譬如线程休眠),然后发送到消费者的MQ,如果消息积压则只需要处理生产者的MQ的积压消息,不影响消费者MQ2.拆分MQ,生产者一个MQ,消费者一个MQ,写一个程序监听生产者的MQ,定义一个全局静态变量记录上一次消费的时间,如果上一次时间和当前时间只

基于MQ的异步调用保证各服务间的分布式事务

己基于某个MQ中间件开发一个可靠消息服务,如果有高并发场景的,可以用RocketMQ的分布式事务支持,上面的那套流程都可以实现。 这套方案里保障高可用性最大的一个依赖点,就是MQ的高可用。任何一种MQ中间件都有一整套的高可用保障机制,无论是RabbitMQ、RocketMQ还是Kafka。如果MQ集群整体故障,完全不可用时,就会导致业务系统的各个服务之间无法通过MQ来投递消息,导致业务流

RabbitMQ学习-MQ(消息队列)的应用场景

据库后,再写入到MQ,然后通过监听MQ来生成elasticsearch对应的数据。3、用户下单后,24小时未支付,需要取消订单。以前我们可能是定时任务循环查询,然后取消订单。实际上,我更推荐类似延迟MQ的方式,避免了很多无效的数据库查询,将一个MQ设置为24小时后才让消费者消费掉,这样很大程度上能减轻服务器压力。4、支付完成后,需要及时的通知子系统(进销存系统发货,用户服务积分,发送短信)进行下一

接口的幂等性

幂等性概念:在编程中一个幂等操作的概念是其多次执行和一次执行的影响相同。接口的幂等性:是指一个接口的多次调用和一次调用对系统来说是没有影响的。场景:1.前端页面重复提交2.接口调用的超时重试机制,造成重复调用3.MQ消息中间件,消息的重复消费解决方案:1.token(redis方式) 2.数据库唯一索引3.乐观锁

Spring Boot 2.4版本前后的分组配置变化及对多环境配置结构的影响

,dev-mq""prod":"prod-db,prod-mq"---spring:config:activate:on-profile:"dev-db"db:dev-db.didispace.com---spring:config:activate:on-profile:"dev-mq"mq:dev-mq.didispace.com---spring:config:activate:on-pro

分布式事务解决方案之可靠消息最终一致性

志表中,可以启动独立的线程,定时对消息日志表中的消息进行扫描并发送至消息中间件,在消息中间件反馈发送成功后删除该消息日志,否则等待定时任务下一周期重试。3、消费消息如何保证消费者一定能消费到消息呢?这里可以使用MQ的ack(即消息确认)机制,消费者监听MQ,如果消费者接收到消息并且业务处理完成后向MQ发送ack(即消息确认),此时说明消费者正常消费消息完成,MQ将不再向消费者推送消息,否则消费者会

基于本地消息表的分布式事务

只要申请成功,就可以做其他事情。正常流程:系统接受到申请后,支付申请服务经过一些业务校验,先落支付申请库再将消息发送至MQ支付交易服务监听到MQ消息进行进一步的处理落库。但此时也有一些新的问题出现:若支付申请服务完成逻辑后,在投递消息到MQ中间件的过程中由于网络抖动等原因,没有投递到MQ中导致消息丢失了怎么办?MQ接收到消息后,由于内部原因导致消息丢失了怎么办?支付交易服务在监听消息的过程中,由于