RabbitMQ入门介绍

1.1. MQ是什么

MQ全程Message Queue即消息队列，是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。

1.2. MQ的作用

使用MQ通常是为了三个效果，分别是应用解耦，任务异步处理，削峰填谷。

1. 应用解耦：MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。当系统的耦合性越高时，它的容错性和可维护性就越低。所以通过MQ使得应用间解耦，提升容错性和可维护性。
2. 任务异步处理：将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。提高了应用程序的响应时间。比如在一个正常的应用中，用户发送一个请求其写入数据库需要20ms，然后进行三个不同消费模块处理后，每个模块需要300ms，那么总共需要20+300+300+300=920ms才能返回给用户响应，这样无疑是很慢的，很影响用户体验。如果使用MQ，那么用户同样用发送一个请求其写入数据库需要20ms，将请求写入MQ只需要5m，然后每个功能模块获取消息队列进行异步处理，这样只要20+5ms用户便能得到响应，用户的体验便能提高很多。
3. 削峰填谷：如订单系统，在下单的时候就会往数据库写数据。但是数据库只能支撑每秒1000左右的并发写入，并发 量再高就容易宕机。低峰期的时候并发也就100多个，但是在高峰期时候，并发量会突然激增到5000以 上，这个时候数据库肯定卡死了。而当使用MQ之后，消息被MQ保存起来了，然后系统就可以按照自己的消费能力来消费，比如每秒1000个消息，这样慢慢 写入数据库，这样就不会卡死数据库了。但是使用了MQ之后，限制消费消息的速度为1000，但是这样一来，高峰期产生的数据势必会被积压在 MQ中，高峰就被“削”掉了。但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会 维持在1000QPS，直到消费完积压的消息,这就叫做“填谷”。

1.3.MQ的劣势

1. 系统可用性降低，系统引入的外部依赖越多，系统稳定性越差。一旦 MQ 宕机，就会对业务造成影响。如何保证MQ的高 可用？ 

2. 系统复杂度提高，MQ 的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过 MQ 进行异步调用。 如何保证消息没有被重复消费？怎么处理消息丢失情况？那么保证消息传递的顺序性？

3. 一致性问题，A 系统处理完业务，通过 MQ 给B、C、D三个系统发消息，如果 B 系统、C 系统处理成功，D 系统处理 失败。如何保证消息数据处理的一致性？

1.4.MQ的两种实现方式

实现MQ的大致有两种主流方式：AMQP、JMS。

AMQP

AMQP，即 Advanced Message Queuing Protocol（高级消息队列协议），是一个网络协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，遵循此协议，不收客户端和中间件产品和开发语言限制。2006年，AMQP规范发布。类比HTTP。

JMS

JMS 即 Java 消息服务（JavaMessage Service）应用程序接口，是一个 Java 平台中关于面向消息中间 件的API JMS 是 JavaEE 规范中的一种，类比JDBC 很多消息中间件都实现了JMS规范。

2.1.RabbitMQ基础概念

介绍完MQ，我们再来具体说说RabbitMQ。

RabbitMQ是Rabbit公司通过Erlang语言开发的，它拥有并发能力强，性能极其好， 延时低，社区活跃，管理界面丰富等特性。

RabbitMQ 基础架构如下图：

RabbitMQ 基础架构如下图：

• Broker：接收和分发消息的应用，RabbitMQ Server就是 Message Broker
• Virtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类 似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务 时，可以划分出多个vhost，每个用户在自己的 vhost 创建 exchange／queue 等
• Connection：publisher／consumer 和 broker 之间的 TCP 连接
• Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCP Connection的开销将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接， 如果应用程序支持多线程，通常每个thread创建单独的 channel 进行通讯，AMQP method 包含 了channel id 帮助客户端和message broker 识别 channel，所以 channel 之间是完全隔离的。 Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP connection 的开销
• Exchange：message 到达 broker 的第一站，根据分发规则，匹配查询表中的 routing key，分发 消息到queue 中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
• Queue：消息最终被送到这里等待 consumer 取走
• Binding：exchange 和 queue 之间的虚拟连接，binding 中可以包含 routing key。Binding 信息 被保存到 exchange 中的查询表中，用于 message 的分发依据

 2.2.RabbitMQ的工作模式

我们常用的RabbitMQ的模式有四种，work模式，Publish/Subscribe发布与订阅模式，Routing路由 模式，Topics主题模式。

1.Work queues工作队列模式

 

Work Queues 与入门程序的简单模式相比，多了一个或一些消费端，多个消费端共同消费同一个队列中的消息。通常应用于任务过重或任务较多的情况下，使用工作队列可以提高任务处理的速度。

2.Publish/Subscribe发布与订阅模式

在订阅模型中，多了一个exchange角色，过程略有变化： 

P即生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机），交换机一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于 Exchange的类型。Exchange有常见以下3种类型：

• Fanout：广播，将消息交给所有绑定到交换机的队列
• Direct：定向，把消息交给符合指定routing key 的队列
• Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列

需要注意的是，Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑 定，或者没有符合路由规则的队列，那么消息会丢失！

3.Routing路由模式

路由模式特点： 队列与交换机的绑定，不能是任意绑定了，而是要指定一个 RoutingKey（路由key）消息的发送方在 向 Exchange发送消息时，也必须指定消息的 RoutingKey。 Exchange不再把消息交给每一个绑定的队列，而是根据消息的RoutingKey进行判断，只有队列的Routingkey 与消息的 Routing key 完全一致，才会接收到消息。

 生产者，向Exchange发送消息，发送消息时，会指定一个routing key。Exchange（交换机），接收生产者的消息，然后把消息递交给 与routing key完全匹配的队列，比如C1指定了需要routing key 为 aaa 的消息，C2指定了需要routing key 为 bbb的消息。

4.Topics通配符模式

Topic 类型与 Direct 相比，都是可以根据 RoutingKey 把消息路由到不同的队列。只不过 Topic 类型 Exchange 可以让队列在绑定 Routing key 的时候使用通配符。通配符规则： # ：匹配一个或多个词 * ：匹配不多不少恰好1个词。例如 ：item.# ：能够匹配 item.insert.abc 或者 item.insert，item.* ：只能匹配 item.insert。