瑞_RabbitMQ_初识MQ

🙊 前言：本文章为瑞_系列专栏之《RabbitMQ》的初识MQ篇，主要介绍了市面上常见的 MQ，RabbitMQ 的安装、架构、管理控制台的基本使用以及数据隔离。由于博主是从B站黑马程序员的《RabbitMQ》学习其相关知识，所以本系列专栏主要是针对该课程进行笔记总结和拓展，文中的部分原理及图解等也是来源于黑马提供的资料，特此注明。本文仅供大家交流、学习及研究使用，禁止用于商业用途，违者必究！

1 初识MQ

  微服务一旦拆分，必然涉及到服务之间的相互调用，目前我们服务之间调用采用的都是基于 OpenFeign 的调用。这种调用中，调用者发起请求后需要等待服务提供者执行业务返回结果后，才能继续执行后面的业务。也就是说调用者在调用过程中处于阻塞状态，因此我们成这种调用方式为同步调用，也可以叫同步通讯。但在很多场景下，我们可能需要采用异步通讯的方式，为什么呢？

  我们先来看看什么是同步通讯和异步通讯。如图

• 同步通讯：就如同打视频电话，双方的交互都是实时的。因此同一时刻你只能跟一个人打视频电话。
• 异步通讯：就如同发微信聊天，双方的交互不是实时的，你不需要立刻给对方回应。因此你可以多线操作，同时跟多人聊天。

  两种方式各有优劣，打电话可以立即得到响应，但是你却不能跟多个人同时通话。发微信可以同时与多个人收发微信，但是往往对方回复不及时导致响应延迟。

  所以

• 如果我们的业务需要实时得到服务提供方的响应，则应该选择同步通讯（同步调用）
• 如果我们追求更高的效率，并且不需要实时响应，则应该选择异步通讯（异步调用）

同步调用的方式例如基于 OpenFeign 调用。异步调用的方式例如基于 MQ 消息通知的调用方式

1.1 同步调用

1.1.1 同步调用的优势

• 时效性强
    等待到结果才返回

瑞：在需要等待结果的业务场景下，就很需要同步调用。比如查询商品信息，需要同步调用商品查询服务，查到了商品信息后才能进行接下来的业务操作，诸如此类的查询业务基本上都采用同步调用

1.1.2 同步调用的缺点

瑞：同步调用虽然有问题，但仍具有大量的业务场景，在实际开发中也是经常使用的

• 拓展性差
    一旦有功能变更，需要修改业务代码

• 性能下降
    调用链路越长，那同步阻塞等待就会导致性能变差，微服务调用越多，性能越差

• 级联失败问题
    一个服务挂了，这个链路上的服务全部会出现问题

  基于 OpenFeign 的调用属于是同步调用，这种方式存在的问题如【余额支付功能】

  首先看下整个流程，如下图所示⬇️

  以上流程采用的是基于 OpenFeign 的同步调用，业务执行流程如下⬇️

  1️⃣ 支付服务需要先调用用户服务完成余额扣减

  2️⃣ 然后支付服务自己要更新支付流水单的状态

  3️⃣ 然后支付服务调用交易服务，更新业务订单状态为已支付

  三个步骤依次同步执行，这样就存在3个问题

  第一，拓展性差

  目前上述的业务相对简单，但是随着业务规模扩大，产品的功能也在不断完善。在大多数电商业务中，用户支付成功后都会以短信或者其它方式通知用户，告知支付成功。假如后期产品经理提出这样新的需求，你怎么办？是不是要在上述业务中再加入通知用户的业务？

  某些电商项目中，还会有积分或金币的概念。假如产品经理提出需求，用户支付成功后，给用户以积分奖励或者返还金币，你怎么办？是不是要在上述业务中再加入积分业务、返还金币业务？

  最终你的支付业务会越来越臃肿，如下⬇️

  每当有新需求时，现有支付逻辑都要跟着变化，代码需要改动，不符合开闭原则（对扩展开放，对修改关闭），拓展性不好。

瑞：关于设计模式的 6 大法则，可以参考《瑞_23种设计模式_概述（含代码）》

  第二，性能下降

  由于我们采用了同步调用，调用者需要等待服务提供者执行完返回结果后，才能继续向下执行，也就是说每次远程调用，调用者都是阻塞等待状态。最终整个业务的响应时长就是每次远程调用的执行时长之和

  假如每个微服务的执行时长都是 50ms，则最终整个业务的耗时可能高达 300ms，性能太差了。

  第三，级联失败

  由于我们是基于 OpenFeign 调用交易服务、通知服务。当交易服务、通知服务出现故障时，整个事务都会回滚，交易失败。这其实就是同步调用的级联失败问题。

