0


RabbitMQ架构详解

文章目录

概述

RabbitMQ是⼀个高可用的消息中间件,支持多种协议和集群扩展。并且支持消息持久化和镜像队列,适用于对消息可靠性较高的场合
官网https://www.rabbitmq.com/getstarted.html

架构详解

在这里插入图片描述
在这里插入图片描述

RabbitMQ 是一个流行的开源消息队列系统,它实现了高级消息排队协议(AMQP)标准,提供了可靠的消息传递机制。下面是 RabbitMQ 的架构概述:

  1. 生产者(Producer):负责产生消息并发送到 RabbitMQ 服务器。消息可以包含任何类型的数据,例如 JSON、XML 等。
  2. 交换机(Exchange):接收来自生产者的消息,并将消息路由到一个或多个队列中。交换机有不同的类型,包括直连交换机(direct exchange)、主题交换机(topic exchange)、扇出交换机(fanout exchange)和头部交换机(headers exchange),每种类型的交换机都有不同的路由规则。
  3. 队列(Queue):消息最终存储在队列中,等待消费者处理。消费者可以订阅一个或多个队列,从队列中接收消息。
  4. 绑定(Binding):用于将交换机和队列连接起来,定义了消息的路由规则。
  5. 消费者(Consumer):订阅队列,并从中接收消息进行处理。 RabbitMQ 的架构支持高度的灵活性和可扩展性,可以根据需求配置多个交换机、队列和消费者,以满足复杂的消息处理需求。通过合理设计交换机和绑定,可以实现灵活的消息路由和过滤功能。 除了上述基本组件外,RabbitMQ 还包括虚拟主机(Virtual Host)、连接(Connection)、通道(Channel)等概念,用于提供更加复杂的消息处理和管理能力。 总的来说,RabbitMQ 提供了一个强大且灵活的消息传递平台,适用于各种异步通信和消息处理场景。

核心组件

它们分别是Product、Cunsumer、Broker、Connection、Channel、Queue、Exchange、Binding、VHost。
Broker:接收和分发消息的应用,RabbitMQ Server就是 Message Broker
Virtual host:出于多租户和安全因素设计的,把 AMQP 的基本组件划分到一个虚拟的分组中,类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时,可以划分出多个vhost,每个用户在自己的 vhost 创建 exchange/queue 等
Connection:publisher/consumer 和 broker 之间的 TCP 连接
Channel:如果每一次访问 RabbitMQ 都建立一个 Connection,在消息量大的时候建立 TCP Connection的开销将是巨大的,效率也较低。Channel 是在 connection 内部建立的逻辑连接,如果应用程序支持多线程,通常每个thread创建单独的 channel 进行通讯,AMQP method 包含了channel id 帮助客户端和message broker 识别 channel,所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP connection 的开销
Exchange:message 到达 broker 的第一站,根据分发规则,匹配查询表中的 routing key,分发消息到queue 中去。常用的类型有:direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
Queue:消息最终被送到这里等待 consumer 取走
Binding:exchange 和 queue 之间的虚拟连接,binding 中可以包含 routing key。Binding 信息被保存到 exchange 中的查询表中,用于 message 的分发依据
ConnectionFactory(连接管理器):应用程序与 Rabbit 之间建立连接的管理器,程序代码中使用。
Channel(信道):消息推送使用的通道。
Exchange(交换器):用于接受、分配消息。
Queue(队列):用于存储生产者的消息。
RoutingKey(路由键):用于把生成者的数据分配到交换器上。
BindingKey(绑定键):用于把交换器的消息绑定到队列上。

虚拟主机(Virtual Host)

