RabbitMQ从0到1完备学习条记一:《根本篇》

[复制链接]
发表于 2026-2-9 06:06:09 | 显示全部楼层 |阅读模式
目次
  启篇
  一、初识MQ
  1.1 同步调用
  1.2异步调用
  1.3 技能选型
  二、RabbitMQ
  架构
  2.2 收发消息
  2.2.1 交换机
  2.2.2 队列
  2.2.3 绑定关系
  2.2.4 发送消息
  2.3 数据隔离
  2.3.1 用户管理
  2.3.2 virtual host
  三、SpringAMQP
  3.1 案例入门
  3.1.1 导入依靠
  3.1.2 消息发送
  3.1.2 消息吸收
  3.2 WorkQueues模子
  3.2.1 消息发送
  3.2.2 消息吸收
  3.2.3.测试
  3.2.4.能者多劳
  3.3 交换机范例
  3.3.1 Fanout交换机
  案例演示
  3.3.1.1 声明队列和交换机
  3.3.1.2 消息发送
  3.3.1.3 消息吸收
  3.3.1.4 总结
  3.3.2 Direct交换机
  3.3.2.1 声明队列和交换机
  3.3.2.2 消息吸收
  3.3.2.3 消息发送
  3.3.2.4 总结
  3.3.3 Topic交换机
  3.3.3.1.阐明
  3.3.2.1 声明队列和交换机
  3.3.2.2 消息发送
  3.3.2.3 消息吸收
  3.3.2.4 总结
  3.4 API声明队列和交换机
  3.4.1.根本API
  3.4.2.fanout示例
  3.4.2.direct示例
  3.4.4.基于注解声明
  3.5.消息转换器
  3.5.1 设置JSON转换器
  3.5.2 消耗者吸收Object
  四、业务案例实践
  4.1 设置MQ
  4.1.1 添加依靠:
  4.1.2 设置MQ地点:
  4.2 吸收消息
  4.3 发送消息
  
启篇

微服务一旦拆分,肯定涉及到服务之间的相互调用,如今我们服务之间调用接纳的都是基于OpenFeign的调用。这种调用中,调用者发起哀求后须要期待服务提供者实行业务返回结果后,才气继续实行反面的业务。也就是说调用者在调用过程中处于壅闭状态,因此我们成这种调用方式为同步调用,也可以叫同步通讯。但在许多场景下,我们大概须要接纳异步通讯的方式,为什么呢?
我们先来看看什么是同步通讯和异步通讯。如图

解读:

      
  • 同步通讯:就犹如打视频电话,双方的交互都是及时的。因此同一时候你只能跟一个人打视频电话。
      
  • 异步通讯:就犹如发微信谈天,双方的交互不是及时的,你不须要立刻给对方回应。因此你可以多线利用,同时跟多人谈天。

两种方式各有优劣,打电话可以立刻得到相应,但是你却不能跟多个人同时通话。发微信可以同时与多个人收发微信,但是通常相应会有耽误。
以是,如果我们的业务须要及时得到服务提供方的相应,则应该选择同步通讯(同步调用)。而如果我们寻求更高的服从,而且不须要及时相应,则应该选择异步通讯(异步调用)。
同步调用的方式我们已经学过了,之前的OpenFeign调用就是。但是:

      
  • 异步调用又该怎样实现?
      
  • 哪些业务得当用异步调用来实现呢?

通过本日的学习你就能明白这些标题了。
<hr> 一、初识MQ

1.1 同步调用

  之前说过,我们如今基于OpenFeign的调用都属于是同步调用,那么这种方式存在哪些标题呢? 举个例子,我们以昨天留给各人作为作业的余额付出功能为例来分析,起首看下整个流程:

如今我们接纳的是基于OpenFeign的同步调用,也就是说业务实行流程是如许的:

      
  • 付出服务须要先调用用户服务完成余额扣减
      
  • 然后付出服务自己要更新付出流水单的状态
      
  • 然后付出服务调用生意业务服务,更新业务订单状态为已付出

