九 RabbitMQ

一   MQ 简介

在计算机科学中，消息队列（英语：Message queue）是一种进程间通信或同一进程的 不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提 供了异步的通信协议，每一个贮列中的纪录包含详细说明的数据，包含发生的时间，输入设 备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列 互交。消息会保存在队列中，直到接收者取回它。

1.实现

消息队列常常保存在链表结构中。拥有权限的进程可以向消息队列中写入或读取消息。

目前，有很多消息队列有很多开源的实现，包括 JBoss Messaging、JORAM、Apache ActiveMQ、Sun Open Message Queue、IBM MQ、Apache Qpid 和 HTTPSQS。

当前使用较多的消息队列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq 等，而部分数据库如 Redis、Mysql 以及 phxsql 也可实现消息队列的功能。

2.特点

MQ 是消费者-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一 端则可以读取或者订阅队列中的消息。MQ 和 JMS 类似，但不同的是 JMS 是 SUN JAVA 消息 中间件服务的一个标准和 API 定义，而 MQ 则是遵循了 AMQP 协议的具体实现和产品。

注意：

1. AMQP，即 Advanced Message Queuing Protocol,一个提供统一消息服务的应用 层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于 此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语 言等条件的限制。

2. JMS，Java 消息服务（Java Message Service）应用程序接口，是一个 Java 平 台中关于面向消息中间件的 API，用于在两个应用程序之间，或分布式系统中发送消息，进 行异步通信。 Java 消息服务是一个与具体平台无关的 API，绝大多数 MOM 提供商都对 JMS 提供支持。常见的消息队列，大部分都实现了 JMS API，如 ActiveMQ，Redis 以及 RabbitMQ 等。

3.优缺点

优点: 应用耦合、异步处理、流量削锋

缺点: 系统可用性降低、系统复杂性增加

4.为什么用它

基于 AMQP 协议

高并发(是一个容量的概念，服务器可以接受的最大任务数量)

高性能(是一个速度的概念，单位时间内服务器可以处理的任务数)

高可用(是一个持久的概念，单位时间内服务器可以正常工作的时间比例)

强大的社区支持，以及很多公司都在使用

支持插件

支持多语音

二   队列的模式

0.普通队列模式

一个生产者对应一个消费者

1.工作队列-消息轮询分发

从结果可以看出消息被平均分配到两个消费方，来对消息进行处理，提高了消息处理效 率，创建多个消费者来对消息进行处理。这里 RabitMQ 采用轮询来对消息进行分发时保证 了消息被平均分配到每个消费方，但是引入新的问题:真正的生产环境下，对于消息的处理 基本不会像我们现在看到的这样，每个消费方处理的消息数量是平均分配的，比如因为网络 原因，机器 cpu,内存等硬件问题，消费方处理消息时同类消息不同机器进行处理时消耗时 间也是不一样的，比如 1 号消费者消费 1 条消息时 1 秒，2 号消费者消费 1 条消息是 5 秒， 对于 1 号消费者比 2 号消费者处理消息快，那么在分配消息时就应该让 1 号消费者多收到 消息进行处理，也即是我们通常所说的”能者多劳”,同样 Rabbitmq 对于这种消息分配模式 提供了支持。

问题：任务量很大，消息虽然得到了及时的消费，单位时间内消息处理速度加快，提高 了吞吐量，可是不同消费者处理消息的时间不同，导致部分消费者的资源被浪费。

解决：采用消息公平分发。

总结：工作队列-消息轮询分发-消费者收到的消息数量平均分配，单位时间内消息处理 速度加快，提高了吞吐量。

2.工作队列-消息公平分发

从结果可以看出 1 号消费者消费消息数量明显高于 2 号，即消息通过 fair 机制被公 平分发到每个消费者。

问题：生产者产生的消息只可以被一个消费者消费，可不可以被多个消费者消费呢？

解决：采用发布与订阅模式。

总结：工作队列-公平轮询分发-根据不同消费者机器硬件配置，消息处理速度不同，收 到的消息数量也不同，通常速度快的处理的消息数量比较多，最大化使用计算机资源。适用 于生成环境。

3.消息的发布与订阅模式队列

从结果可以看出生产者发送了一条消息，用于邮件发送和短信发送的消费者均可以收到 消息进行后续处理。

问题：生产者产生的消息所有消费者都可以消费，可不可以指定某些消费者消费呢？

解决：采用 direct 路由模式。

4.路由模式队列

从结果可以看出生产者发送了多条设置了路由规则的消息，消费者可以根据具体的路由 规则消费对应队列中的消息，而不是所有消费者都可以消费所有消息了。

问题：生产者产生的消息如果场景需求过多需要设置很多路由规则，可不可以减少？

解决：采用 topic 主题模式。

5.主题模式队列

从结果可以看出生产者发送了多条设置了路由匹配规则(主题)的消息，根据不同的路 由匹配规则(主题)，可以将消息根据指定的 routing key 路由到匹配到的队列中，也是在 生产中比较常见的一种消息处理方式。

问题：RabbitMQ 本身是基于异步的消息处理，是否可以同步实现？

解决：采用 RPC 模式。

6.rpc远程过程调用模式队列

三   RabbitMQ 消息的事物机制

在使用 RabbitMQ 的时候，我们可以通过消息持久化操作来解决因为服务器的异常奔溃 导致的消息丢失，除此之外我们还会遇到一个问题，当消息的发布者在将消息发送出去之后， 消息到底有没有正确到达 broker 代理服务器呢？如果不进行特殊配置的话，默认情况下发 布操作是不会返回任何信息给生产者的，也就是默认情况下我们的生产者是不知道消息有没 有正确到达 broker 的，如果在消息到达 broker 之前已经丢失的话，持久化操作也解决不 了这个问题，因为消息根本就没到达代理服务器，你怎么进行持久化，那么这个问题该怎么 解决呢？

RabbitMQ 为我们提供了两种方式：

1. 通过 AMQP 事务机制实现，这也是 AMQP 协议层面提供的解决方案；

2. 通过将 channel 设置成 confirm 模式来实现；