![4b1ee71e3ac5965870ca86b943077b5b.png](https://i-blog.csdnimg.cn/blog_migrate/9ddb97e84354ecdfa56b60ca877f3c58.jpeg)
RabbitMQ是一个基于AMQP协议实现的企业级消息系统,想要顺畅的玩耍的前提是得先了解它,本文将主要介绍rabbitmq的一些基本知识点
- 特点
- 基本概念
- 消息投递消费的几种姿势
- 事务
- 集群
I. 基本知识点
它是采用Erlang语言实现的AMQP(Advanced Message Queued Protocol)的消息中间件,最初起源于金融系统,用在分布式系统存储转发消息,目前广泛应用于各类系统用于解耦、削峰
1.特点
首先得了解一下rabbitmq的特点,看看是否满足我们的系统需求(毕竟学习一个框架也是要不少时间的)
以下内容来自: MQ和RabbitMQ作用特点
主要特点,大致可以归纳为以下几个
- 可靠性:通过支持消息持久化,支持事务,支持消费和传输的ack等来确保可靠性
- 路由机制:支持主流的订阅消费模式,如广播,订阅,headers匹配等
- 扩展性:多个RabbitMQ节点可以组成一个集群,也可以根据实际业务情况动态地扩展集群中节点。
- 高可用性:队列可以在集群中的机器上设置镜像,使得在部分节点出现问题的情况下队仍然可用。
- 多种协议:RabbitMQ除了原生支持AMQP协议,还支持STOMP,MQTT等多种消息中间件协议。
- 多语言客户端:RabbitMQ几乎支持所有常用语言,比如Jav a、Python、Ruby、PHP、C#、JavaScript等。
- 管理界面:RabbitMQ提供了一个易用的用户界面,使得用户可以监控和管理消息、集群中的节点等。
- 插件机制:RabbitMQ提供了许多插件,以实现从多方面进行扩展,当然也可以编写自己的插件。
2. 基本概念
下图为rabbitmq的内部结构图
![eb1ba88840206d8edb79f4e31ae8ec4f.png](https://i-blog.csdnimg.cn/blog_migrate/864616761d391525e440300dd26030d0.jpeg)
从上图也可以发现几个基本概念(Message, Publisher, Exchange, Binding, Queue, Channel, Consuer, Virtual host)
下面逐一进行说明
a. Message
具体的消息,包含消息头(即附属的配置信息)和消息体(即消息的实体内容)
由发布者,将消息推送到Exchange,由消费者从Queue中获取
b. Publisher
消息生产者,负责将消息发布到交换器(Exchange)
c. Exchange
交换器,用来接收生产者发送的消息并将这些消息路由给服务器中的队列
d. Binding
绑定,用于给Exchange和Queue建立关系,从而决定将这个交换器中的哪些消息,发送到对应的Queue
e. Queue
消息队列,用来保存消息直到发送给消费者
它是消息的容器,也是消息的终点
一个消息可投入一个或多个队列
消息一直在队列里面,等待消费者连接到这个队列将其取走
f. Connection
连接,内部持有一些channel,用于和queue打交道
g. Channel
信道(通道),MQ与外部打交道都是通过Channel来的,发布消息、订阅队列还是接收消息,这些动作都是通过Channel完成;
简单来说就是消息通过Channel塞进队列或者流出队列
h. Consumer
消费者,从消息队列中获取消息的主体
i. Virtual Host
虚拟主机,表示一批交换器、消息队列和相关对象。
虚拟主机是共享相同的身份认证和加密环境的独立服务器域。
每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器,拥有自己的队列、交换器、绑定和权限机制。
vhost 是 AMQP 概念的基础,必须在连接时指定,RabbitMQ 默认的 vhost 是 /
可以理解为db中的数据库的概念,用于逻辑拆分
j. Broker
消息队列服务器实体
3. 消息投递消费
从前面的内部结构图可以知晓,消息由生产者发布到Exchange,然后通过路由规则,分发到绑定queue上,供消费者获取消息
接下来我们看一下Exchange支持的四种策略
a. Direct策略
![36a1400d9917c207d89e71fb15ff1e46.png](https://i-blog.csdnimg.cn/blog_migrate/051e24c1e88cec768275f328faccdf7a.jpeg)
消息中的路由键(routing key)如果和 Binding 中的 binding key 一致, 交换器就将消息发到对应的队列中
简单来讲,就是rounting key与binding key完全匹配
- 如果一个队列绑定到交换机要求路由键为dog
- 只转发routing key 标记为dog的消息,
- 不会转发dog.puppy,也不会转发“dog.guard”等等
- 它是完全匹配、单播的模式
举例说明
![ba9b7faaeafd97f53b1c52f61a5bbbed.png](https://i-blog.csdnimg.cn/blog_migrate/c559315c60f5ced087752c062ceb0c32.jpeg)
Exchange和两个队列绑定在一起:
- Q1的bindingkey是orange
- Q2的binding key是black和green.
- 当Producer 发布一个消息,其routing key是orange时, exchange会把它放到Q1上, 如果是black或green就会到Q2上, 其余的Message被丢弃
注意
- 当有多个队列绑定到同一个Exchange,且binding key相同时,这时消息会分发给所有满足条件的队列
b. Topic策略
![29cfa219df54e5deb985c34882794c9c.png](https://i-blog.csdnimg.cn/blog_migrate/0f42cb21875698ed05c439fc706a4a6c.jpeg)
这个策略可以看成是Direct策略的升级版,通过routing key与 bingding key的模式匹配方式来分发消息
简单来讲,直接策略是完全精确匹配,而topic则支持正则匹配,满足某类指定规则的(如以xxx开头的路由键),可以将消息分发过去
- # 匹配0个或多个单词
- * 匹配不多不少一个单词
一个更直观的实例如下
![4114ae3b80aa9cc072f3f1ef7e08f144.png](https://i-blog.csdnimg.cn/blog_migrate/1b770aae2088f314c70c1fc401f997be.jpeg)
Producer发送消息时需要设置routing_key,
- Q1 的binding key 是*.orange.*
- Q2 是 *.*.rabbit 和 lazy.#:
- 发布一个routing key为test.orange.mm 消息,则会路由到Q1;注意: 如果是routng key是 test.orange则无法路由到Q1,因为Q1的规则是三个单词,中间一个为orange,不满足这个规则的都无效
- 发布一个routing key为test.qq.rabbit或者lazy.qq的消息 都可以分发到Q2;即路由key为三个单词,最后一个为rabbit或者不限制单词个数,主要第一个是lazy的消息,都可以分发过来
- 如果发布的是一个test.orange.rabbit消息,则Q1和Q2都可以满足注意: 这时两个队列都会接受到这个消息
c. Fanout策略
![08f183445bc879b37d08e4b7bb2a102e.png](https://i-blog.csdnimg.cn/blog_migrate/fffd5e7ba04c25c4c82647cfd538bc9b.jpeg)
广播策略,忽略routing key 和 binding key,将消息分发给所有绑定在这个exchange上的queue
d. Headers策略
这个实际上用得不多,它是根据Message的一些头部信息来分发过滤Message,忽略routing key的属性,如果Header信息和message消息的头信息相匹配
II. 消息一致性问题
在进入rabbitmq如何保证一致性之前,我们先得理解,什么是消息一致性?
1. 一致性问题
数据的一致性是什么
按照我个人的粗浅理解,我认为的消息一致性,应该包含下面几个
- 生产者,确保消息发布成功消息不会丢顺序不会乱消息不会重复(如重传,导致发布一次,却出现多个消息)
- 消费者,确保消息消费成功有序消费不重复消费
发送端
为了确保发布者推送的消息不会丢失,我们需要消息持久化
- broker持久化消息
为了确定消息正确接收
- publisher 需要知道消息投递并成功持久化
2. 持久化
这里的持久化,主要是指将内存中的消息保存到磁盘,避免mq宕机导致的内存中消息丢失;然而单纯的持久化,只是保证一致性的其中一个要素,比如publisher将消息发送到exchange,在broker持久化的工程中,宕机了导致持久化失败,而publisher并不知道持久化失败,这个时候就会出现数据丢失,为了解决这个问题,rabbitmq提供了事务机制
3. 事务机制
事务机制能够解决生产者与broker之间消息确认的问题,只有消息成功被broker接受,事务才能提交成功,否则就进行事务回滚操作并进行消息重发。但是使用事务机制会降低RabbitMQ的消息吞吐量,不适用于需要发布大量消息的业务场景。
注意,事务是同步的
4. 消息确认机制
RabbitMQ学习(六)——消息确认机制(Confirm模式)
消息确认机制,可以区分为生产端和消费端
生产端
- 生产者将信道设置成Confirm模式,一旦信道进入Confirm模式,所有在该信道上面发布的消息都会被指派一个唯一的ID(以confirm.select为基础从1开始计数),
- 一旦消息被投递到所有匹配的队列之后,Broker就会发送一个确认给生产者(包含消息的唯一ID),这就使得生产者知道消息已经正确到达目的队列了,
- 如果消息和队列是可持久化的,那么确认消息会将消息写入磁盘之后发出,
- Broker回传给生产者的确认消息中deliver-tag域包含了确认消息的序列号(此外Broker也可以设置basic.ack的multiple域,表示到这个序列号之前的所有消息都已经得到了处理)
Confirm模式属性异步,publisher发布一条消息之后,在等信道返回确认的同时,依然可以继续发送下一条消息,所以小概率会出现投递的消息顺序和broker中持久化消息顺序不一致的问题
一般从编程角度出发,Confirm模式有三种姿势
- 普通Confirm模式:发送一条消息之后,等到服务器confirm,然后再发布下一条消息(串行发布)
- 批量Confirm模式:发送一批消息之后,等到服务器confirm,然后再发布下一批消息(如果失败,这一批消息全部重复,所以会有重复问题)
- 异步Confirm模式:提供一个回调方法,服务器confirm之后,触发回调方法,因此不会阻塞下一条消息的发送
消费端
ACK机制是消费者从RabbitMQ收到消息并处理完成后,反馈给RabbitMQ,RabbitMQ收到反馈后才将此消息从队列中删除。
- 如果一个消费者在处理消息出现了网络不稳定、服务器异常等现象,那么就不会有ACK反馈,RabbitMQ会认为这个消息没有正常消费,会将消息重新放入队列中
- 如果在集群的情况下,RabbitMQ会立即将这个消息推送给这个在线的其他消费者。这种机制保证了在消费者服务端故障的时候,不丢失任何消息和任务
- 消息永远不会从RabbitMQ中删除,只有当消费者正确发送ACK反馈,RabbitMQ确认收到后,消息才会从RabbitMQ服务器的数据中删除
III. 集群
按照目前的发展趋势,一个不支持集群的中间件基本上是不会有市场的;rabbitmq也是支持集群的,下面简单的介绍一下常见的4种集群架构模式
以下内容来自网上博文,详情请点击右边:RabbitMQ 的4种集群架构
1. 主备模式
这个属于常见的集群模式了,但又不太一样
主节点提供读写,备用节点不提供读写。如果主节点挂了,就切换到备用节点,原来的备用节点升级为主节点提供读写服务,当原来的主节点恢复运行后,原来的主节点就变成备用节点
2. 远程模式
远程模式可以实现双活的一种模式,简称 shovel 模式,所谓的 shovel 就是把消息进行不同数据中心的复制工作,可以跨地域的让两个 MQ 集群互联,远距离通信和复制。
- Shovel 就是我们可以把消息进行数据中心的复制工作,我们可以跨地域的让两个 MQ 集群互联。
![07f8f5918c2fe8740b14da4293f64885.png](https://i-blog.csdnimg.cn/blog_migrate/df8e2b9753fe1944b854146cd7def3fd.jpeg)
如上图,有两个异地的 MQ 集群(可以是更多的集群),当用户在地区 1 这里下单了,系统发消息到 1 区的 MQ 服务器,发现 MQ 服务已超过设定的阈值,负载过高,这条消息就会被转到 地区 2 的 MQ 服务器上,由 2 区的去执行后面的业务逻辑,相当于分摊我们的服务压力。
3. 镜像模式
非常经典的 mirror 镜像模式,保证 100% 数据不丢失。在实际工作中也是用得最多的,并且实现非常的简单,一般互联网大厂都会构建这种镜像集群模式。
![71f17e078f3e1a484caff35523b2b0ad.png](https://i-blog.csdnimg.cn/blog_migrate/a0f20d926d180e389d9159c871b5d4a4.jpeg)
如上图,用 KeepAlived 做了 HA-Proxy 的高可用,然后有 3 个节点的 MQ 服务,消息发送到主节点上,主节点通过 mirror 队列把数据同步到其他的 MQ 节点,这样来实现其高可靠
4. 多活模式
也是实现异地数据复制的主流模式,因为 shovel 模式配置比较复杂,所以一般来说,实现异地集群的都是采用这种双活 或者 多活模型来实现的。这种模式需要依赖 rabbitMQ 的 federation 插件,可以实现持续的,可靠的 AMQP 数据通信,多活模式在实际配置与应用非常的简单
rabbitMQ 部署架构采用双中心模式(多中心),那么在两套(或多套)数据中心各部署一套 rabbitMQ 集群,各中心的rabbitMQ 服务除了需要为业务提供正常的消息服务外,中心之间还需要实现部分队列消息共享。
![9b501965b2bf6978c6720c1b6d6c9ee0.png](https://i-blog.csdnimg.cn/blog_migrate/22ef1997396bc278be2922e780ba4343.jpeg)
federation 插件是一个不需要构建 cluster ,而在 brokers 之间传输消息的高性能插件,federation 插件可以在 brokers 或者 cluster 之间传输消息,连接的双方可以使用不同的 users 和 virtual hosts,双方也可以使用不同版本的 rabbitMQ 和 erlang。federation 插件使用 AMQP 协议通信,可以接受不连续的传输。federation 不是建立在集群上的,而是建立在单个节点上的,如图上黄色的 rabbit node 3 可以与绿色的 node1、node2、node3 中的任意一个利用 federation 插件进行数据同步。
IV. 其他
0. 项目
- 工程:https://github.com/liuyueyi/spring-boot-demo
1. 相关博文
- RabbitMQ Tutorials
- MQ和RabbitMQ作用特点
- RabbitMq基础教程之基本概念
- RabbitMQ学习(六)——消息确认机制(Confirm模式)
- RabbitMQ 的4种集群架构
- Rabbitmq是如何来保证事务的
- rabbitmq消息一致性问题
2. 一灰灰Blog
尽信书则不如,以上内容,纯属一家之言,因个人能力有限,难免有疏漏和错误之处,如发现bug或者有更好的建议,欢迎批评指正,不吝感激
下面一灰灰的个人博客,记录所有学习和工作中的博文,欢迎大家前去逛逛
- 一灰灰Blog个人博客 https://blog.hhui.top
- 一灰灰Blog-Spring专题博客 http://spring.hhui.top