消息中间件 - RabbitMQ详解

本文介绍了RabbitMQ的基本概念,包括消息、生产者、交换器等核心组件,详细解析了RabbitMQ的工作原理,如消息路由机制及消息确认机制等。

一、消息中间件的作用

1.异步处理

在这里插入图片描述

2、应用解耦

在这里插入图片描述

3、流量控制

二、概述

RabbitMQ架构图:
在这里插入图片描述

在这里插入图片描述

1、大多应用中,可通过消息服务中间件来提升系统异步通信、扩展解耦能力;

2、消息服务中两个重要概念:
消息代理(message broker)和目的地(destination)
当消息发送者发送消息以后,将由消息代理接管,消息代理保证消息传递到指定目的地。

3、消息队列主要有两种形式的目的地
* 队列(queue): 消息队列主要有两种形式的目的地
* 主题(topic): 发布(publish)/订阅(subscribe)消息通信

4、点对点式

  • 消息发送者发送消息,消息代理将其放入一个队列中,消息接收者从队列中获取消息内容,消息读取后被移出队列。
  • 消息只有唯一的发送者和接受者,但并不是说只能有一个接收者。

5、发布订阅式

  • 发送者(发布者)发送消息到主题,多个接收者(订阅者)监听(订阅)这个主题,那么就会在消息到达时同时收到消息。

6、JMS(Java Message Service)JAVA消息服务:

  • 基于JVM消息代理的规范。ActiveMQ、HornetMQ是JMS实现

7、AMQP(Advanced Message Queuing Protocol)

  • 高级消息队列协议,也是一个消息代理的规范,兼容JMS
  • RabbitMQ是AMQP的实现

8、Spring支持

  • spring-jms提供了对JMS的支持
  • spring-rabbit提供了对AMQP的支持
  • 需要ConnectionFactory的实现来连接消息代理
  • 提供JmsTemplate、RabbitTemplate来发送消息
  • @JmsListener(JMS)、@RabbitListener(AMQP)注解在方法上监听消息代理发布的消息
  • @EnableJms、@EnableRabbit开启支持

RabbitMQ概念

RabbitMQ简介

RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue Protocol)的开源实现。

核心概念

1、Message
消息,消息是不具名的,它由消息头和消息体组成。消息体是不透明的,而消息头则由一系列的可选属性组成,这些属性包括routing-key(路由键)、priority(相对于其他消息的优先权)、delivery-mode(指出该消息可能需要持久性存储)等

2、Publisher
消息的生产者,也是一个向交换器发布消息的客户端应用程序

3、Exchange
交换器,用来接收生产者发送的消息并将这些消息路由给服务器中的队列。Exchange有4种类型:direct(默认),fanout, topic, 和headers,不同类型的Exchange转发消息的策略有所区别

4、Queue
消息队列,用来保存消息直到发送给消费者。它是消息的容器,也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面,等待消费者连接到这个队列将其取走。

5、Binding
绑定,用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则,所以可以将交换器理解成一个由绑定构成的路由表。
Exchange 和Queue的绑定可以是多对多的关系。

6、Connection
网络连接,比如一个TCP连接。

7、Channel
信道,多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚拟连接,AMQP 命令都是通过信道发出去的,不管是发布消息、订阅队列还是接收消息,这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销,所以引入了信道的概念,以复用一条 TCP 连接。

8、Consumer
消息的消费者,表示一个从消息队列中取得消息的客户端应用程序。

9、Virtual Host
虚拟主机,表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器,拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础,必须在连接时指定,RabbitMQ 默认的vhost 是 / 。

10、Broker
表示消息队列服务器实体

RabbitMQ运行机制

AMQP中的消息路由

AMQP中消息的路由过程和java开发者熟悉的JMS存在一些差别,AMQP中增加了Exchange和Binding的角色。生产者把消息发布到Exchange上,消息最终到达队列并被消费者接收,而Binding决定交换器的消息应该发送到哪个队列。

