1. MQ 的基本概念

1.1 MQ概述

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

⚫ MQ，消息队列，存储消息的中间件
⚫ 分布式系统通信两种方式：直接远程调用 和 借助第三方 完成间接通信
⚫ 发送方称为生产者，接收方称为消费者

1.2 MQ的优势和劣势

1.2.1 MQ的优势

1）应用解耦

当用户点击按钮下订单的时候会访问订单系统，订单系统再去操作，库存，支付，物流系统，可以有两种方式，第一种方式可以直接通过远程调用的方式来去调用库存，支付，物流系统，然而这样库存，支付，物流这三个系统就耦合在一起，就会引发一些问题：
第一个问题（容错性问题），假如说当库存系统产生一些异常，挂掉，这样订单系统在下订单的时候，这整个链路就走不通了，从而导致订单系统也出现问题，用户就可能得到下单失败的反馈。
第二个问题：假设说产品经理让订单系统开发者，在下单的时候不仅能访问库存，支付，物流系统，还要再加一个系统（X系统），这样系统开发资自能修改订单系统的代码，在访问x系统，在增加，删除系统的时候，订单系统的代码要不停的修改，这样订单系统的可维护性就非常低。

使用MQ可解决上述问题。
当用户点击按钮下订单的时候会访问订单系统，订单系统只需要发送消息给MQ就可以了，这时候我们就可以给用户返回说下单成功了，库存，支付，物流系统只需要从MQ中分别把订单消息数据拿出来，在他们自己的系统里去消费就可以了，应为订单系统和库存，支付，物流系统时隔离的，所以另三个系统的其中一个出错了对订单系统没有影响。提高了系统的容错性。

另外在整个下单链路上再加入一个系统，只需要让新加的系统从MQ里面把消息拿出来再消费一次就可以了，订单系统的代码就无需更改。

2）异步提速

当用户下完订单后，订单系统要保存自己的数据库，假设花费20ms，通过远程调用的方式访问库存，支付，物流系统分别耗费300ms，整个调用完成后再返回给用户下单成功，一个下单耗费920ms，对于互联网系统来说，太慢了。（要200ms以内）

可以用MQ来解决：

当用户下完订单后，订单系统只需要保存自己的数据库，花费20ms，同时向MQ发送一个消息，花费5ms，这时候订单系统就可以告诉用户下单成功了，后面的操作不用管，（让他们从MQ获取相应的消息慢慢消费就可以）
异步的方式。

3）削锋填谷

假设A系统接受用户的请求每秒最大1000个请求，这时候要做一个获得，（类似一元秒杀的活动），这时候大量用户同时访问这个系统，承载不了这样的并发，就挂掉了。
我们可以用MQ把这个峰值消掉。

我们添加一个MQ消息中间件，用户只需要把请求发送给MQ，然后A系统再从MQ把请求的消息拿出来消费就可以了。

使用了 MQ 之后，限制消费消息的速度为1000，这样一来，高峰期产生的数据势必会被积压在 MQ 中，高峰 就被“削”掉了，但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会维持在1000，直 到消费完积压的消息，这就叫做“填谷”。
使用MQ后，可以提高系统稳定性。

小结 ：
⚫ 应用解耦：提高系统容错性和可维护性
⚫ 异步提速：提升用户体验和系统吞吐量
⚫ 削峰填谷：提高系统稳定性

1.2.2 MQ的劣势

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

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

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

既然 MQ 有优势也有劣势，那么使用 MQ 需要满足什么条件呢？

① 生产者不需要从消费者处获得反馈。引入消息队列之前的直接调用，其接口的返回值应该为空，这才让明 明下层的动作还没做，上层却当成动作做完了继续往后走，即所谓异步成为了可能。
② 容许短暂的不一致性。
③ 确实是用了有效果。即解耦、提速、削峰这些方面的收益，超过加入MQ，管理MQ这些成本。

1.3 常见的 MQ 产品

目前业界有很多的 MQ 产品，例如 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等， 也有直接使用 Redis 充当消息队列的案例，而这些消息队列产品，各有侧重，在实际选型时，需要结合自身需 求及 MQ 产品特征，综合考虑。

2. RabbitMQ 简介

2007年，Rabbit 技术公司基于 AMQP 标准开发的 RabbitMQ 1.0 发布。RabbitMQ 采用 Erlang 语言开发。 Erlang 语言由 Ericson 设计，专门为开发高并发和分布式系统的一种语言，在电信领域使用广泛。

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

RabbitMQ 基础架构如下图：

2.1 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 的分发依据

RabbitMQ 提供了 6 种工作模式：简单模式、work queues、Publish/Subscribe 发布与订阅模式、Routing 路由模式、Topics 主题模式、RPC 远程调用模式（远程调用，不太算 MQ；暂不作介绍）。
官网对应模式介绍：https://www.rabbitmq.com/getstarted.html

2.2 JMS

⚫ JMS 即 Java 消息服务（JavaMessage Service）应用程序接口，是一个 Java 平台中关于面向消息中间件 的API
⚫ JMS 是 JavaEE 规范中的一种，类比JDBC
⚫ 很多消息中间件都实现了JMS规范，例如：ActiveMQ。RabbitMQ 官方没有提供 JMS 的实现包，但是开 源社区有

2.3 RabbitMQ 的安装和配置

基于Docker安装RabbitMQ
1.创建并运行
docker run -d —name rabbitmq -p15672:15672 -p 5672:5672 rabbitmq:management

2.开放端口
开放端口15672和5672

3.访问测试
http://服务器ip:15672
http://192.168.71.128:15672/

默认账号和密码：guest/guest

3. RabbitMQ 的工作模式

3.1 Work queues 工作队列模式

c1 和 c2 是竞争关系，c1 和c2只能有一个能取到消息，另一个取另一个

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

小结：
1. 在一个队列中如果有多个消费者，那么消费者之间对于同一个消息的关系是竞争的关系。
2. Work Queues 对于任务过重或任务较多情况使用工作队列可以提高任务处理的速度。例如：短信服务部署多个， 只需要有一个节点成功发送即可。

3.2 Pub/Sub 订阅模式

在订阅模型中，多了一个 Exchange 角色，而且过程略有变化：
⚫ P：生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机）
⚫ C：消费者，消息的接收者，会一直等待消息到来
⚫ Queue：消息队列，接收消息、缓存消息
⚫ Exchange：交换机（X）。一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个 特别队列、 递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。Exchange有常见以下3种类型：
➢ Fanout：广播，将消息交给所有绑定到交换机的队列
➢ Direct：定向，把消息交给符合指定routing key 的队列
➢ Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列

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

小结：
1. 交换机需要与队列进行绑定，绑定之后；一个消息可以被多个消费者都收到。
2. 发布订阅模式与工作队列模式的区别：
⚫ 工作队列模式不用定义交换机，而发布/订阅模式需要定义交换机
⚫ 发布/订阅模式的生产方是面向交换机发送消息，工作队列模式的生产方是面向队列发送消息(底层使用 默认交换机)
⚫ 发布/订阅模式需要设置队列和交换机的绑定，工作队列模式不需要设置，实际上工作队列模式会将队 列绑 定到默认的交换机