思考一下，我们假设用户余额充足，扣款已经成功，此时我们应该确保支付流水单更新为已支付，确保交易成功。毕竟收到手里的钱没道理再退回去吧

  总不能因为短信通知、更新订单状态失败、积分增长失败等后续的业务逻辑执行失败而回滚整个事务

  综上，同步调用的方式存在下列问题

• 拓展性差
• 性能下降
• 级联失败

  而要解决这些问题，我们就必须用异步调用的方式来代替同步调用

1.2 异步调用

1.2.1 异步调用的角色

  异步调用方式其实就是基于消息通知的方式，一般包含以下三个角色

  1️⃣ 消息发送者：投递消息的人，就是原来同步服务的调用方（生产者）

  2️⃣ 消息 Broker：管理、暂存、转发消息，你可以把它理解成微信服务器（消息代理）

  3️⃣ 消息接收者：接收和处理消息的人，就是原来的同步服务的提供方（消费者）

消息 Broker，目前常见的实现方案就是消息队列（MessageQueue），简称为MQ.

  在异步调用中，发送者不再直接同步调用接收者的业务接口，而是发送一条消息投递给消息 Broker。然后接收者根据自己的需求从消息 Broker 那里订阅消息。每当发送方发送消息后，接受者都能获取消息并处理。

  这样，发送消息的人和接收消息的人就完全解耦了

  还是以余额支付业务为例，除了扣减余额、更新支付流水单状态以外，其它同步调用逻辑全部取消。而是改为发送一条消息到 Broker。而相关的微服务都可以订阅消息通知，一旦消息到达 Broker，则会分发给每一个订阅了的微服务，处理各自的业务。

  假如产品经理冒出了新的想法，给你提出了新的需求，比如要添加积分系统，即要在支付成功后更新用户积分。此时支付代码完全不用变更，而仅仅是让积分服务也订阅消息即可，如下⬇️

  不管后期增加了多少消息订阅者，作为支付服务来讲，执行问扣减余额、更新支付流水状态后，发送消息即可。业务耗时仅仅是这三部分业务耗时，仅仅 100ms，大大提高了业务性能。

  另外，不管是交易服务、通知服务，还是积分服务，他们的业务与支付关联度低。现在采用了异步调用，解除了耦合，他们即便执行过程中出现了故障，也不会影响到支付服务，只要保证最终一致性就行。

1.2.2 异步调用的优势

  综上，异步调用的优势如下

• 解除耦合，拓展性强
    只需要发消息到 Broker，后续如果要添加业务，其它业务只需要自行订阅相关消息即可

• 无需等待，性能好
    发完消息，直接服务结束，无需等待异步调用服务的执行时间

• 故障隔离，避免级联失败
    异步调用服务失败抛异常不影响消息发送者

• 缓存消息，流量削峰填谷
    流量削峰填谷是在高并发场景下平滑系统负载，避免因瞬间高流量导致系统崩溃的技术策略。这种策略广泛应用于电商秒杀、大规模促销活动等场景，能够有效平衡上下游系统的负载差异，提高系统的稳定性和可靠性。

1.2.3 异步调用的缺点

  当然，异步通信也并非完美无缺，存在下列缺点⬇️

• 不能立即得到调用结果，时效性差
• 不确定下游业务执行是否成功
• 业务完全依赖于 Broker 的可靠性、安全性和性能
• 架构复杂，后期维护和调试麻烦

1.2.4 异步调用的场景

• 对异步调用的结果不关心，如发送通知、记录日志、执行后台任务等操作。
• 调用链非常长的业务中，一般会改造成异步调用的方式

瑞：对结果不关心指的是：无论异步调用的结果成功或者失败，对当前业务都没有特别大的影响。比如余额支付业务中，订单的状态更新即使失败了，但根据业务逻辑，一般会继续尝试更新，不管是最后人工解决还是怎么慢慢处理，最后总会更新成功，关键点是在于之前的同步调用中用户的钱已经支付成功。但是像查询类型的业务，必须要立马得到结果，这种场景就不能使用异步调用。

1.3 MQ技术选型

  MQ（MessageQueue），中文是消息队列，如同字面上的意思就是存放消息的队列。也就是异步调用中的 Broker 角色，目比较常见的 MQ 实现如下

• ActiveMQ
• RabbitMQ
• RocketMQ
• Kafka

  以上 MQ 的对比

