《Spring Boot 实战派》--12.集成RabbitMQ,实现系统间的 数据交换

第12章 集成RabbitMQ,实现系统间的数据交换

RabbitMQ是近年来使用非常广泛的消息中间件。

本章首先介绍它的原理、概念、6种工作模式、常用的注解；

然后用实例讲解在Spring Boot 中如何使用AmqpTemplate接口实现消息的发送和监听。

12.1 认识 RabbitMQ

12.1.1 介绍 RabbitMQ

RabbitMQ 是开源的高级消息队列协议(Advanced Message Queueing Protocol, AMQP) 的实现，用Erlang语言编写，支持多种客户端。

RabbitMQ是目前应用相当广泛的消息中间件(其他同类的消息处理中间件有ActiveMQ、

Kafka等)。在企业级应用、微服务应 用中，RabbitMQ担当着十分重要的角 色。例如，在业务服务模块中解耦' 异 步通信、高并发限流、超时业务、数据 延迟处理等都可以使用RabbitMQo

RabbitMQ的处理流程如图

12.1.2使用场景

1、推送通知

“发布/订阅”是RabbitMQ的重要功能。可以用“发布/订阅”功能来实现通知功能。消费者 （consumer）-直监听RabbitM Q的数据。如果RabbitM Q有数据，则消费者会按照“先进先出” 规则逐条进行消费。而生产者（producer）只需要将数据存入RabbitMQ。这样既降低了不同系统 之间的耦合度，也确保了消息通知的及时性，且不影响系统的性能。

“发布/订阅”功能支持三种模式：一对一、一对多、广播。这三种模式都可以根据规则选择分发的对象。众多消费者（consumer）可以根据规则选择是否接收这些数据，扩展性非常强。

2、异步任务

        后台系统接到任务后，将其分解成多个小任务，只要分别完成这些小任务，整个任务便可以完 成。但是，如果某个小任务很费时，且延迟执行并不影响整个任务，则可以将该任务放入消息队列 中去处理，以便加快请求响应时间。

        如果用户注册会员时有一项需求——发送验证邮件或短信验证码以完成验证，则可以使用 RabbitMQ的消息队列来实现，这样可以及时提醒用户操作已经成功。等待收到邮件或验证码，然 后进行相应的确认，即完成验证。

3、多平台应用的通信

        RabbitMQ可以用于不同开发语言开发的应用间的通信（如Java开发的应用程序需要与C++ 开发的应用程序进行通信），实现企业应用集成。由于消息队列是无关平台和语言的，而且语义上也 不是函数调用，因此RabbitMQ适合作为多个应用之间的松耦合的接口，且不需要发送方和接收方同时在线。

不同语言的软件解耦，可以最大限度地减少程序之间的相互依赖，提高系统可用性及可扩展性, 同时还增加了消息的可靠传输和事务管理功能。

RabbitMQ提供两种事务模式：

• AMQP事务模式。
• Confirm事务模式。

4、消息延迟

        利用RabbitMQ消息队列延迟功能，可以实现订单、支付过期定时取消功能。因为延迟队列存 储延时消息，所以，当消息被发送以后，消费者不是立即拿到消息，而是等待指定时间后才拿到这个消息进行消费。

        当然，死信、计时器、定时任务也可以实现延迟或定时功能，但是需要开发者去处理。

        要实现消息队列延迟功能，一般采用官方提供的插件“rabbitmq_delayed_message_ exchange"来实现，但RabbitMQ版本必须是3.5.8版本以上才支持该插件。如果低于这个版本， 则可以利用“死信”来完成。

5、远程过程调用

        在实际的应用场景中，有时需要一些同步处理，以等待服务器端将消息处理完成后再进行下一 步处理，这相当于RPC ( Remote Procedure Call,远程过程调用)。RabbitMQ也支持RPC

12.1.3特性

RabbitMQ具有以下特性。

• 信息确认：RabbitMQ有以下两种应答模式。
• 自动应答：当RabbitMQ把消息发送到接收端，接收端从队列接收消息时，会自动发送 应答消息给服务器端。
• 手动应答：需要开发人员手动调用方法告诉服务器端已经收到。

        

    注：   如果实际场景中对个别消息的丢失不是很敏感，则选用自动应答比较理想。

             如果是一个消息都不能丢的场景，则需要选用手动应答，在正确处理完以后才应答。

