RabbitMQ 实战教程
MQ 引言
什么是 MQ
MQ
(Message Queue) : 翻译为 消息队列
,通过典型的 生产者
和消费者
模型,生产者不断向消息队列中生产消息,消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的,而且只关心消息的发送和接收,没有业务逻辑的侵入,轻松的实现系统间解耦。别名为 消息中间件
。通过利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。
MQ 有哪些
当今市面上有很多主流的消息中间件,如老牌的ActiveMQ
、RabbitMQ
,炙手可热的Kafka
,阿里巴巴自主开发RocketMQ
等。
不同 MQ 特点
1 | # 1.ActiveMQ |
RabbitMQ 比 Kafka 可靠,Kafka 更适合 IO 高吞吐的处理,一般应用在大数据日志处理或对实时性(少量延迟),可靠性(少量丢数据)要求稍低的场景使用,比如 ELK 日志收集。
RabbitMQ 的引言
RabbitMQ
基于
AMQP
协议,erlang
语言开发,是部署最广泛的开源消息中间件,是最受欢迎的开源消息中间件之一。
官方教程
: https://www.rabbitmq.com/#getstarted
1 | # AMQP 协议 |
RabbitMQ 的安装
下载
官网下载地址
: https://www.rabbitmq.com/download.html
使用docker安装步骤:
1 | docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management |
最新版本
: 3.7.18
下载的安装包
注意
: 这里的安装包是 centos7 安装的包
安装步骤
1 | # 1.将 rabbitmq 安装包上传到 linux 系统中的 /home/soft 目录下 |
将上图中配置文件中红色部分去掉%%
,以及最后的,
逗号 修改为下图:
1 | # 7.执行如下命令,启动 rabbitmq 中的插件管理 |
1 | # 10.关闭防火墙服务(在云服务器将安全策略开放) |
1 | # 12.登录管理界面 |
RabiitMQ 配置
RabbitMQ 管理命令行
1 | # 1.服务启动相关 |
web 管理界面介绍
overview 概览
connections:无论生产者还是消费者,都需要与RabbitMQ建立连接后才可以完成消息的生产和消费,在这里可以查看连接情况
channels:通道,建立连接后,会形成通道,消息的投递获取依赖通道。
Exchanges:交换机,用来实现消息的路由
Queues:队列,即消息队列,消息存放在队列中,等待消费,消费后被移除队列。
15672:web界面端口,5672:通信端口,25672:集群端口
Admin 用户和虚拟主机管理
添加用户
上面的 Tags 选项,其实是指定用户的角色,可选的有以下几个:
超级管理员(administrator)
可登陆管理控制台,可查看所有的信息,并且可以对用户,策略(policy)进行操作。
监控者(monitoring)
可登陆管理控制台,同时可以查看 rabbitmq 节点的相关信息(进程数,内存使用情况,磁盘使用情况等)
策略制定者(policymaker)
可登陆管理控制台, 同时可以对 policy 进行管理。但无法查看节点的相关信息(上图红框标识的部分)。
普通管理者(management)
仅可登陆管理控制台,无法看到节点信息,也无法对策略进行管理。
其他
无法登陆管理控制台,通常就是普通的生产者和消费者。
创建虚拟主机
1 | # 虚拟主机 |
绑定虚拟主机和用户
创建好虚拟主机,我们还要给用户添加访问权限:
点击添加好的虚拟主机:
进入虚拟机设置界面:
RabbitMQ 的第一个程序
AMQP 协议的回顾
RabbitMQ 支持的消息模型
第一种模型(直连)
创建新项目
创建空项目:rabbitmq_study
创建普通 maven 模块:rabbitmq
引入依赖
1 | <!--test--> |
首先在 rabbitmq 页面上创建虚拟主机,以及用户,然后用户绑定虚拟主机。
在上图的模型中,有以下概念:
- P:生产者,也就是要发送消息的程序
- C:消费者:消息的接受者,会一直等待消息到来。
- queue:消息队列,图中红色部分。类似一个邮箱,可以缓存消息;生产者向其中投递消息,消费者从其中取出消息。
开发生产者
1 | package com.itjing.rabbitmq.helloword; |
运行后,去查看页面队列信息:
开发消费者
1 | package com.itjing.rabbitmq.helloword; |
封裝工具类
1 | package com.itjing.rabbitmq.utils; |
第二种模型(work quene)
Work queues
,也被称为(Task queues
),任务模型。当消息处理比较耗时的时候,可能生产消息的速度会远远大于消息的消费速度。长此以往,消息就会堆积越来越多,无法及时处理。此时就可以使用 work 模型:让多个消费者绑定到一个队列,共同消费队列中的消息
。队列中的消息一旦消费,就会消失,因此任务是不会被重复执行的。
角色:
- P:生产者:任务的发布者
- C1:消费者-1,领取任务并且完成任务,假设完成速度较慢
- C2:消费者-2:领取任务并完成任务,假设完成速度快
开发生产者
1 | package com.itjing.rabbitmq.workqueue; |
开发消费者-1
1 | package com.itjing.rabbitmq.workqueue; |
开发消费者-2
1 | package com.itjing.rabbitmq.workqueue; |
测试结果
总结:默认情况下,RabbitMQ将按顺序将每个消息发送给下一个使用者。
平均而言,每个消费者都会收到相同数量的消息。这种分发消息的方式称为循环。
消息自动确认机制
Doing a task can take a few seconds. You may wonder what happens if one of the consumers starts a long task and dies with it only partly done. With our current code, once RabbitMQ delivers a message to the consumer it immediately marks it for deletion. In this case, if you kill a worker we will lose the message it was just processing. We’ll also lose all the messages that were dispatc hed to this particular worker but were not yet handled.
But we don’t want to lose any tasks. If a worker dies, we’d like the task to be delivered to another worker.
1 | channel.basicQos(1); // 每次只能消费一个消息 |
设置通道一次只能消费一个消息
关闭消息的自动确认,开启手动确认消息
消费一个消息,手动确认后,队列就会把那个消息删除,达到能者多劳的效果
第三种模型(fanout)
fanout 扇出 也称为广播
在广播模式下,消息发送流程是这样的:
- 可以有多个消费者
- 每个
消费者有自己的queue
(队列) - 每个
队列都要绑定到Exchange
(交换机) 生产者发送的消息,只能发送到交换机
,交换机来决定要发给哪个队列,生产者无法决定。- 交换机把消息发送给绑定过的所有队列
- 队列的消费者都能拿到消息。实现一条消息被多个消费者消费
开发生产者
1 | package com.itjing.rabbitmq.fanout; |
开发消费者-1
1 | package com.itjing.rabbitmq.fanout; |
开发消费者-2
1 | package com.itjing.rabbitmq.fanout; |
开发消费者-3
1 | package com.itjing.rabbitmq.fanout; |
测试结果
第四种模型(Routing)
Routing 之订阅模型-Direct(直连)
在Fanout模式中,一条消息,会被所有订阅的队列都消费。但是,在某些场景下,我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。
在 Direct 模型下:
- 队列与交换机的绑定,不能是任意绑定了,而是要指定一个
RoutingKey
(路由 key) - 消息的发送方在 向 Exchange 发送消息时,也必须指定消息的
RoutingKey
。 - Exchange 不再把消息交给每一个绑定的队列,而是根据消息的
Routing Key
进行判断,只有队列的Routingkey
与消息的Routing key
完全一致,才会接收到消息
流程:
图解:
- P:生产者,向 Exchange 发送消息,发送消息时,会指定一个 routing key。
- X:Exchange(交换机),接收生产者的消息,然后把消息递交给与 routing key 完全匹配的队列
- C1:消费者,比如其所在队列指定了需要 routing key 为 error 的消息
- C2:消费者,比如其所在队列指定了需要 routing key 为 info、error、warning 的消息
开发生产者
1 | package com.itjing.rabbitmq.direct; |
开发消费者-1
1 | package com.itjing.rabbitmq.direct; |
开发消费者-2
1 | package com.itjing.rabbitmq.direct; |
测试结果
测试生产者发送 Route key 为 error 的消息时:
测试生产者发送 Route key 为 info 的消息时:
Routing 之订阅模型-Topic
Topic
类型的Exchange
与Direct
相比,都是可以根据RoutingKey
把消息路由到不同的队列。只不过Topic
类型Exchange
可以让队列在绑定Routing key
的时候使用通配符!这种模型Routingkey
一般都是由一个或多个单词组成,多个单词之间以”.”分割,例如: item.insert
1 | # 统配符 |
开发生产者
1 | package com.itjing.rabbitmq.topic; |
开发消费者-1
Routing Key中使用*通配符方式
1 | package com.itjing.rabbitmq.topic; |
开发消费者-2
Routing Key中使用#通配符方式
1 | package com.itjing.rabbitmq.topic; |
测试结果
测试生产者发送 Route key 为 user.save 的消息时:
测试生产者发送 Route key 为 user.save.findAll 的消息时:
SpringBoot 中使用 RabbitMQ
搭建初始环境
新建模块
新建 springboot 模块:springboot_rabbitmq
引入依赖
1 | <dependency> |
配置配置文件
1 | server: |
RabbitTemplate
用来简化操作,使用时候直接在项目中注入即可使用。
hello world 模型使用
开发生产者
编写测试类
1 | // 注入 RabbitTemplate |
开发消费者
1 | package com.itjing.rabbitmq.hello; |
work 模型使用
开发生产者
1 |
|
开发消费者
1 | package com.itjing.rabbitmq.work; |
说明:默认在Spring AMQP实现中Work这种方式就是公平调度,如果需要实现能者多劳需要额外配置
Fanout 广播模型
开发生产者
1 | /** |
开发消费者
1 | package com.itjing.rabbitmq.fanout; |
Route 路由模型
开发生产者
1 |
|
开发消费者
1 | package com.itjing.rabbitmq.direct; |
Topic 订阅模型(动态路由模型)
开发生产者
1 |
|
开发消费者
1 | package com.itjing.rabbitmq.topic; |
MQ 的应用场景
异步处理
场景说明:用户注册后,需要发注册邮件和注册短信,传统的做法有两种 1.串行的方式 2.并行的方式
串行方式:
将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西.
并行方式:
将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。
消息队列:
假设三个业务节点分别使用 50ms,串行方式使用时间 150ms,并行使用时间 100ms。虽然并行已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响,客户端没有必要等着其发送完成才显示注册成功,应该是写入数据库后就返回。消息队列
: 引入消息队列后,把发送邮件,短信不是必须的业务逻辑异步处理
由此可以看出,引入消息队列后,用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的 3 倍,是并行的 2 倍。
应用解耦
场景:双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口.
这种做法有一个缺点:
当库存系统出现故障时,订单就会失败。 订单系统和库存系统高耦合, 引入消息队列 。
订单系统:
用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。库存系统:
订阅下单的消息,获取下单消息,进行库操作。 就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失。
流量削峰
场景:
秒杀活动,一般会因为流量过大,导致应用挂掉,为了解决这个问题,一般在应用前端加入消息队列。
作用:
可以控制活动人数,超过此一定阀值的订单直接丢弃(我为什么秒杀一次都没有成功过呢^^)
可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)
用户的请求,服务器收到之后,首先写入消息队列,加入消息队列长度超过最大值,则直接抛弃用户请求或跳转到错误页面。
秒杀业务根据消息队列中的请求信息,再做后续处理。
RabbitMQ 的集群
集群架构
普通集群(副本集群)
All data/state required for the operation of a RabbitMQ broker is replicated across all nodes. An exception to this are message queues, which by default reside on one node, though they are visible and reachable from all nodes. To replicate queues across nodes in a cluster –摘自官网
默认情况下:RabbitMQ代理操作所需的所有数据/状态都将跨所有节点复制。这方面的一个例外是消息队列,默认情况下,消息队列位于一个节点上,尽管它们可以从所有节点看到和访问
架构图
核心解决问题: 当集群中某一时刻master节点宕机,可以对Quene中信息,进行备份
集群搭建
1 | # 0.集群规划 |
1 | # 9.测试集群在 node1 上,创建队列 |
1 | # 10.查看 node2 和 node3 节点: |
1 | # 11.关闭 node1 节点,执行如下命令,查看 node2 和 node3: |
镜像集群
This guide covers mirroring (queue contents replication) of classic queues –摘自官网
By default, contents of a queue within a RabbitMQ cluster are located on a single node (the node on which the queue was declared). This is in contrast to exchanges and bindings, which can always be considered to be on all nodes. Queues can optionally be made mirrored across multiple nodes. –摘自官网
镜像队列机制就是将队列在三个节点之间设置主从关系,消息会在三个节点之间进行自动同步,且如果其中一个节点不可用,并不会导致消息丢失或服务不可用的情况,提升MQ集群的整体高可用性。
集群架构图
配置集群架构
1 | # 0.策略说明 |
发布时间: 2021-01-25
最后更新: 2024-06-24
本文标题: MQ消息中间件之RabbitMQ入门到实战教程
本文链接: https://blog-yilia.xiaojingge.com/posts/b5091e43.html
版权声明: 本作品采用 CC BY-NC-SA 4.0 许可协议进行许可。转载请注明出处!