三个步调依次实行。 这此中就存在3个标题: 第一拓展性差 我们如今的业务相对简朴,但是随着业务规模扩大,产物的功能也在不绝美满。 在大多数电贸易务中,用户付出乐成后都会以短信大概别的方式关照用户,告知付出乐成。如果后期产物司理提出如许新的需求,你怎么办?是不是要在上述业务中再参加关照用户的业务? 某些电商项目中,还会有积分或金币的概念。如果产物司理提出需求,用户付出乐成后,给用户以积分夸奖大概返还金币,你怎么办?是不是要在上述业务中再参加积分业务、返还金币业务? 。。。 终极你的付出业务会越来越痴肥:

也就是说每次有新的需求,现有付出逻辑都要跟着厘革,代码常常变动,不符合开闭原则,拓展性欠好。
第二性能降落 由于我们接纳了同步调用,调用者须要期待服务提供者实行完返回结果后,才气继续向下实行,也就是说每次长途调用,调用者都是壅闭期待状态。终极整个业务的相应时长就是每次长途调用的实行时长之和:

如果每个微服务的实行时长都是50ms,则终极整个业务的耗时大概高达300ms,性能太差了。
第三,级联失败 由于我们是基于OpenFeign调用生意业务服务、关照服务。当生意业务服务、关照服务出现故障时,整个事故都会回滚,生意业务失败。 这着实就是同步调用的级联失败标题。
但是各人思索一下,我们假设用户余额富足,扣款已经乐成,此时我们应该确保付出流水单更新为已付出,确保生意业务乐成。毕竟收得手里的钱没原理再退归去吧
因此,这里不能由于短信关照、更新订单状态失败而回滚整个事故。
综上,同步调用的方式存在下列标题:

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

而要办理这些标题,我们就必须用异步调用的方式来代替同步调用
<hr> 1.2异步调用

异步调用方式着实就是基于消息关照的方式,一样平常包罗三个脚色:

      
  • 消息发送者:投递消息的人,就是原来的调用方
      
  • 消息Broker:管理、暂存、转发消息,你可以把它明白成微敬佩务器
      
  • 消息吸收者:吸收和处置惩罚消息的人,就是原来的服务提供方


在异步调用中,发送者不再直接同步调用吸收者的业务接口,而是发送一条消息投递给消息Broker。然后吸收者根据自己的需求从消息Broker那边订阅消息。每当发送方发送消息后,担当者都能获取消息并处置惩罚。 如许,发送消息的人和吸收消息的人就完全解耦了。
还是以余额付出业务为例:

除了扣减余额、更新付出流水单状态以外,别的调用逻辑全部取消。而是改为发送一条消息到Broker。而相干的微服务都可以订阅消息关照,一旦消息到达Broker,则会分发给每一个订阅了的微服务,处置惩罚各自的业务。
如果产物司理提出了新的需求,好比要在付出乐成后更新用户积分。付出代码完全不消变动,而仅仅是让积分服务也订阅消息即可:

不管后期增长了多少消息订阅者,作为付出服务来讲,实行问扣减余额、更新付出流水状态后,发送消息即可。业务耗时仅仅是这三部门业务耗时,仅仅100ms,大大进步了业务性能。
别的,不管是生意业务服务、关照服务,还是积分服务,他们的业务与付出关联度低。如今接纳了异步调用,排除了耦合,他们即便实行过程中出现了故障,也不会影响到付出服务。
综上,异步调用的上风包罗:
   
       
  • 耦合度更低
       
  • 性能更好
       
  • 业务拓展性强
       
  • 故障隔离,克制级联失败
      
  固然,异步通讯也并非完善无缺,它存在下列缺点:
   
       
  • 完全依靠于Broker的可靠性、安全性和性能
       
  • 架构复杂,后期维护和调试贫苦
      
  <hr> 1.3 技能选型

  消息Broker,如今常见的实现方案就是消息队列(MessageQueue),简称为MQ. 目比力常见的MQ实现:

      
  • ActiveMQ
      
  • RabbitMQ
      
  • RocketMQ
      
  • Kafka

