一、SpringBoot 中使用 RabbitMQ

1. 导入对应的依赖

		<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-amqp</artifactId></dependency>

2. 配置配置文件

spring:application:name: rabbitmq-springbootrabbitmq:host: 192.168.248.138port: 5672virtual-host: /emsusername: emspassword: 123456

​ RabbitTemplate 用来简化操作。使用时候直接在项目中注入即可使用。

3. 以 Topics 模型为例做案例解释

生产者（只需指定交换机给某路由指定信息）

@SpringBootTest(classes = BootRabbitmqApplication.class)
@RunWith(SpringRunner.class)
public class RabbitMQTest {// 注入 RabbitTemplate 对象@Resourceprivate RabbitTemplate rabbitTemplate;// topic@Testpublic void testTopic(){rabbitTemplate.convertAndSend("topics","myz.love.ly","Topic 模型 之 Myz 为您发送信息了");}
}

消费者（需要声明队列，绑定交换机路由与队列）

@Component
public class TopicConsumer {@RabbitListener(bindings = @QueueBinding(value = @Queue,exchange = @Exchange(value = "topics",type = "topic"),key = {"myz.*"}))public void receive1(String message) {System.out.println("message1 = " + message);}@RabbitListener(bindings = @QueueBinding(value = @Queue,exchange = @Exchange(value = "topics",type = "topic"),key = {"myz.#"}))public void receive2(String message) {System.out.println("message2 = " + message);}}

输出：message2 = Topic 模型 之 Myz 为您发送信息了

二、MQ的应用场景说明

异步处理

场景说明：用户注册后，需要发注册邮件和注册短信，传统的做法有两种 1. 串行的方式 2. 并行的方式

• 串行方式：将注册信息写入数据库后，发送注册邮件，在发送注册短信，以上三个任务全部完成后才返回给客户端。这里有一个问题是，邮件短信并不是必须的，它只是一个通知而已，而这种做法让客户端等待了没有必要等待的东西。

• 并行方式：将注册信息写入数据库后，发送邮件的同时，发送短信，以上三个任务完成后，返回给客户端，并行的方式能提高处理的时间。

• 消息队列：假设三个业务节点分别是50ms，串行方式使用150ms，并行时间使用100ms。虽然并行已经提高了处理的时间，但是，前面说了，短信和邮件对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功，应该是写入数据库后就返回。消息队列：引入消息队列后，把发送邮件，短信不是必须的业务逻辑异步处理。

应用解耦

场景：双11是购物狂欢节，用户下单后，订单系统需要通知库存系统，传统的做法就是订单系统调用库存系统的接口。

这样做法有一个缺点：当库存系统出现故障的时候，订单就会失败。订单系统和库存系统高耦合。引入消息队列。

• 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。
• 库存系统：订阅下单的消息，获取下单消息，进行库操作。就算库存系统出现故障，消息队列也能保证消息的可靠投递，不会导致消息丢失。

流量削峰

场景：秒杀活动，一般会因为流量过大，导致应用挂掉，为了解决这个问题，一般在应用前端加入消息队列。

作用：

1. 可以控制活动人数，超过此一定阀值的订单直接丢弃。
2. 可以缓解时间的高流量压垮应用（应用程序按自己的最大处理能力获取订单）

1. 用户的请求，服务器收到之后，首先写入消息队列，加入消息队列长度超过最大值时，则直接抛弃用户请求或者直接跳转到错误页面。
2. 秒杀业务根据消息队列中的请求消息，再做后续处理。