虚拟主机(Virtual Host)是 RabbitMQ 中用于实现逻辑隔离的机制,类似于操作系统中的虚拟化技术。每个虚拟主机都是一个独立的、隔离的消息代理,拥有自己的交换机、队列、绑定和权限规则。虚拟主机可以让不同的应用程序或团队在同一个 RabbitMQ 服务器上共享相同的基础设施,同时保持彼此之间的隔离。
有虚拟主机的区别:

  1. 隔离性:每个虚拟主机之间是完全隔离的,它们拥有独立的命名空间,因此一个虚拟主机中的队列、交换机等元素不会影响到其他虚拟主机。
  2. 权限控制:你可以为每个虚拟主机设置独立的权限规则,从而实现对不同应用程序或团队的精细化权限控制。
  3. 灵活性:不同的应用程序可以在不同的虚拟主机中进行消息传递,而不会相互干扰。 没有虚拟主机的区别: 如果没有虚拟主机的概念,那么所有的交换机、队列和连接都将在全局范围内进行管理,这样会导致以下问题:
  4. 命名冲突:不同应用程序中可能会出现交换机、队列名称冲突,从而引起混乱。
  5. 权限管理困难:无法对不同的应用程序或团队进行灵活的权限控制。 综上所述,虚拟主机提供了一种有效的逻辑隔离机制,使得不同的应用程序或团队可以在同一台 RabbitMQ 服务器上共存而不相互干扰。如果没有虚拟主机的话,管理和维护起来将会变得更加困难并且容易产生混乱。

在 RabbitMQ 中,虚拟主机(Virtual Host)是用于实现逻辑隔离的机制,类似于操作系统中的虚拟化技术。每个虚拟主机都是一个独立的、隔离的消息代理,拥有自己的交换机、队列、绑定和权限规则。
在 RabbitMQ 中,虚拟主机名称可以使用斜杠(/)来分隔成多层路径,例如 “/myapp” 或者 “/team1/app1” 等。如果虚拟主机名称中包含了斜杠,则表示该虚拟主机名称是一个带有层级结构的路径。
带斜杠和不带斜杠的区别:

  1. 带斜杠的虚拟主机名称: 如果虚拟主机名称带有斜杠,那么这个虚拟主机名称就是一个路径,它可以表示多级目录结构。例如,“/myapp” 就可以表示一个名为 “myapp” 的虚拟主机,而 “/team1/app1” 则可以表示 “team1” 目录下的 “app1” 虚拟主机。带斜杠的虚拟主机名称可以让你更好地组织和管理虚拟主机,使得不同的团队或应用程序之间更加隔离。
  2. 不带斜杠的虚拟主机名称: 如果虚拟主机名称不带斜杠,那么这个虚拟主机名称就是一个简单的字符串。例如,“myapp” 就可以表示一个名为 “myapp” 的虚拟主机,但是它不能区分不同团队或应用程序之间的隔离。如果你只需要一个简单的、不带层级结构的虚拟主机,那么可以使用不带斜杠的虚拟主机名称。 综上所述,带斜杠和不带斜杠的虚拟主机名称都是有效的,但它们表示的含义不同。你可以根据实际情况选择合适的虚拟主机名称来组织你的应用程序或团队。 containerFactory连接管理器 在Spring AMQP中,containerFactory是用于配置消息监听器容器的工厂。通过指定containerFactory属性,你可以选择不同的容器工厂来创建和配置消息监听器容器。 使用containerFactory的目的如下:
  3. 自定义配置:可以根据需求自定义配置不同的消息监听器容器。每个容器工厂可以具有不同的配置,包括线程数、并发消费者数量、消息确认模式等,以便根据不同的业务需求进行调整。
  4. 多个队列监听:可以为不同的队列使用不同的容器工厂,以便对它们进行独立的配置,如并发消费者数量、线程池大小等。这样可以根据队列的特性和负载进行优化,以提高消息处理的性能和效率。
  5. 容器级别的设置:通过容器工厂,可以对容器本身进行一些全局级别的设置,例如错误处理器、消息转换器等。
  6. 集成其他组件:使用自定义的容器工厂,可以更轻松地集成其他组件或框架。例如,你可能需要与Spring Boot Actuator一起使用,以便在管理端点上暴露一些指标和统计信息。 总之,通过指定containerFactory属性并配置相应的容器工厂,你可以更加灵活地管理消息监听器容器,并根据需求进行个性化的配置和优化。

