【RabbitMQ】RabbitMQ 的七种工作模式介绍
目录
上一篇文章中我们简单认识了RabbitM1:
【RabbitMQ】RabbitMQ 的概念以及使用RabbitMQ编写生产者消费者代码_rabbitmq 编程-CSDN博客
RabbitMQ 共提供了7种工作模式, 进行消息传递, 我们上一篇文章入门程序的案例, 其实就是一个简单模式.
官方文档:https://www.rabbitmq.com/tutorials
1. Simple(简单模式)
P: 生产者, 也就是要发送消息的程序
C: 消费者, 消息的接收者
Queue: 消息队列, 图中黄色背景部分. 类似一个邮箱, 可以缓存消息; 生产者向其中投递消息, 消费者从其中取出消息
特点: 一个生产者P，一个消费者C, 消息只能被消费一次, 也称为点对点(Point-to-Point)模式
适用场景: 消息只能被单个消费者处理
2. Work Queue(工作队列)
一个生产者P，多个消费者C1, C2. 在多个消息的情况下, Work Oueue 会将消息分派给不同的消费者, 每个消费者都会接收到不同的消息.
特点: 消息不会重复, 分配给不同的消费者
适用场景: 集群环境中做异步处理
比如12306 短信通知服务, 订票成功后, 订单消息会发送到RabbitMO, 短信服务从RabbitMO中获取订单信息, 并发送通知信息(在短信服务之间进行任务分配)
3. Publish/Subscribe(发布/订阅)
图中X表示交换机, 在订阅模型中，多了一个Exchange角色, 过程略有变化
概念介绍
Exchange: 交换机(X).
作用: 生产者将消息发送到Exchange,由交换机将消息按一定规则路由到一个或多个队列中(上图中生产者将消息投递到队列中,实际上这个在RabbitMO中不会发生.
RabbitMO交换机有四种类型:fanout, direct, topic, headers, 不同类型有着不同的路由策略. AMOP协议里还有另外两种类型, System和自定义, 此处不再描述.
1. Fanout: 广播，将消息交给所有绑定到交换机的队列(Publish/Subscribe模式)
2. Direct: 定向，把消息交给符合指定routing key的队列(Routing模式)
3. Topic: 通配符，把消息交给符合routing pattern(路由模式)的队列(Topics模式)
4. headers 类型的交换器不依赖于路由键的匹配规则来路由消息,而是根据发送的消息内容中的
headers属性进行匹配. headers类型的交换器性能会很差, 而且也不实用, 基本上不会看到它的存在
Exchange(交换机)只负责转发消息, 不具备存储消息的能力, 因此如果没有任何队列与Exchange绑
定，或者没有符合路由规则的队列，那么消息就会丢失.
RoutingKey: 路由键, 生产者将消息发给交换器时, 指定的一个字符串, 用来告诉交换机应该如何处理这个消息.
Binding Key: 绑定. RabbitMQ中通过Binding (绑定) 将交换器与队列关联起来, 在绑定的时候一般会指定一个Binding Key, 这样RabbitMQ就知道如何正确地将消息路由到队列了,
比如下图: 如果在发送消息时, 设置了RoutingKey为orange, 消息就会路由到Q1
当消息的Routingkey与队列绑定的Bindingkey相匹配时，消息才会被路由到这个队列
BindingKey 其实也属于路由键中的一种, 官方解释为: the routingkey to use for the binding.
可以翻译为: 在绑定的时候使用的路由键, 大多数时候, 包括官方文档和RabbitMOJava API 中都把
BindingKey和RoutingKey看作RoutingKey, 为了避免混淆, 可以这么理解:
1. 在使用绑定的时候, 需要的路由键是BindingKey.
2. 在发送消息的时候, 需要的路由键是RoutingKey.
Publish/Subscribe模式
一个生产者P, 多个消费者C1, C2, X代表交换机消息复制多份，每个消费者接收相同的消息
生产者发送一条消息，经过交换机转发到多个不同的队列，多个不同的队列就有多个不同的消费者
适合场景: 消息需要被多个消费者同时接收的场景. 如: 实时通知或者广播消息
比如中国气象局发布"天气预报"的消息送入交换机, 新浪, 百度, 搜狐, 网易等门户网站接入消息,通过队列绑定到该交换机, 自动获取气象局推送的气象数据
4. Routing(路由模式)
路由模式是发布订阅模式的变种, 在发布订阅基础上, 增加路由key
发布订阅模式是无条件的将所有消息分发给所有消费者, 路由模式是Exchange根据RoutingKey的规则, 将数据筛选后发给对应的消费者队列
适合场景: 需要根据特定规则分发消息的场景
比如系统打印日志, 日志等级分为error, warning, info, debug, 就可以通过这种模式, 把不同的日志发送到不同的队列, 最终输出到不同的文件
5. Topics(通配符模式)
路由模式的升级版, 在routingKey的基础上, 增加了通配符的功能, 使之更加灵活
Topics和Routing的基本原理相同，即: 生产者将消息发给交换机，交换机根据RoutingKey将消息转
发给与RoutingKey匹配的队列. 类似于正则表达式的方式来定义Routingkey的模式
不同之处是: routingKey的匹配方式不同，Routing模式是相等匹配，topics模式是通配符匹配
适合场景: 需要灵活匹配和过滤消息的场景
6. RPC(RPC通信)
在RPC通信的过程中, 没有生产者和消费者, 比较像咱们RPC远程调用, 大概就是通过两个队列实现了一个可回调的过程
1. 客户端发送消息到一个指定的队列, 并在消息属性中设置replyTo字段, 这个字段指定了一个回调队列, 用于接收服务端的响应.
2. 服务端接收到请求后,处理请求并发送响应消息到replyTo指定的回调队列
3. 客户端在回调队列上等待响应消息.一旦收到响应，客户端会检查消息的correlationld属性，以
确保它是所期望的响应,
7. Publisher Confirms(发布确认)
Publisher Confirms模式是RabbitMQ提供的一种确保消息可靠发送到RabbitMQ服务器的机制。在这种模式下，生产者可以等待RabbitMO服务器的确认，以确保消息已经被服务器接收并处理
1.生产者将Channel设置为confirm模式(通过调用channel.confirmSelect()完成)后, 发布的每一条消
息都会获得一个唯一的ID, 生产者可以将这些序列号与消息关联起来，以便跟踪消息的状态
2.当消息被RabbitMO服务器接收并处理后，服务器会异步地向生产者发送一个确认(ACK)给生产者
(包含消息的唯一ID)，表明消息已经送达,
通过Publisher Confirms模式，生产者可以确保消息被RabbitMQ服务器成功接收,从而避免消息丢失的问题.
适用场景: 对数据安全性要求较高的场景. 比如金融交易, 订单处理
原文地址：https://blog.csdn.net/m0_73648729/article/details/142904133
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！