rabbitmq集成和实战

与 Spring 集成

pom 文件

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

 

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

rabbitmq集成和实战_第1张图片

 

 

 rabbitmq集成和实战_第2张图片

 

 

 

统一配置

配置文件中增加命名空间

rabbitmq集成和实战_第3张图片

 

 

 

连接相关配置:

  客户端连接

 rabbitmq集成和实战_第4张图片

  管理配置

 

 

 

生产者端(基础配置)

  RabbitTemplate

 

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

 

 

 

队列和交换器

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

 rabbitmq集成和实战_第5张图片   

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

 

 

 rabbitmq集成和实战_第6张图片

 

 

 rabbitmq集成和实战_第7张图片

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

 

消费者端(基础配置)

队列和交换器、

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

rabbitmq集成和实战_第8张图片

 

 

 

消费者 bean

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

 

 

注解定义

 rabbitmq集成和实战_第9张图片

 

 

 

监听容器

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

rabbitmq集成和实战_第10张图片

 

 

 

代码

消费者实现 MessageListener接口即可。

rabbitmq集成和实战_第11张图片

 

 

 

生产者端(高级配置)

发送者确认的回调

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

rabbitmq集成和实战_第12张图片

 

 

 rabbitmq集成和实战_第13张图片

 

 

 

失败通知的回调

实现方式和原生差不多

rabbitmq集成和实战_第14张图片

 

 

 rabbitmq集成和实战_第15张图片

消费者端(高级配置)

手动确认

  实现方式和原生差不多

rabbitmq集成和实战_第16张图片

 

 

 rabbitmq集成和实战_第17张图片

 

 

 

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

 

Qos

 rabbitmq集成和实战_第18张图片

 

 

与 SpringBoot 集成

pom 文件

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

 rabbitmq集成和实战_第19张图片

rabbitmq集成和实战_第20张图片

 

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

rabbitmq集成和实战_第21张图片

 

 

 

统一配置

配置连接相关配置

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

rabbitmq集成和实战_第22张图片

 

 

连接工厂使用

一个配置类

rabbitmq集成和实战_第23张图片

 

 rabbitmq集成和实战_第24张图片

 

 

RabbitTemplate

rabbitmq集成和实战_第25张图片

 

 

队列和交换器及绑定关系

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

 

默认交换器(direct)

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

rabbitmq集成和实战_第26张图片

 

 

Topic类型

rabbitmq集成和实战_第27张图片

 

 

Fanout类型

rabbitmq集成和实战_第28张图片

 

发送者失败通知

rabbitmq集成和实战_第29张图片

 

 

发送者确认的回调

 rabbitmq集成和实战_第30张图片

 

 

生产者

默认情况下(direct交换器绑定的队列)

HelloReceiver、UserReceiver

 

Topic交换器(绑定的队列)

TopicEmailMessageReceiver、TopicUserMessageReceiver

 

Fanout交换器(绑定的队列)

FanoutReceiver

 

消费者

默认情况下(direct交换器绑定的队列)

  HelloReceiver、UserReceiver

 

Topic交换器(绑定的队列)

  TopicEmailMessageReceiver、TopicUserMessageReceiverFanout交换器(绑定的队列)

  FanoutReceiver

 

演示效果

普通类型(direct 交换)测试

  http://localhost:8080/rabbit/hello

rabbitmq集成和实战_第31张图片

 

 

生产者

 rabbitmq集成和实战_第32张图片

 

消费者

简单消费者

 rabbitmq集成和实战_第33张图片

消费者手动确认

rabbitmq集成和实战_第34张图片

 

 
广播类型(Fanout 交换)测试

http://localhost:8080/rabbit/fanoutTest

 

 

生产者

 rabbitmq集成和实战_第35张图片

 

 

消费者

简单消费者

rabbitmq集成和实战_第36张图片

 

 

Topic 类型(topic 交换)测试

http://localhost:8080/rabbit/topicTest

rabbitmq集成和实战_第37张图片

 

 

实战-应用解耦

场景:

 rabbitmq集成和实战_第38张图片

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

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

 

RPC 实现

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

 

 

RabbitMQ 的实现

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

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

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

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

 

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

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

你可能感兴趣的:(rabbitmq集成和实战)