RabbitMQ 有几种广播类型

direct(默认方式):最基础最简单的模式,发送方把消息发送给订阅方,如果有多个订阅者,默认采取轮询的方式进行消息发送。
headers:与 direct 类似,只是性能很差,此类型几乎用不到。
fanout:分发模式,把消费分发给所有订阅者。
topic:匹配订阅模式,使用正则匹配到消息队列,能匹配到的都能接收到。

1topic模式,按照设置的路由信息(routing key)将消息路由到一个或者多个消费端,而消息只能由一个消费者消费一次。一个消费者可以设置多个路由信息,可以同时获取多个消费者发送的消息;
2fanout模式,与topic模式唯一的区别是同一消息会发送到订阅(binding)的多个消费者;
3direct模式,一对一模式,实际中比较少用;
4RPC模式,结合topic和direct模式,发送消息的同时指定要接受的消息。
i. 直连交换机,Direct exchange:带路由功能的交换机,根据routing_key(消息发送的时候需要指定)直接绑定到队列,⼀个交换机也可以通过过个routing_key绑定多个队列。
ii. 扇形交换机,Fanout exchange:⼴播消息。
iii. 主题交换机,Topic exchange:发送到主题交换机上的消息需要携带指定规则的routing_key,主题交换机会根据这个规则将数据发送到对应的(多个)队列上。
iv. ⾸部交换机,Headers exchange:⾸部交换机是忽略routing_key的⼀种路由⽅式。路由器和交换机路由的规则是通过Headers信息来交换的,这个有点像HTTP的Headers。将⼀个交换机声明成⾸部交换机,绑定⼀个队列的时候,定义⼀个Hash的数据结构,消息发送的时候,会携带⼀组hash数据结构的信息,当Hash的内容匹配上的时候,消息就会被写⼊队列 。

Direct :交换机会将消息中的Routing key与该Exchange所有Binding中的Routing key进行匹配,如果相等,就发送到该Binding对应的Queue中。
Fanout :交换机会将接收到的消息发送给所有与之绑定的队列。
Topic :将消息中的Routing key与该Exchange所有Binding中的Routing key进行匹配,匹配成功发送到该Binding对应的Queue中。routingKey必须是由点隔开的一系列的标识符组成(根据消息的特性以.隔开)。

  • *匹配一个标识符
  • #匹配0个或多个标识符 Headers :分发消息不依赖路由键,使用发送消息basicProperties对象中的headers来匹配的,将消息中的headers与该交换机中所有Binding中的参数进行匹配。

Exchange 属性说明:
Virtual host:属于哪个Virtual host。(如果有多个Virtual host的有此属性,一般默认的Virtual host是"/",Virtual host可以做最小粒度的权限控制。)
Name:名字,同一个Virtual host里面的Name不能重复。
Durability: 是否持久化 (Durable:持久化,Transient:不持久化)。
Auto delete:当最后一个绑定(队列或者exchange)被unbind之后,该exchange自动被删除。
Internal: 是否是内部专用exchange,是的话,就意味着我们不能往该exchange里面发消息。
Arguments: 参数,是AMQP协议留给AMQP实现做扩展使用的。alternate_exchange配置的时候,exchange根据路由路由不到对应的队列的时候,这时候消息被路由到指定的alternate_exchange的value值配置的exchange上。

扇出(fanout)交换机是将接收到到消息广播给它知道的所有队列,从而实现生产者发送一条消息,可以供多个消费者消费。
案例:一个生产者发送一条消息,通过扇出交换机,广播给两个消费者消费,如下图:

标签: rabbitmq

本文转载自: https://blog.csdn.net/Fireworkit/article/details/136564159
版权归原作者 思静语 所有, 如有侵权,请联系我们删除。

“RabbitMQ架构详解”的评论:

还没有评论