• 追求可用性：Kafka、 RocketMQ 、RabbitMQ
• 追求可靠性：RabbitMQ、RocketMQ
• 追求吞吐能力：RocketMQ、Kafka
• 追求消息低延迟：RabbitMQ、Kafka

  RabbitMQ 是基于 Erlang 语言开发的开源消息通信中间件，性能好，Erlang 语言是面向并发的语言；协议支持丰富，符合微服务理念，Spring 官方默认支持 RabbitMQ ；支持集群，可用性高；单机吞吐量（并发能力）十万二十万左右的样子，但已经满足大多数企业级应用需求；消息延迟在毫秒级；需要消息确认，消息可靠性高。

  Kafka 适用于吞吐量需求很高的场景中，如日志搜集，但由于其消息不可靠，可能存在数据丢失的情况。

  据统计，大厂基本上是使用自研，而中小型企业消息队列使用最多的是 RabbitMQ，因为其各方面都比较均衡，稳定性也好。至于 RocketMQ 由于是阿里的产品，而阿里每年向外输出大量的人才，这些人才流入到中小型企业中，会优先选择去使用 RocketMQ ，但具数据统计 RabbitMQ 在国内还是更受欢迎。

瑞：除了 RabbitMQ 以外，其它的 MQ 都是大厂开发的。大厂有大厂的问题，小厂有小厂的好处。Rabbit 公司主营核心业务之一就是 RabbitMQ ，有团队专门维护，社区也活跃。而其它大厂开发的业务多，如阿里，在阿里待过的同学就知道，阿里中的开源往往是奔 KPI 去的，想要升职加薪得有业绩，得有开源贡献，完成业绩指标之后，后续的升级、维护工作可能就没有那么到位，就会导致 bug 比较多，常见的如 FastJson

2 RabbitMQ

  RabbitMQ的官网地址：Messaging that just works — RabbitMQ

2.1 安装

  本文是基于 Docker 来安装 RabbitMQ

瑞：Docker 的安装和使用可以参考《瑞_Docker（笔记超详细，有这一篇就够了）》
瑞：博主使用的SSH客户端远程连接工具是 MobaXterm，有需要的小伙伴可以参考《瑞_Java所有相关环境及软件的安装和卸载》

2.1.1 资源准备

  如果是内网中开发或拉取镜像困难，请准备好以下资源，如果您的设备可以连接互联网，则可以直接开始安装

瑞：下面是博主提供rabbitmq:3.8-management的 Docker 镜像文件压缩包mq.tar的某度网盘链接，有需要的伙伴请自提

链接：https://pan.baidu.com/s/1tBRud60ExkPXcOBsr7R_rA?pwd=sm4u 
提取码：sm4u

  将mq.tar上传至root目录下，执行以下命令加载镜像

cd /root
docker load -i mq.tar

2.1.2 安装步骤

  执行以下命令进行安装

docker run \-e RABBITMQ_DEFAULT_USER=ray \-e RABBITMQ_DEFAULT_PASS=123456 \-v mq-plugins:/plugins \--name mq \--hostname mq \-p 15672:15672 \-p 5672:5672 \-d \rabbitmq:3.8-management

• -e RABBITMQ_DEFAULT_USER=ray
    设置 RabbitMQ 用户名为：ray

• -e RABBITMQ_DEFAULT_PASS=123456
    设置 RabbitMQ 密码为：123456

• -v mq-plugins:/plugins
    挂载数据卷 mq-plugins 对应容器内目录 plugins

• --name mq
    容器名为：mq

• --hostname mq
    主机名为：mq

• -p 15672:15672
    端口映射，表示将本机的 15672 端口映射到 RabbitMQ 镜像的 15672 端口

• -p 5672:5672
    端口映射，表示将本机的 5672 端口映射到 RabbitMQ 镜像的 5672 端口

• docker run -d
    创建并运行一个容器，-d则是让容器以后台进程运行

  在安装命令中有两个映射的端口

• 15672：RabbitMQ 提供的管理控制台的端口
• 5672：RabbitMQ 的消息发送处理接口

  如上图所示，安装完成后，访问 http://192.168.133.131:15672即可看到管理控制台（记得 IP 要替换为你虚拟机的 IP）

瑞：如果页面无法访问，有可能是因为你的服务器或者虚拟机的对应端口没有开放，请参考《瑞_Linux防火墙相关命令_Windows远程连接虚拟机的服务失败_Linux防火墙端口开放》将 15672 以及 5672 端口开放

  首次访问需要登录，默认的用户名和密码在 docker run 中指定了，博主的用户名为：ray，密码为：123456

  登录成功后即可看到管理控制台总览页面

2.2 RabbitMQ架构

  RabbitMQ 对应的架构如下图所示

  其中包含几个概念：

• publisher：生产者，也就是发送消息的一方
• consumer：消费者，也就是消费消息的一方
• queue：队列，存储消息。生产者投递的消息会暂存在消息队列中，等待消费者处理
• exchange：交换机，负责消息路由。生产者发送的消息由交换机决定投递到哪个队列。
• virtual host：虚拟主机，起到数据隔离的作用。每个虚拟主机相互独立，有各自的exchange、queue

  上述这些东西都可以在 RabbitMQ 的管理控制台来管理。

瑞：交换机不能存储消息，只能路由和转发消息

2.3 RabbitMQ管理控制台收发消息

