【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成功接收,从而避免消息丢失 ;但是并不能确保消息会被消费者正常消费

相关推荐
笃行客从不躺平1 小时前
Token 复习
java·分布式·spring cloud
u0104058363 小时前
分布式淘客系统的配置中心设计:Nacos在多环境配置管理的应用
分布式
迎仔4 小时前
01-Hadoop 核心三剑客通俗指南:从“单机搬砖”到“包工队”
大数据·hadoop·分布式
ALex_zry4 小时前
分布式缓存与微服务架构的集成
分布式·缓存·架构
ALex_zry5 小时前
分布式缓存安全最佳实践
分布式·安全·缓存
陌上丨8 小时前
分布式锁的特性是什么?如何实现分布式锁?
分布式
yangSnowy8 小时前
MySQL 分布式锁实现方案
数据库·分布式·mysql
ALex_zry9 小时前
分布式缓存性能优化策略
分布式·缓存·性能优化
七夜zippoe9 小时前
分布式配置中心终极对决 Spring Cloud Config与Apollo架构深度解析
分布式·架构·springcloud·apollo·配置中心
迎仔9 小时前
09-消息队列Kafka介绍:大数据世界的“物流枢纽”
大数据·分布式·kafka