Exchange类型
  • Exchange分发消息时根据类型的不同分发策略有区别,目前共四种类型:direct、fanout、topic、headers 。headers 匹配 AMQP 消息的 header 而不是路由键,headers 交换器和 direct 交换器完全一致,但性能差很多,目前几乎用不到了,所以直接看另外三种类型:

  • 1、Direct Exchange
    消息中的路由键(routing key)如果和Binding 中的 binding key 一致, 交换器就将消息发到对应的队列中。路由键与队列名完全匹配,如果一个队列绑定到交换机要求路由键为“dog”,则只转发 routingkey 标记为“dog”的消息,不会转发“dog.puppy”,也不会转发“dog.guard” 等等。它是完全匹配、单播的模式
    在这里插入图片描述

  • 2、Fanout Exchange(扇出交换器)
    每个发到fanout类型的交换器的消息都会分到所有绑定的队列上去。fanout交换器不处理路由键,只是简单的将队列绑定到交换器上,每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上
    在这里插入图片描述

  • Topic Exchange
    topic 交换器通过模式匹配分配消息的路由键属性,将路由键和某个模式进行匹配,此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串切分成单词,这些单词之间用点隔开。它同样也会识别两个通配符:符号“#”和符号“*”。#匹配0个或多个单词,*匹配一个单词。
    在这里插入图片描述

RabbitMQ消息确认机制 - 可靠抵达

1、可靠抵达-ConfirmCallback

需要在配置文件中设置开启发送端消息抵达Broker确认

spring.rabbitmq.publisher-confirms=true

1、在创建 connectionFactory 的时候设置 PublisherConfirms(true) 选项,开启confirmcallback。
2、消息只要被 broker 接收到就会执行 confirmCallback,如果是 cluster 模式,需要所有broker 接收到才会调用 confirmCallback。
3、被 broker 接收到只能表示 message 已经到达服务器,并不能保证消息一定会被投递到目标 queue 里。所以需要用到接下来的 returnCallback。

2、可靠抵达-ReturnCallback

需要在配置文件中设置开启发送端消息抵达Queue确认

# 开启发送端消息抵达Queue确认
spring.rabbitmq.publisher-returns=true
# 只要消息抵达Queue,就会异步发送优先回调returnfirm
spring.rabbitmq.template.mandatory=true

1、confrim 模式只能保证消息到达 broker,不能保证消息准确投递到目标 queue 里。在有
些业务场景下,我们需要保证消息一定要投递到目标 queue 里,此时就需要用到return 退回模式。

2、这样如果未能投递到目标 queue 里将调用 returnCallback ,可以记录下详细到投递数
据,定期的巡检或者自动纠错都需要这些数据。

3、可靠抵达-Ack消息确认机制

1、消费者获取到消息,成功处理,可以回复Ack给Broker

  • basic.ack用于肯定确认;broker将移除此消息
  • basic.nack用于否定确认;可以指定broker是否丢弃此消息,可以批量
  • basic.reject用于否定确认;同上,但不能批量

2、默认自动ack,消息被消费者收到,就会从broker的queue中移除

3、queue无消费者,消息依然会被存储,直到消费者消费

4、消费者收到消息,默认会自动ack。但是如果无法确定此消息是否被处理完成,
或者成功处理。我们可以开启手动ack模式

  • 消息处理成功,ack(),接受下一个消息,此消息broker就会移除
  • 消息处理失败,nack()/reject(),重新发送给其他人进行处理,或者容错处理后ack
  • 消息一直没有调用ack/nack方法,broker认为此消息正在被处理,不会投递给别人,此时客户
    端断开,消息不会被broker移除,会投递给别人。