如果选择了自动应答，那消息重发这个功能就没有了；

• 队列持久化：队列可以被持久化，但是否为持久化，要看持久化设置。
• 信息持久化：设置properties.DeliveryMode值即可。默认值为1,代表不是持久的，2代表持久化。
• 消息拒收：接收端可以拒收消息，而且在发送“reject”命令时，可以选择是否要把拒收的消息重新放回队列中。
• 消息的QoS：在接收端设置的。发送端没有任何变化，接收端的代码也比较简单，只需要加上如 “channel.BasicQos(0, 1, false);"的代码即可。

12.2 RabbitMQ的基本概念

12.2.1生产者、消费者和代理

RabbitMQ的角色有以下三种。

• 生产者：消息的创建者，负责创建和推送数据到消息服务器。
• 消费者：消息的接收方，用于处理数据和确认消息。
• 代理：RabbitMQ本身，扮演“快递”的角色，本身不生产消息。

注： 生产者和消费者并不属于RabbitMQ, RabbitMQ只是为生产者和消费者提供发送和接收消息的API

12.2.2消息队列

        Queue(队列)是RabbitMQ的内部对象，用于存储生产者的消息直到发送给消费者，也是消费者接收消息的地方。RabbitMQ中的消息也都只能存储在Queue中，多个消费者可以订阅同一个Queue。        

Queue有以下一些重要的属性。

• 持久性：如果启用，则队列将会在消息协商器（broker）重启前都有效。
• 自动删除：如果启用，则队列将会在所有的消费者停止使用之后自动删除掉。
• 惰性：如果没有声明队列，则应用程序调用队列时会导致异常，并不会主动声明。
• 排他性：如果启用，则声明它的消费者才能使用。

12.2.3交换机

        Exchange （交换机）用于接收、分配消息。生产者先要指定一个“routing key”，然后将消息 发送到交换机。这个“routing key”需要与“Exchange Type”及”binding key"联合使用才能最终生效，然后，交换机将消息路由到一个或多个Queue中，或丢弃。

        在虚拟主机的消息协商器（broker）中，每个Exchange都有唯一的名字。

        Exchange包含4种类型：direct、topic、fanout、headerso不同的类型代表绑定到队列的行为不同。

AMQP规范里还有两种交换机类型--system与自定义。

1. direct

        direct类型的行为是“先匹配，再投送”。在绑定队列时会设定一个routing key,只有在消息的routing key与队列匹配时，消息才会被交换机投送到绑定的队列中。允许一个队列通过一个固定的routing key （通常是队列的名字）进行绑定。Direct交换机将消息根据其routing key属性投 递到包含对应key属性的绑定器上。

        Direct Exchange是RabbitMQ默认的交换机模式，也是最简单的模式。它根据routing key 全文匹配去寻找队列。

2、topic

        按规则转发消息（最灵活）。主题交换机（topic exchange ）转发消息主要根据通配符。队列和交换机的绑定会定义一种路由模式，通配符就要在这种路由模式和路由键之间匹配后，交换机才能转发消息。

        在这种交换机模式下，路由键必须是一串字符，用"."隔开。

        路由模式必须包含一个星号“*”，主要用于匹配路由键指定位置的一个单词。

        topic还支持消息的routing key,用“*”或“#”的模式进行绑定。“*”匹配一个单词，“#” 匹配0个或多个单词。例如，"'binding key *.user.#"匹配 routing key 为“cn.user”和“us.user.db”, 但是不匹配"user.hello"。

3、headers

        它根据应用程序消息的特定属性进行匹配，可以在binding key中标记消息为可选或必选。在队列与交换机绑定时，会设定一组键值对规则。消息中也包括一组键值对（headers属性），当这些 键值对中有一对，或全部匹配时，消息被投送到对应队列。

4、fanout

        消息广播的模式，即将消息广播到所有绑定到它的队列中，而不考虑routing key的值（不管路由键或是路由模式）。如果配置了 r