【RabbitMQ】-- 七种工作模式

文章目录

  • [2. RabbitMQ七种工作模式](#2. RabbitMQ七种工作模式)
    • [2.1 Simple(简单工作模式)](#2.1 Simple(简单工作模式))
    • [2.2 Work Queue(工作队列)](#2.2 Work Queue(工作队列))
    • [2.3 Publish/Subscribe(发布/订阅模式)](#2.3 Publish/Subscribe(发布/订阅模式))
    • [2.4 Routing(路由模式)](#2.4 Routing(路由模式))
    • [2.5 Topics(通配符模式)](#2.5 Topics(通配符模式))
    • [2.6 RPC(RPC通信模式)](#2.6 RPC(RPC通信模式))
    • [2.7 Publisher Confirms(发布确认模式--异步)](#2.7 Publisher Confirms(发布确认模式--异步))

更多RabbitMQ相关知识:RabbitMQ专栏

2. RabbitMQ七种工作模式

2.1 Simple(简单工作模式)

  1. 一个生产者,一个消费者。
  2. 消息只能被消费一次。也称为点对点模式。
  3. 适用场景:消息只能被单个消费者处理。

2.2 Work Queue(工作队列)

  1. 一个生产者,多个消费者。
  2. 消息只有一份,多个消费者共同消费所有的消息,每条消息不会被重复消费。
  3. 适用场景:集群环境中做异步处理。

2.3 Publish/Subscribe(发布/订阅模式)

与上面两种工作模式相比,发布订阅模式的图中多了交换机的概念。但是,并不说上面的两种工作模式中没有交换机,其实是有的,只是在上面的途中没有画出来而已。在Rabbit MQ中发布消息一定会经过交换机。

只不过与前两种工作模式相比,发布订阅模式中的交换机起到的作用不同:
简单工作模式 & 工作队列模式: 消息只有一份,交换机起到消息转发的作用。
发布订阅模式: 交换机会将消息转发给所有绑定到交换机的队列。消息可能不再是只有一份。

  1. 一个生产者多个消费者。
  2. 交换机将消息复制多份,每个消费者接收相同的消息。
  3. 适用场景:消息需要被多个消费者同时接收的场景。

2.4 Routing(路由模式)

  1. 路由模式是发布订阅模式的变种, 在发布订阅基础上, 增加路由key。
  2. 发布订阅模式是⽆条件的将所有消息分发给所有消费者, 路由模式是Exchange根据RoutingKey的规则,将数据筛选后发给对应的消费者队列。
  3. 适合场景: 需要根据特定规则分发消息的场景.

2.5 Topics(通配符模式)

  1. 路由模式的升级版, 在routingKey的基础上,增加了通配符的功能.
  2. Topics和Routing的基本原理相同,即:⽣产者将消息发给交换机,交换机根据RoutingKey将消息转发给与RoutingKey匹配的队列. 类似于正则表达式的⽅式来定义Routingkey的模式.
  3. 适合场景: 需要灵活匹配和过滤消息的场景.

2.6 RPC(RPC通信模式)

RPC:远程过程调用。

在PRC通信的过程中,没有生产者和消费者。RabbitMQ 实现RPC通信的过程,大概就是通过两个队列实现一个可回调的过程。

  1. 客户端发送一个消息到指定队列,并在消息属性中设置replyTo字段,这个字段指定了一个回调队列,服务端处理后,会把响应结果发送到这个队列;消息中还会携带一个correlationId。
  2. 服务端接收到请求之后,处理请求并发送响应消息到replyTo指定的回调队列中,与此同时,这条消息中依旧携带着correlationId。
  3. 客户端在回调队列上等待响应消息,一旦收到响应,客户端会检查消息的correlationId属性,以确保它是所期望的响应。

2.7 Publisher Confirms(发布确认模式--异步)

发布确认模式是 RabbitMQ 消息可靠性保证的机制。发布确认有三种策略:

  1. 单独确认策略:每一条消息都单独进行确认。

  2. 批量确认策略:消息达到指定数量后进行确认。

  3. 异步确认策略(性能最好):生产者可以同时发布消息和等待信道返回确认消息。

  1. 在这种模式下,需要生产者将信道设置成confirm模式,一旦信道进入confirm模式,所有在该信道上发布的每一条消息都会被指派一个唯一的ID(ID以信道为边界,从1开始),生产者可以将这些序列号与消息关联起来,以便跟踪消息的状态。

  2. 当消息被RabbitMQ服务器接收并处理后,服务器会异步地向生产者发送一个ACK(包含消息的唯一ID)给生产者,表示消息已经送达。如果消息和队列是持久化的,那么确认消息会在将消息写入磁盘之后发出。

  3. 当消息最终得到确认之后没生产者可以通过回调方法来处理该确认消息;如果发生错误导致消息丢失,就会发出nack命令,生产者同样可以在回调方法中处理该nack命令。

  4. 适用场景:对数据安全性要求比较高的场景。

发布确认模式下,生产者可以确保消息被RabbitMQ Server成功接收,从而避免消息丢失 ;但是并不能确保消息会被消费者正常消费

相关推荐
洛豳枭薰2 小时前
消息队列关键问题描述
kafka·rabbitmq·rocketmq
Coder_Boy_2 小时前
基于Spring AI的分布式在线考试系统-事件处理架构实现方案
人工智能·spring boot·分布式·spring
袁煦丞 cpolar内网穿透实验室3 小时前
远程调试内网 Kafka 不再求运维!cpolar 内网穿透实验室第 791 个成功挑战
运维·分布式·kafka·远程工作·内网穿透·cpolar
人间打气筒(Ada)4 小时前
GlusterFS实现KVM高可用及热迁移
分布式·虚拟化·kvm·高可用·glusterfs·热迁移
xu_yule4 小时前
Redis存储(15)Redis的应用_分布式锁_Lua脚本/Redlock算法
数据库·redis·分布式
難釋懷8 小时前
分布式锁的原子性问题
分布式
ai_xiaogui9 小时前
【开源前瞻】从“咸鱼”到“超级个体”:谈谈 Panelai 分布式子服务器管理系统的设计架构与 UI 演进
服务器·分布式·架构·分布式架构·panelai·开源面板·ai工具开发
凯子坚持 c9 小时前
如何基于 CANN 原生能力,构建一个支持 QoS 感知的 LLM 推理调度器
分布式
飞升不如收破烂~9 小时前
Redis 分布式锁+接口幂等性使用+当下流行的限流方案「落地实操」+用户连续点击两下按钮的解决方案自用总结
数据库·redis·分布式