wordpress网站鼠标,网站设计的研究方法,贵阳网站页面设计,个人博客网站开发毕业设计文章目录 1 初识MQ1.1 同步调用1.1.1 同步调用的优势1.1.2 同步调用的缺点 1.2 异步调用1.2.1 异步调用的角色1.2.2 异步调用的优势1.2.3 异步调用的缺点1.2.4 异步调用的场景 1.3 MQ技术选型 2 RabbitMQ2.1 安装2.1.1 资源准备2.1.2 安装步骤 2.2 RabbitMQ架构2.3 RabbitMQ管理… 文章目录 1 初识MQ1.1 同步调用1.1.1 同步调用的优势1.1.2 同步调用的缺点 1.2 异步调用1.2.1 异步调用的角色1.2.2 异步调用的优势1.2.3 异步调用的缺点1.2.4 异步调用的场景 1.3 MQ技术选型 2 RabbitMQ2.1 安装2.1.1 资源准备2.1.2 安装步骤 2.2 RabbitMQ架构2.3 RabbitMQ管理控制台收发消息2.3.1 创建队列2.3.2 交换机绑定队列★2.3.3 交换机发送消息2.3.4 查看消息接收 2.4 数据隔离2.4.1 用户管理2.4.2 virtual host 用户授权 前言本文章为瑞_系列专栏之《RabbitMQ》的初识MQ篇主要介绍了市面上常见的 MQRabbitMQ 的安装、架构、管理控制台的基本使用以及数据隔离。由于博主是从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技术选型 MQMessageQueue中文是消息队列如同字面上的意思就是存放消息的队列。也就是异步调用中的 Broker 角色目比较常见的 MQ 实现如下
ActiveMQRabbitMQRocketMQKafka 以上 MQ 的对比
RabbitMQActiveMQRocketMQKafka公司/社区RabbitApache阿里Apache开发语言ErlangJavaJavaScalaJava协议支持AMQPXMPPSMTPSTOMPOpenWire,STOMPREST,XMPP,AMQP自定义协议自定义协议可用性高主从架构高主从架构非常高分布式架构非常高分布式架构单机吞吐量一般万级差 万级高 十万级非常高百万级消息延迟微秒级us级毫秒级ms级毫秒级ms级毫秒以内ms级以内消息可靠性高一般高一般功能特性基于Erlang开发所以并发能力很强性能极其好延时很低管理界面较丰富成熟的产品在很多公司得到应用有较多的文档各种协议支持较好MQ功能比较完备扩展性佳只支持主要的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?pwdsm4u
提取码sm4u将mq.tar上传至root目录下执行以下命令加载镜像
cd /root
docker load -i mq.tar2.1.2 安装步骤 执行以下命令进行安装
docker run \-e RABBITMQ_DEFAULT_USERray \-e RABBITMQ_DEFAULT_PASS123456 \-v mq-plugins:/plugins \--name mq \--hostname mq \-p 15672:15672 \-p 5672:5672 \-d \rabbitmq:3.8-management【命令解读】 -e RABBITMQ_DEFAULT_USERray 设置 RabbitMQ 用户名为ray -e RABBITMQ_DEFAULT_PASS123456 设置 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则是让容器以后台进程运行 在安装命令中有两个映射的端口
15672RabbitMQ 提供的管理控制台的端口5672RabbitMQ 的消息发送处理接口 如上图所示安装完成后访问 http://192.168.133.131:15672即可看到管理控制台记得 IP 要替换为你虚拟机的 IP 瑞如果页面无法访问有可能是因为你的服务器或者虚拟机的对应端口没有开放请参考《瑞_Linux防火墙相关命令_Windows远程连接虚拟机的服务失败_Linux防火墙端口开放》将 15672 以及 5672 端口开放 首次访问需要登录默认的用户名和密码在 docker run 中指定了博主的用户名为ray密码为123456 登录成功后即可看到管理控制台总览页面 RabbitMQ 安装完成 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 的管理控制台入门小案例——收发消息 【需求】在 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这个用户。用户表格中的字段如下
Nameray也就是用户名Tagsadministrator说明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 用户都具有超级管理员权限但并不能操作对方的虚拟机只能操作本用户下的虚拟机中的交换机和队列以此做到数据隔离的效果。所以一般每一个项目会创建一个用户创建一个专属的虚拟机。 本文是博主的粗浅理解可能存在一些错误或不完善之处如有遗漏或错误欢迎各位补充谢谢 如果觉得这篇文章对您有所帮助的话请动动小手点波关注你的点赞收藏⭐️转发评论都是对博主最好的支持~