访问 http://192.168.133.131:15672到 RabbitMQ 管理控制台（记得替换 IP）

  【需求】在 RabbitMQ 的控制台完成下列操作

2.3.1 创建队列

• 新建队列 hello.queue1 和 hello.queue2

  1️⃣ 点击导航栏中的Queues，选择Add a new queue，在Name中输入 hello.queue1，点击Add queue即可添加队列，hello.queue2 同理添加

  2️⃣ 添加成功后如下图

2.3.2 交换机绑定队列★

• 将刚刚创建的 hello.queue1 和 hello.queue2 队列绑定到默认的 amp.fanout 交换机

  1️⃣ 点击Exchanges，鼠标单击选中amp.fanout交换机

  2️⃣ 点击Bindings，在To queue中输入或选择 hello.queue1 ，点击Bind进行绑定，hello.queue2 同理绑定

  3️⃣ 绑定完成后如下图所示

  4️⃣ 到Queues中查看Bindings中是否绑定了交换机amp.fanout

2.3.3 交换机发送消息

• 向默认的 amp.fanout 交换机发送一条消息

  1️⃣ 点击Exchanges，鼠标单击选中amp.fanout交换机进入交换机详情页面，然后点击Publish message，在Payload中输入要发送的消息，如“hello every queue!”，然后点击Publish message，会有提示框提示“Message published”，点击Close即可

  2️⃣ 在Overview中查看消息发送情况，如下图所示

2.3.4 查看消息接收

• 查看消息是否到达 hello.queue1 和 hello.queue2

  1️⃣ 点击导航栏中的Queues，查看队列消息接收情况，如下图所示

  2️⃣ 选中 hellp.queue1 ，进入队列管理界面，展开Get messages，点击Get Message(s)按钮，查看交换机发送的消息内容

此时如果有消费者监听了 MQ 的hello.queue1或hello.queue2队列，就能接收到消息了

2.4 数据隔离

  在 RabbitMQ 中存在 virtual host 即虚拟主机的概念，交换机和队列都有自己所属的虚拟主机，以此实现数据隔离的效果。

2.4.1 用户管理

  点击Admin选项卡，会看到 RabbitMQ 控制台的用户管理界面 Users

  这些用户都是 RabbitMQ 的管理或运维人员。目前只有安装 RabbitMQ 时添加的ray这个用户。用户表格中的字段，如下：

• Name：ray，也就是用户名
• Tags：administrator，说明ray用户是超级管理员，拥有所有权限
• Can access virtual host： /，可以访问的virtual host，这里的/是默认的virtual host

  对于小型企业而言，出于成本考虑，通常只会搭建一套 MQ 集群，公司内的多个不同项目同时使用。这个时候为了避免互相干扰， 会利用virtual host的隔离特性，将不同项目隔离。一般会做两件事情：

• 给每个项目创建独立的运维账号，将管理权限分离。
• 给每个项目创建不同的virtual host，将每个项目的数据隔离。

  比如给黑马商城项目创建一个新的用户，名为hmall，密码为123456，标签选择admin即administrator超级管理员权限

  此时会发现 hmall 用户没有任何virtual host的访问权限

  别急，接下来我们就来为 hmall 进行授权操作

2.4.2 virtual host 用户授权

  1️⃣ 先点击页面右上角的Log out退出登录

  2️⃣ 切换到刚刚创建的 hmall 用户登录，在Admin标签页中点击Virtual Hosts菜单，进入virtual host管理页

  可以看到目前只有一个默认的virtual host，名字为 /

  3️⃣ 给黑马商城项目创建一个单独的virtual host，而不是使用默认的/，展开Add a new virtual host

  4️⃣ 创建完成后如下图所示

  由于我们是登录hmall账户后创建的virtual host，因此回到users菜单，你会发现当前用户已经具备了对/hmall这个virtual host的访问权限了

  5️⃣ 点击页面右上角的virtual host下拉菜单，切换virtual host为 /hmall

  6️⃣ 切换virtual host为 /hmall后，查看Queues选项卡，会发现之前的队列已经看不到了

  这就是基于virtual host 的隔离效果

瑞：可以理解为 MySQL 中的 database 数据库就是虚拟机，默认有/数据库，它的数据表和新建的hmall数据库中的数据表即使命名相同，但会处于互相隔离互不影响的状态，我们能看到其它数据库（虚拟机）是因为无论是 hmall 用户还是 ray 用户，都具有超级管理员权限，但并不能操作对方的虚拟机，只能操作本用户下的虚拟机中的交换机和队列，以此做到数据隔离的效果。所以一般每一个项目会创建一个用户，创建一个专属的虚拟机。

  如果觉得这篇文章对您有所帮助的话，请动动小手点波关注💗，你的点赞👍收藏⭐️转发🔗评论📝都是对博主最好的支持~