持续学习&持续更新中…
守破离
【雷丰阳-谷粒商城 】【分布式高级篇-微服务架构篇】【22】【RabbitMQ】
Message Queue 消息队列
异步处理
应用解耦
这样不管库存系统的接口会不会发生改变，订单系统都不关心
流量控制
把用户请求流量存到消息队列中，后台服务根据它自身的处理能力去来进行消费处理，不会导致后台服务宕机
消息中间件概念
大多应用中，可通过消息服务中间件来提升系统异步通信、扩展解耦能力，消息服务中两个重要概念：消息代理（message broker）和目的地（destination）
当消息发送者发送消息以后，将由消息代理接管，消息代理保证消息传递到指定目的地。
消息队列主要有两种形式的目的地
- 队列（queue）：点对点消息通信（point-to-point）
- 主题（topic）：发布（publish）/订阅（subscribe）消息通信
点对点式：
- 消息发送者发送消息，消息代理将其放入一个队列中，消息接收者从队列中获取消息内容，消息读取后被移出队列
- 消息只有唯一的发送者和接收者
- 很多人都可以监听队列，但是，消息谁抢到就是谁的
发布订阅式：
- 发送者发送消息到主题，多个接收者（订阅者）监听（订阅）这个主题，那么就会在消息到达时，同时收到消息
- （订阅者都会收到消息）
JMS（Java Message Service）JAVA消息服务：基于JVM消息代理的规范。ActiveMQ、HornetMQ是JMS实现
AMQP（Advanced Message Queuing Protocol）高级消息队列协议，也是一个消息代理的规范，兼容JMS
RabbitMQ是AMQP的实现
RabbitMQ概念
RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue Protocol)的开源实现。
Message
消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成， 这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。
Publisher
消息的生产者，也是一个向交换器发布消息的客户端应用程序。
Exchange
交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
Exchange有4种类型：direct(默认)，fanout, topic, 和headers，不同类型的Exchange转发消息的策略有所区别
Queue
消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直 在队列里面，等待消费者连接到这个队列将其取走。
Binding
绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交 换器理解成一个由绑定构成的路由表。
Exchange 和Queue的绑定可以是多对多的关系。
Connection
网络连接，比如一个TCP连接。
客户端和消息中间件之间，一直保持一个长连接。1个客户端只会建立1条连接
长连接的好处：客户端宕机或下线，该长连接就会断开，RabbitMQ就会感知到，就不会再继续派发消息，可以防止大面积消息丢失问题。
Channel
（1条Connection上建立多个Channel，收发数据通过Channel进行）
信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚拟连接，AMQP 命令都是通过信道 发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。
因为对于操作系统来说建立和销毁 TCP 都 是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。
Consumer
消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。
Virtual Host
虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个Vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定、配置和权限机制。VHost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是
/
。
虚拟主机跟虚拟主机之间是相互隔离的。可以用于生产环境和开发环境隔离等
类比，RabbitMQ类似一个多租户系统，各个用户相互隔离。每一个 RabbitMQ 服务器都能创建 虚拟的消息服务器，称之为 虚拟主机（virtual host），简称 vhost。vhost 本质上是一个独立的小型 RabbitMQ 服务器，vhost 可避免队列和交换器等命名冲突，vhost 之间是绝对隔离的
Broker
表示消息队列服务器实体
图示
安装
docker run -d--name rabbitmq -p5671:5671 -p5672:5672 -p4369:4369 -p25672:25672 -p15671:15671 -p15672:15672 rabbitmq:management
docker update rabbitmq --restart=always
- https://www.rabbitmq.com/networking.html
- 4369, 25672 (Erlang发现&集群端口)
- 5672, 5671 (AMQP端口)
- 15672 (web管理后台端口)
- 61613, 61614 (STOMP协议端口)
- 1883, 8883 (MQTT协议端口)
RabbitMQ运行机制
AMQP 中的消息路由
AMQP 中消息的路由过程和 Java 开发者熟悉的 JMS 存在一些差别，AMQP 中增加了 Exchange 和Binding 的角色。生产者把消息发布到 Exchange 上，消息最终到达队列并被消费者接收，而 Binding 决定交换器的消息应该发送到那个队列。
Exchange类型
Exchange分发消息时根据类型的不同分发策略有区别，目前共四种类型：direct、fanout、topic、headers 。headers 匹配 AMQP 的消息 header 而不是路由键，headers 交换器和 direct 交换器完全一致，但性能差很多，目前几乎用不到了，所以直接看另外三种类型：
消息中的路由键（routing key）如果和 Binding 中的 binding key 一致， 交换器就将消息发到对应的队列中。
路由键与队列名完全匹配，如果一个队列绑定到交换机要求路由键为“dog”，则只转发 routing key 标记为“dog”的消息，不会转发“dog.puppy”，也不会转发“dog.guard” 等等。它是完全匹配的模式。
每个发到 fanout 类型交换器的消息都会分到所有绑定的队列上去。fanout 交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。很像子网广播，每台子网内的主机都获得了一份复制的消息。
fanout 类型转发消息是最快的。
topic 交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。 它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。
它同样也会识别两个通配符：符号“#”和符号“”，#匹配0个或多个单词，匹配1个单词。
练习
RabbitMQ整合
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-amqp</artifactId></dependency>
spring.rabbitmq.host=192.168.56.10
# 都有默认配置
#spring.rabbitmq.port=5672
#spring.rabbitmq.virtual-host=/
#spring.rabbitmq.username=guest
#spring.rabbitmq.password=guest
/**
* 使用RabbitMQ
* 1、引入amqp场景启动器；RabbitAutoConfiguration 就会自动生效
*
* 2、给容器中自动配置了
* RabbitTemplate、AmqpAdmin、CachingConnectionFactory、RabbitMessagingTemplate;
* 所有的属性都是 spring.rabbitmq
* @ConfigurationProperties(prefix = "spring.rabbitmq")
* public class RabbitProperties
*
* 3、给配置文件中配置 spring.rabbitmq 信息
*
* 4、@EnableRabbit: @EnableXxxxx；开启功能
*
* 5、监听消息：使用@RabbitListener；必须有@EnableRabbit
* @RabbitListener: 类+方法上（监听哪些队列即可）
* @RabbitHandler：配合@RabbitListener标在方法上（重载区分不同的消息）
*/@EnableRabbit
@ConfigurationpublicclassMyRabbitConfig{/**
* 使用JSON序列化机制，进行消息转换
*/@BeanpublicMessageConvertermessageConverter(){returnnewJackson2JsonMessageConverter();}
AmqpAdmin 管理组件
@TestpublicvoidcreateExchange(){/**
* DirectExchange(String name, boolean durable, boolean autoDelete, Map<String, Object> arguments)
*/Exchange directExchange =newDirectExchange("hello-java-exchange",true,false);
amqpAdmin.declareExchange(directExchange);
log.info("Exchange[{}]创建成功","hello-java-exchange");}@TestpublicvoidcreateQueue(){/**
* public Queue(String name, boolean durable, boolean exclusive, boolean autoDelete, Map<String, Object> arguments)
*/Queue queue =newQueue("hello-java-queue",true,false,false);
amqpAdmin.declareQueue(queue);
log.info("Queue[{}]创建成功","hello-java-queue");}@TestpublicvoidcreateBinding(){/**
* String destination【目的地】,
* DestinationType destinationType【目的地类型】,
* String exchange【交换机】,
* String routingKey【路由键】,
* Map<String, Object> arguments【自定义参数】
*
* 将exchange指定的交换机和destination目的地进行绑定，使用routingKey作为指定的路由键
*/Binding binding =newBinding("hello-java-queue",Binding.DestinationType.QUEUE,"hello-java-exchange","hello.java",null);
amqpAdmin.declareBinding(binding);
log.info("Binding[{}]创建成功","hello-java-binding");}
RabbitTemplate 消息发送处理组件
@TestpublicvoidsendMessageTest(){//1、发送消息，如果发送的消息是个对象，我们会使用序列化机制，将对象写出去。对象必须实现SerializableString msg ="Hello World!";
rabbitTemplate.convertAndSend("hello-java-exchange","hello.java", msg);// 2、发送的对象类型的消息，可以自动转成一个json【自定义MessageConverter即可】// OrderReturnReasonEntity reasonEntity = new OrderReturnReasonEntity();// reasonEntity.setId(1L);// reasonEntity.setCreateTime(new Date());// reasonEntity.setName("哈哈-"+ 666);// rabbitTemplate.convertAndSend("hello-java-exchange", "hello.java",// reasonEntity);
log.info("消息发送完成{}");}
CorrelationData：消息的唯一ID【可以放在数据库或者Redis中，方便之后判断哪些消息没有可靠抵达】
@RestControllerpublicclassRabbitController{@AutowiredRabbitTemplate rabbitTemplate;@GetMapping("/sendOneMq")publicStringsendOneMq(@RequestParam(value ="num", defaultValue ="10")Integer num){OrderReturnReasonEntity reasonEntity =newOrderReturnReasonEntity();
reasonEntity.setId(1L);
reasonEntity.setCreateTime(newDate());
reasonEntity.setName("哈哈");// CorrelationData：消息的唯一ID【可以放在数据库或者Redis中，方便之后判断哪些消息没有可靠抵达】
rabbitTemplate.convertAndSend("hello-java-exchange","hello.java", reasonEntity,newCorrelationData(UUID.randomUUID().toString()));return"ok";}
监听消息
@RabbitListener + @RabbitHandler （重载区分不同的消息）
@GetMapping("/sendMq")publicStringsendMq(@RequestParam(value ="num", defaultValue ="10")Integer num){for(int i =0; i < num; i++){if(i %2==0){OrderReturnReasonEntity reasonEntity =newOrderReturnReasonEntity();
reasonEntity.setId(1L);
reasonEntity.setCreateTime(newDate());
reasonEntity.setName("哈哈-"+ i);
rabbitTemplate.convertAndSend("hello-java-exchange","hello.java", reasonEntity,newCorrelationData(UUID.randomUUID().toString()));}else{OrderEntity entity =newOrderEntity();
entity.setOrderSn(UUID.randomUUID().toString());
rabbitTemplate.convertAndSend("hello-java-exchange","hello22.java", entity,newCorrelationData(UUID.randomUUID().toString()));}}return"ok";}
@RabbitListener(queues ={"hello-java-queue"})@Service("orderItemService")publicclassOrderItemServiceImplextendsServiceImpl<OrderItemDao,OrderItemEntity>implementsOrderItemService{@RabbitHandlerpublicvoidreceiveMessage(Message message,OrderReturnReasonEntity content,Channel channel)throwsInterruptedException{// 接收到消息...(Body:'{"id":1,"name":"哈哈-666","sort":null,"status":null,"createTime":1720438632794}' MessageProperties [headers={__TypeId__=com.atguigu.gulimall.order.entity.OrderReturnReasonEntity}, contentType=application/json, contentEncoding=UTF-8, contentLength=0, receivedDeliveryMode=PERSISTENT, priority=0, redelivered=false, receivedExchange=hello-java-exchange, receivedRoutingKey=hello.java, deliveryTag=1, consumerTag=amq.ctag-ltQ3IQ4H1lvLGqYNyEH3nQ, consumerQueue=hello-java-queue])System.out.println("@RabbitListener接收到消息..."+ message);// System.out.println("接收到消息...content："+content);// byte[] body = message.getBody();// //消息头属性信息// MessageProperties properties = message.getMessageProperties();// Thread.sleep(3000);// System.out.println("消息处理完成=>"+content.getName());}@RabbitHandlerpublicvoidreceiveMessage2(OrderEntity content)throwsInterruptedException{System.out.println("@RabbitHandler接收到消息..."+ content);}}
@RabbitListener写在方法上
@Service("orderItemService")publicclassOrderItemServiceImplextendsServiceImpl<OrderItemDao,OrderItemEntity>implementsOrderItemService{@RabbitListener(queues ={"hello-java-queue"})publicvoidreceiveMessage(OrderEntity content)throwsInterruptedException{System.out.println("接收到消息..."+ content);}}
注意
- Queue、Exchange、Binding可以 @Bean 注入进去
- 监听消息的方法可以有三种参数（不分数量，顺序）：Object content, Message message, Channel channel
- channel可以用来拒绝或者签收消息
RabbitMQ消息确认机制-可靠抵达
保证消息不丢失，可靠抵达，可以使用事务消息，这样性能会下降250倍，为此引入确认机制：
- publisher confirmCallback ：确认模式
- publisher returnCallback ：未投递到 queue 退回模式
- consumer 手动 ack 机制
发送端—ConfirmCallback
spring.rabbitmq.publisher-confirms=true
在创建 connectionFactory 的时候设置 PublisherConfirms(true) 选项，开启confirmcallback 。
CorrelationData：用来表示当前消息唯一性。
消息只要被 broker 接收到就会执行 confirmCallback，如果是 cluster 模式，需要所有 broker 接收到才会调用confirmCallback。
被 broker 接收到只能表示 message 已经到达服务器，并不能保证消息一定会被投递到目标 queue 里。所以需要用到接下来的 returnCallback 。
发送端—ReturnCallback
spring.rabbitmq.publisher-returns=true
spring.rabbitmq.template.mandatory=true
confrim 模式只能保证消息到达 broker，不能保证消息准确投递到目标 queue 里。在有些业务场景下，我们需要保证消息一定要投递到目标 queue 里，此时就需要用到return 退回模式。
这样如果消息未能投递到目标 queue 里将调用 returnCallback ，可以记录下详细到投递数据，定期的巡检或者自动纠错都需要这些数据。
发送端—代码配置
#服务端确认# 开启消息正确抵达RabbitMQ确认
spring.rabbitmq.publisher-confirms=true
# 开启RabbitMQ中的消息正确的从交换机投递到队列确认
spring.rabbitmq.publisher-returns=true
# 只要消息抵达队列，以异步方式优先回调ReturnCallbackspring.rabbitmq.template.mandatory=true
@ConfigurationpublicclassMyRabbitConfig{/**
* 使用JSON序列化机制，进行消息转换
*/@BeanpublicMessageConvertermessageConverter(){returnnewJackson2JsonMessageConverter();}privateRabbitTemplate rabbitTemplate;@Primary@BeanpublicRabbitTemplaterabbitTemplate(ConnectionFactory connectionFactory){RabbitTemplate rabbitTemplate =newRabbitTemplate(connectionFactory);this.rabbitTemplate = rabbitTemplate;
rabbitTemplate.setMessageConverter(messageConverter());initRabbitTemplate();return rabbitTemplate;}/**
* 定制RabbitTemplate
* 做好消息确认机制（publisher，consumer【手动ack】）
* 每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一遍
*
* 发送端确认：
* 1、Broker收到消息就回调【P——>B】
* 1、spring.rabbitmq.publisher-confirms=true
* 2、设置确认回调ConfirmCallback
* 2、消息没有正确抵达队列进行回调【E——>Q】
* 1、spring.rabbitmq.publisher-returns=true
* spring.rabbitmq.template.mandatory=true
* 2、设置确认回调ReturnCallback
*
*
* 消费端确认（保证每个消息被正确消费，此时broker才可以删除这个消息）。
* spring.rabbitmq.listener.simple.acknowledge-mode=manual #手动签收
* 默认是自动确认的：只要消息接收到，客户端会自动确认，服务端就会移除这个消息
* 问题：
* 我们收到很多消息，如果自动回复给服务器ack，当消息由于各种原因没有成功处理完成，就会发生消息丢失；
* 消费者手动确认模式：
* 只要我们没有明确告诉MQ消息被签收，消息就一直是unacked状态。
* 即使Consumer宕机，消息也不会丢失，会重新变为Ready状态，下一次有新的Consumer连接进来就发给他
* 如何签收:
* channel.basicAck(deliveryTag,false);业务成功，签收
* channel.basicNack(deliveryTag,false,true);业务失败，拒签，并让消息重新入队；
*/// @PostConstruct //MyRabbitConfig对象创建完成以后，也就是构造器执行完成后，执行这个方法publicvoidinitRabbitTemplate(){
rabbitTemplate.setConfirmCallback(newRabbitTemplate.ConfirmCallback(){/**
* P ——> B [Publisher ——> Broker]
*
* 只要消息抵达Broker这里的ack就为true
* @param correlationData 当前消息的唯一关联数据（这个是消息的唯一id，发布者发消息的时候传递的）
* @param ack 消息是否成功抵达Broker
* @param cause 失败的原因
*/@Overridepublicvoidconfirm(CorrelationData correlationData,boolean ack,String cause){//Broker收到了:修改消息的状态——>Broker接收到消息// System.out.println("confirm...correlationData[" + correlationData + "]==>ack[" + ack + "]==>cause[" + cause + "]");}});
rabbitTemplate.setReturnCallback(newRabbitTemplate.ReturnCallback(){/**
* E ——> Q [Exchange ——> Queue]
*
* 只要消息没有正确投递给指定的队列，就会触发这个失败回调
* @param message 投递失败的消息的详细信息
* @param replyCode 回复的状态码
* @param replyText 回复的文本内容
* @param exchange 当时这个消息发给了哪个交换机
* @param routingKey 当时这个消息指定的路由键
*/@OverridepublicvoidreturnedMessage(Message message,int replyCode,String replyText,String exchange,String routingKey){//报错了:修改数据库当前消息的状态——>队列接收消息发生错误// System.out.println("Fail Message[" + message + "]==>replyCode[" + replyCode + "]==>replyText[" + replyText + "]===>exchange[" + exchange + "]===>routingKey[" + routingKey + "]");}});}}
消费端
消费者获取到消息，成功处理，可以回复Ack给Broker
- basic.ack用于肯定确认；broker将移除此消息
- basic.nack用于否定确认；可以指定broker是否丢弃此消息，可以批量
- basic.reject用于否定确认；可以指定broker是否丢弃此消息，但不能批量
默认自动ack，消息被消费者收到，就会从broker的queue中移除
queue无消费者，消息依然会被存储，直到消费者消费。消费者收到消息，默认会自动ack。但是如果无法确定此消息是否被处理完成， 或者成功处理。我们可以开启手动ack模式spring.rabbitmq.listener.simple.acknowledge-mode=manual
- 消息处理成功，ack()，接受下一个消息，此消息broker就会移除
- 消息处理失败，nack()/reject()，重新发送给其他人进行处理，或者容错处理后ack，或者丢弃
- 消息一直没有调用ack/nack方法（比如宕机/程序出异常），broker认为此消息正在被处理，不会投递给别人，此时客户端断开，MQ感知到后，消息不会被broker移除，会重新入队并投递给别人
# 客户端确认：开启手动ack消息
spring.rabbitmq.listener.simple.acknowledge-mode=manual
/**
* 消费端确认（保证每个消息被正确消费，此时broker才可以删除这个消息）。
* spring.rabbitmq.listener.simple.acknowledge-mode=manual #手动签收
* 默认是自动确认的：只要消息接收到，客户端会自动确认，服务端就会移除这个消息
* 问题：
* 我们收到很多消息，如果自动回复给服务器ack，当消息由于各种原因没有成功处理完成，就会发生消息丢失；
* 消费者手动确认模式：
* 只要我们没有明确告诉MQ消息被签收，消息就一直是unacked状态。
* 即使Consumer宕机，消息也不会丢失，会重新变为Ready状态，下一次有新的Consumer连接进来就发给他
* 如何签收:
* channel.basicAck(deliveryTag,false);业务成功，签收
* channel.basicNack(deliveryTag,false,true);业务失败，拒签，并让消息重新入队；
*/
@RabbitListener(queues ={"hello-java-queue"})publicvoidreceiveMessage0(Message message,Channel channel){// multiple：是否批量// requeue=false 丢弃 requeue=true 发回服务器，让服务器重新入队该消息。// long deliveryTag, boolean multiple// channel.basicAck( deliveryTag, false); 只签收当前货物，不批量签收；// long deliveryTag, boolean multiple, boolean requeue// channel.basicNack( deliveryTag, false, true); 拒签当前货物【是否将该消息让MQ重新放入队列，看自己的业务需求】// long deliveryTag, boolean requeue// channel.basicReject( deliveryTag, true); 拒签当前货物【是否将该消息重新放回MQ看自己的业务需求】//DeliveryTag在channel内按顺序自增long deliveryTag = message.getMessageProperties().getDeliveryTag();System.out.println("deliveryTag==>"+ deliveryTag);//签收货物（消息），非批量模式try{if(deliveryTag %2==0){//收货
channel.basicAck(deliveryTag,false);System.out.println("签收了货物"+ message +"...deliveryTag..."+ deliveryTag);}else{//退货 requeue=false 丢弃 requeue=true 发回服务器，服务器重新入队。
channel.basicNack(deliveryTag,false,true);// channel.basicReject(deliveryTag, true);// channel.basicNack(deliveryTag, false, false);System.out.println("不签收货物"+ message +"...deliveryTag..."+ deliveryTag);}}catch(Exception e){//网络中断，签收信息未成功发送给Broker}}
消息的TTL（Time To Live）
消息的TTL就是消息的存活时间。
RabbitMQ给消息设置 TTL
- 通过队列设置：队列中的消息都有相同的过期时间
- 给消息本身设置：每条消息的 TTL 可以不同
如果队列设置了，消息也设置了，则最小的 TTL 生效。所以一个消息如果被路由到不同的队列中，这个消息死亡的时间有可能不一样（不同的队列设置）。
消息在队列中生存时间一旦超过 TTL，就会变成死信（Dead Message）
什么是死信
- 一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。（
basic.reject/ basic.nack）requeue=false - 消息的TTL到了，消息过期了。（没有人消费它）
- 队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上
延时队列
当消息在一个队列中变成死信之后，它能被发送到一个指定的交换机中，这个交换机就是 DLX （Dead Letter Exchange），可称为死信交换机。
绑定在 DLX 上的队列就称为死信队列。
我们既可以控制消息在一段时间后变成死信，又可以控制变成死信的消息被路由到某一个指定的交换机，这个交换机又可以绑定队列去消费死信，结合它们就可以实现一个延时队列
不推荐使用给消息设置过期时间这种方式实现延时队列
延时队列的实现
importorg.springframework.amqp.core.*;importorg.springframework.context.annotation.Bean;importorg.springframework.context.annotation.Configuration;importjava.util.HashMap;importjava.util.Map;@ConfigurationpublicclassMyMQConfig{//@Bean Binding，Queue，Exchange/**
* 容器中的 Binding，Queue，Exchange 都会自动创建（RabbitMQ没有的情况）
* RabbitMQ中已有的话 @Bean中声明属性发生了变化也不会覆盖
*/@BeanpublicQueueorderDelayQueue(){Map<String,Object> arguments =newHashMap<>();/**
* x-dead-letter-exchange: order-event-exchange
* x-dead-letter-routing-key: order.release.order
* x-message-ttl: 60000
*/
arguments.put("x-dead-letter-exchange","order-event-exchange");
arguments.put("x-dead-letter-routing-key","order.release.order");
arguments.put("x-message-ttl",60000);//String name, boolean durable, boolean exclusive, boolean autoDelete, Map<String, Object> argumentsreturnnewQueue("order.delay.queue",true,false,false,arguments);}@BeanpublicQueueorderReleaseOrderQueue(){returnnewQueue("order.release.order.queue",true,false,false);}@BeanpublicExchangeorderEventExchange(){//String name, boolean durable, boolean autoDelete, Map<String, Object> argumentsreturnnewTopicExchange("order-event-exchange",true,false);}@BeanpublicBindingorderCreateOrderBinding(){//String destination, DestinationType destinationType, String exchange, String routingKey,// Map<String, Object> argumentsreturnnewBinding("order.delay.queue",Binding.DestinationType.QUEUE,"order-event-exchange","order.create.order",null);}@BeanpublicBindingorderReleaseOrderBinding(){returnnewBinding("order.release.order.queue",Binding.DestinationType.QUEUE,"order-event-exchange","order.release.order",null);}}
importcom.atguigu.gulimall.order.entity.OrderEntity;importcom.rabbitmq.client.Channel;importorg.springframework.amqp.core.Message;importorg.springframework.amqp.rabbit.annotation.RabbitListener;importorg.springframework.amqp.rabbit.core.RabbitTemplate;importorg.springframework.beans.factory.annotation.Autowired;importorg.springframework.stereotype.Controller;importorg.springframework.web.bind.annotation.GetMapping;importorg.springframework.web.bind.annotation.PathVariable;importorg.springframework.web.bind.annotation.ResponseBody;importjava.io.IOException;importjava.util.Date;importjava.util.UUID;@ControllerpublicclassHelloController{@AutowiredRabbitTemplate rabbitTemplate;@RabbitListener(queues ={"order.release.order.queue"})publicvoidtestListenOrderRelease(OrderEntity order,Message message,Channel channel)throwsIOException{System.out.println("listenOrderRelease order : "+ order);System.out.println("listenOrderRelease message : "+ message);System.out.println("listenOrderRelease channel : "+ channel);
channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);}@ResponseBody@GetMapping("/test/createOrder")publicStringcreateOrderTest(){//订单下单成功OrderEntity entity =newOrderEntity();
entity.setOrderSn(UUID.randomUUID().toString());
entity.setModifyTime(newDate());//给MQ发送消息。
rabbitTemplate.convertAndSend("order-event-exchange","order.create.order", entity);return"ok";}}
如何保证消息可靠性
消息丢失
消息丢失出现的原因：
- 消息发送出去，由于网络问题没有抵达MQ服务器(Broker)- 发送者做好容错方法（try-catch），发送消息可能会网络失败，失败后要有重试机制；- 做好记录，每个消息发送出去后都应该记录到数据库
- 消息抵达Broker，Broker要将消息写入磁盘（持久化）才算成功。此时Broker尚未持久化完成就宕机。- publisher必须加入确认回调机制，回调后，根据是否成功，修改数据库消息的发送状态。- 做好定期重发，定期去数据库扫描未成功的消息进行重发
- 自动ACK的状态下。消费者收到消息，但没来得及处理完成消息宕机- 一定开启手动ACK，消费成功才移除，失败或者没来得及处理就noAck并重新入队
防止消息丢失：
- 做好消息确认机制（publisher，consumer【手动ack】）
- publisher将发送的消息都在数据库做好记录。定期从数据库扫描发送失败的消息，将它们再次发送
比如给数据库创建如下表，用来记录消息的发送状态：
CREATETABLE`mq_message`(`message_id`char(32)NOTNULL,`content`text,`to_exchange`varchar(255)DEFAULTNULL,`routing_key`varchar(255)DEFAULTNULL,`class_type`varchar(255)DEFAULTNULL,`message_status`int(1)DEFAULT'0'COMMENT'0-新建 1-已发送 2-错误抵达 3-已抵达',`create_time`datetimeDEFAULTNULL,`update_time`datetimeDEFAULTNULL,PRIMARYKEY(`message_id`))ENGINE=InnoDBDEFAULTCHARSET= utf8mb4
消息重复
- 消息消费失败，由于重试机制，自动又将消息发送出去。【这种情况允许重复】
- 成功消费，手动ack时宕机或者网络原因等等，消息由unack变为ready，Broker又重新发送 - 将消费者的业务消费接口设计为幂等的即可。比如要解锁库存先判断状态- 使用防重表（redis/mysql），发送消息每一个都有业务的唯 一标识，处理过就不用处理- rabbitMQ的每一个消息都有redelivered字段，可以获取是否是被重新投递过来的，而不是第一次投递过来的
Boolean redelivered = message.getMessageProperties().getRedelivered();
消息积压
- 消费者宕机积压
- 消费者消费能力不足积压
- 发送者发送流量太大 - 上线更多的消费者，进行正常消费- 上线专门的消费服务，将消息先批量取出来，记录数据库，离线慢慢处理
MQ对比
参考
雷丰阳: Java项目《谷粒商城》Java架构师 | 微服务 | 大型电商项目.
本文完，感谢您的关注支持！
本文转载自: https://blog.csdn.net/weixin_44018671/article/details/124542734
版权归原作者 lpruoyu 所有， 如有侵权，请联系我们删除。
版权归原作者 lpruoyu 所有， 如有侵权，请联系我们删除。