<think>好的,用户想了解如何创建或设计系统架构图,包括工具、方法和示例。首先,我需要回忆一下系统架构设计的基本概念和相关方法。根据引用[1],系统架构设计需要内聚和良好的设计表示,这说明架构图应该清晰展示各个模块的关系和层次结构。然后,用户提供的引用中有提到微服务应用的模块划分,比如Infrastructure、Domain等,这可能是一个示例结构,可以参考。 接下来,用户可能想知道具体步骤。根据引用[4],架构图的关键是准确表达设计意图,而不是纠结于图形标准。所以,在设计架构图时,重点应该放在逻辑结构上,而不是图形的美观程度。需要分步骤说明:明确目标、确定核心组件、分层设计、选择视图类型、工具选择、绘制和验证。 工具方面,常用的有Draw.io、Lucidchart、Visio、PlantUML等,这些工具各有特点,用户可能需要免费或付费的选择,所以需要列举几个常见的。另外,引用[3]提到部署图,可能需要说明不同类型的架构图,比如逻辑视图、物理视图、部署视图等,每种视图的用途和示例。 示例部分,可以举一个电商系统的分层架构,结合引用[2]中的模块划分,比如基础设施层、领域层等,这样用户更容易理解。同时,需要强调根据项目特点调整架构图,比如微服务架构可能需要更多的服务拆分展示。 还要考虑用户可能的后续问题,比如如何优化架构设计,或者具体工具的使用方法,所以在相关问题中可以加入这些方面。最后,确保引用正确,每个引用对应的内容在回答中自然出现,比如引用[4]关于沟通思想的部分,应该在强调设计意图时提到。</think>### 如何设计系统架构图? #### 一、设计原则与方法 1. **明确目标** 架构图需反映系统的核心功能、模块划分与交互关系。例如,微服务架构需突出服务边界和通信机制[^2],而单体架构可能更关注分层逻辑(如基础设施层、领域层等)。 2. **确定核心组件** 根据引用[1]的“内聚设计”原则,识别系统的核心模块(如用户管理、订单处理、数据存储),并通过颜色或形状区分层级(应用层、中间件层、数据库层)。 3. **分层设计** 参考分层架构示例: ```plaintext |—— Interfaces(接口层:API/Web) |—— Application(应用层:业务逻辑) |—— Domain(领域层:核心模型) |—— Infrastructure(基础设施层:数据库/消息队列) ``` 这种分层方式符合模块化设计思想[^2]。 4. **选择视图类型** - **逻辑视图**:展示模块间关系,如类图或组件图。 - **物理视图**:体现服务器、网络拓扑等部署细节(引用[3]的部署图要求)。 - **动态视图**:描述请求流程或事件时序,如序列图。 #### 二、工具推荐 | 工具 | 特点 | 适用场景 | |--------------|-----------------------------|----------------------| | **Draw.io** | 免费、在线协作、模板丰富 | 快速绘制逻辑/物理视图 | | **Lucidchart**| 支持实时协作、集成Confluence/Jira | 团队协作文档化 | | **PlantUML** | 代码生成图表、版本友好 | 开发人员偏好文本化设计 | | **Visio** | 专业、本地化操作 | 企业级复杂架构图 | #### 三、设计示例:电商系统架构图 ```plaintext +-------------------+ | 用户界面层 | | (Web/APP/API网关) | +---------+---------+ | v +-------------------+ | 应用服务层 | | (订单/支付/库存服务) | +---------+---------+ | v +-------------------+ | 领域模型层 | | (商品/用户/交易实体) | +---------+---------+ | v +-------------------+ | 基础设施层 | | (MySQL/Redis/MQ) | +-------------------+ ``` *注:箭头表示依赖方向,层级间通过接口解耦[^2]* #### 四、验证与优化 1. **一致性检查**:确保架构图与实际代码结构匹配(如引用[2]的微服务模块划分)。 2. **可读性优化**:用注释说明关键设计决策,避免过度复杂(引用[4]强调意图清晰优先于形式规范)。 3. **迭代更新**:随需求变更同步调整架构图,保持“活的文档”状态。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值