前言

RabbitMQ 共提供了7种工作模式, 进⾏消息传递, 我们入门程序的案例（生产者消费者模型）, 其实就是⼀个简单模式.

官方文档

一、Simple (简单模式)

·P: 生产者, 也就是要发送消息的程序
·C: 消费者,消息的接收者
·Queue: 消息队列, 图中黄色背景部分. 类似⼀个邮箱, 可以缓存消息; 生产者向其中投递消息, 消费者从其中取出消息.
·特点: 一个生产者P，一个消费者C, 消息只能被消费⼀次. 也称为 点对点(Point-to-Point) 模式.
·适用场景: 消息只能被单个消费者处理

二、Work Queue (工作队列)

·一个生产者P，多个消费者C1,C2. 在多个消息的情况下, Work Queue 会将消息分派给不同的消费者, 每个消费者都会接收到不同的消息
·特点: 消息不会重复, 分配给不同的消费者.
·适用场景: 集群环境中做异步处理
·比如12306 短信通知服务, 订票成功后, 订单消息会发送到 RabbitMQ, 短信服务从RabbitMQ中获取订单信息, 并发送通知信息(在短信服务之间进行任务分配)



以上两种工作模式若没有交换机，在 RabbitMQ 中是不成立的
但是在 RabbitMQ 中，消费者一定会把消息 先发送给交换机的

三、Publish/Subscribe (发布/订阅)

图中X表示交换机, 在订阅模型中，多了⼀个Exchange角色, 过程略有变化

概念介绍
Exchange: 交换机 (X)

作用: 生产者将消息发送到 Exchange, 由交换机将消息按⼀定规则 路由 到⼀个或多个队列中(上图中生产者将消息投递到队列中, 实际上这个在 RabbitMQ中不会发生. )
RabbitMQ交换机有四种类型: fanout,direct, topic, headers, 不同类型有着不同的路由策略.
AMQP协议⾥还有另外两种类型, 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

当消息的 Routing key 与队列绑定的 Bindingkey 相匹配时，消息才会被路由到这个队列.
BindingKey 其实也属于路由键中的⼀种, 官方解释为:the routingkey to use for the binding.
可以翻译为:在绑定的时候使用的路由键. 大多数时候,包括官方文档和 RabbitMQJava API 中都把
BindingKey 和 RoutingKey 看作 RoutingKey , 为了避免混淆,可以这么理解:

1.在使用绑定的时候,需要的路由键是 BindingKey.
2.在发送消息的时候,需要的路由键是 RoutingKey. 后续也可能把两者合称为Routing Key, 大家根据使用场景来区分
·⼀个生产者P, 多个消费者C1, C2, X代表交换机消息复制多份，每个消费者接收相同的消息
·生产者发送⼀条消息，经过交换机转发到多个不同的队列，多个不同的队列就有多个不同的消费者
·适合场景: 消息需要被多个消费者同时接收的场景.如: 实时通知或者广播消息
比如中国气象局发布"天气预报"的消息送⼊交换机, 新浪,百度, 搜狐, 网易等门户网站接⼊消息, 通过队列绑定到该交换机, 自动获取气象局推送的气象数据

四、Routing (路由模式)

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

比如系统打印日志, 日志等级分为error, warning, info,debug, 就可以通过这种模式,把不同的日志发
送到不同的队列, 最终输出到不同的文件

五、Topics (通配符模式)

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

六、RPC (RPC通信)

·在RPC通信的过程中, 没有生产者和消费者, 比较像咱们RPC远程调用, 大概就是通过两个队列实现了⼀个可回调的过程



1。客户端发送消息到⼀个指定的队列, 并在消息属性中设置 replyTo 字段, 这个字段指定了⼀个回调队列, 用于接收服务端的响应.
2.服务端接收到请求后, 处理请求并发送响应消息到 replyTo 指定的回调队列
3。客户端在回调队列上等待响应消息. ⼀旦收到响应，客户端会检查消息的 correlationId 属性，以确保它是所期望的响应.

七、Publisher Confirms (发布确认)

Publisher Confirms模式是RabbitMQ提供的⼀种确保消息可靠发送到RabbitMQ服务器的机制。在这
种模式下，生产者可以等待RabbitMQ服务器的确认，以确保消息已经被服务器接收并处理.

1.生产者将 Channel 设置为 confirm 模式(通过调用 channel.confirmSelect()完成)后, 发布的每⼀条消息都会获得⼀个唯⼀的ID, ⽣产者可以将这些序列号与消息关联起来，以便跟踪消息的状态.
2.当消息被RabbitMQ服务器接收并处理后，服务器会异步地向生产者发送⼀个确认(ACK)给生产者
(包含消息的唯⼀ID)，表明消息已经送达.
通过Publisher Confirms模式，生产者可以确保消息被RabbitMQ服务器成功接收, 从而避免消息丢失
的问题.
适用场景: 对数据安全性要求较高的场景. 比如金融交易, 订单处理