rabbitmq集成和实战

与 Spring 集成

pom 文件

　　使用 Maven，这里使用的 4.3.11，所以这里引入的是 rabbit 是 2.0.0，如果兼容性的话请自行去 Spring 的官网上去查

这里补充一下，spring 的引入也是对原生进行包装

统一配置

配置文件中增加命名空间

连接相关配置：

　　客户端连接

　　管理配置

生产者端（基础配置）

　　RabbitTemplate

或下面这种声明方式也是可以的。

队列和交换器

可以在生产者配置文件中增加队列和交换器

发送消息时，使用 rabbitTemplate即可。同时还可以给消息配置属性 MessageProperties。

这里重申一下，生产者和消费都可以申明交换器、申明队列、绑定关系，一般处理是生产者和消费者都相同配置，这样以防止万一，如果生产者或者消费者单独启动，发送或者消费数据不会出现问题。

消费者端（基础配置）

队列和交换器、

　　消费者中也可配置队列和交换器，以及指定队列和交换器绑定的路由键

消费者 bean

两种方式，一种配置文件，一种注解定义配置文件

注解定义

监听容器

将消费者 bean 和队列联系起来

代码

消费者实现 MessageListener接口即可。

生产者端（高级配置）

发送者确认的回调

　　实现方式和原生差不多，如下图代码见 rq-order 包中的配置

失败通知的回调

实现方式和原生差不多

消费者端（高级配置）

手动确认

　　实现方式和原生差不多

这里能够拿到信道 Channel 的话，具体操作就和原生一样。前面讲过的原生中的各种情况就可以根据你的业务场景来处理了。

Qos

与 SpringBoot 集成

pom 文件

这里 springboot 的版本我们使用 2.1.1，保持和我们一期讲解 Springboot 版本的一致性

这里 SpringBoot 也是对原生进行包装，同理与 Spring 中引入 RabbitMQ

统一配置

配置连接相关配置

　　这里包括虚拟机、发送方确认我们都加上

连接工厂使用

一个配置类

RabbitTemplate

队列和交换器及绑定关系

　　可以在生产者配置 RabbitConfig 类中增加队列和交换器

默认交换器（direct）

　　默认情况下，申明一个队列，如果没有建立与交换器的绑定关系，系统默认分配一个 Default 交换器（多个队列也是这一个），默认匹配队列名称

Topic类型

Fanout类型

发送者失败通知

发送者确认的回调

生产者

默认情况下（direct交换器绑定的队列）

HelloReceiver、UserReceiver

Topic交换器（绑定的队列）

TopicEmailMessageReceiver、TopicUserMessageReceiver

Fanout交换器（绑定的队列）

FanoutReceiver

消费者

默认情况下（direct交换器绑定的队列）

　　HelloReceiver、UserReceiver

Topic交换器（绑定的队列）

　　TopicEmailMessageReceiver、TopicUserMessageReceiverFanout交换器（绑定的队列）

　　FanoutReceiver

演示效果

普通类型（direct 交换）测试

　　http://localhost:8080/rabbit/hello

生产者

消费者

简单消费者

消费者手动确认

广播类型（Fanout 交换）测试

http://localhost:8080/rabbit/fanoutTest

生产者

消费者

简单消费者

Topic 类型（topic 交换）测试

http://localhost:8080/rabbit/topicTest

实战-应用解耦

场景：

　　用户下订单买商品，订单处理成功后，去扣减库存，在这个场景里，订单系统是生产者，库存系统是消费者。

　　库存是必须扣减的，在业务上来说，有库存直接扣减即可，没库存或者低于某个阈值，可以扣减成功，不过要通知其他系统（如通知采购系统尽快采购，通知用户订单系统我们会尽快调货）。

RPC 实现

通过 RPC 的实现，可以看到 RPC 会造成耦合。一旦库存系统失败，订单系统也会跟着失败。我们希望库存系统本身的失败，不影响订单系统的继续执行，在业务流程上，进行订单系统和库存系统的解耦。

RabbitMQ 的实现

　　对于我们消息模式的实现，为保证库存必须有扣减，我们要考虑几个问题：

　　1、订单系统发给 Mq 服务器的扣减库存的消息必须要被 Mq 服务器接收到，意味着需要使用发送者确认。

　　2、Mq 服务器在扣减库存的消息被库存服务正确处理前必须一直保存，那么需要消息进行持久化。

　　3、某个库存服务器出了问题，扣减库存的消息要能够被其他正常的库存服务处理，需要我们自行对消费进行确认，意味着不能使用消费者自动确认，而应该使用手动确认。

　　所以生产者订单系统这边需要，配置文件中队列和交换器进行持久化，消息发送时的持久化，发送者确认的相关配置和代码。

　　所以消费者库存系统这边要进行手动确认。