几种常见MQ的对比:

   
       
  • 寻求可用性:Kafka、 RocketMQ 、RabbitMQ   
  • 寻求可靠性:RabbitMQ、RocketMQ   
  • 寻求吞吐本领:RocketMQ、Kafka   
  • 寻求消息低耽误:RabbitMQ、Kafka  
  据统计,如今国内消息队列利用最多的还是RabbitMQ,再加上其各方面都比力平衡,稳固性也好,因此我们讲堂上选择RabbitMQ来学习。  
  <hr> 二、RabbitMQ

  RabbitMQ是基于Erlang语言开发的开源消息通讯中心件,官网地点: Messaging that just works — RabbitMQ 接下来,我们就学习它的根本概念和根本用法。
这里的安装教程就不记录了,各人感爱好的可以去找个设置文章跟着弄就好

架构


此中包罗几个概念:

      
  • publisher:生产者,也就是发送消息的一方
      
  • consumer:消耗者,也就是消耗消息的一方
      
  • queue:队列,存储消息。生产者投递的消息会暂存在消息队列中,期待消耗者处置惩罚
      
  • exchange:交换机,负责消息路由。生产者发送的消息由交换机决定投递到哪个队列。
      
  • virtual host:假造主机,起到数据隔离的作用。每个假造主机相互独立,有各自的exchange、queue

<hr>
下面我们学习一下在RabbitMQ控制台利用队列吧~

2.2 收发消息

2.2.1 交换机

我们打开Exchanges选项卡,可以看到已经存在许多交换机:

我们点击恣意交换机,即可进入交换机详情页面。仍旧会利用控制台中的publish message 发送一条消息:



这里是由控制台模拟了生产者发送的消息。由于没有消耗者存在,终极消息丢失了,如许阐明交换机没有存储消息的本领。
2.2.2 队列

我们打开Queues选项卡,新建一个队列:

定名为hello.queue1:

再以雷同的方式,创建一个队列,暗码为hello.queue2,终极队列列表如下:

此时,我们再次向amq.fanout交换机发送一条消息。会发现消息依然没有到达队列!! 怎么回事呢? 发送到交换机的消息,只会路由到与其绑定的队列,因此仅仅创建队列是不敷的,我们还须要将其与交换机绑定。
2.2.3 绑定关系

点击Exchanges选项卡,点击amq.fanout交换机,进入交换机详情页,然后点击Bindings菜单,在表单中填写要绑定的队列名称:

雷同的方式,将hello.queue2也绑定到改交换机。 终极,绑定结果如下:

2.2.4 发送消息

再次回到exchange页面,找到刚刚绑定的amq.fanout,点击进入详情页,再次发送一条消息:

回到Queues页面,可以发现hello.queue中已经有一条消息了:

点击队列名称,进入详情页,检察队列详情,这次我们点击get message:

可以看到消息到达队列了:

这个时间如果有消耗者监听了MQ的hello.queue1或hello.queue2队列,自然就能吸收到消息了。
2.3 数据隔离

2.3.1 用户管理

点击Admin选项卡,起首会看到RabbitMQ控制台的用户管理界面:

这里的用户都是RabbitMQ的管理或运维职员。如今只有安装RabbitMQ时添加的itheima这个用户。细致观察用户表格中的字段,如下:

      
  • Name:itheima,也就是用户名
      
  • Tags:administrator,阐明itheima用户是超等管理员,拥有全部权限
      
  • Can access virtual host: /,可以访问的virtual host,这里的/是默认的virtual host

对于小型企业而言,出于资本思量,我们通常只会搭建一套MQ集群,公司内的多个差别项目同时利用。这个时间为了克制互干系扰, 我们会利用virtual host的隔离特性,将差别项目隔离。一样平常会做两件事故:

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

好比,我们给黑马商城创建一个新的用户,定名为hmall:


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!qidao123.com:ToB企服之家,中国第一个企服评测及软件市场,开放入驻,技术点评得现金

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
回复

使用道具 举报

登录后关闭弹窗

登录参与点评抽奖  加入IT实名职场社区
去登录
快速回复 返回顶部 返回列表