简单模式
生产者，一个队列一个或多个消费者，当多个消费者同时监听一个队列时，他们并不能同时消费一条消息，而是随机消费消息，即一个队列中一条消息，只能被一个消费者消费。

订阅与发布模式(fanout)
生产者，一个交换机(fanoutExchange)，没有路由规则，多个队列，多个消费者。生产者将消息不是直接发送到队列，而是发送到X交换机，然后由交换机发送给两个队列，两个消费者各自监听一个队列，来消费消息。

路由模式(direct)
生产者，一个交换机(directExchange)，路由规则，多个队列，多个消费者。主要根据定义的路由规则决定消息往哪个队列发送。

主题模式(topic)
生产者，一个交换机(topicExchange)，模糊匹配路由规则，多个队列，多个消费者。

                                                                订阅模式-headers
不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。 在绑定Queue与Exchange时指定一组键值对；当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对；如果完全匹配则消息会路由到该Queue，否则不会路由到该Queue。

RPC模式

MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。 但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行。 

对于RPC请求，客户端发送一条带有两个属性的消息：replyTo,设置为仅为请求创建的匿名独占队列，和correlationId,设置为每个请求的唯一id值。

请求被发送到rpc_queue队列。

RPC工作进程(即：服务器)在队列上等待请求。当一个请求出现时，它执行任务，并使用replyTo字段中的队列将结果发回客户机。

客户机在回应消息队列上等待数据。当消息出现时，它检查correlationId属性。如果匹配请求中的值，则向程序返回该响应数据。

总结

订阅模式，路由模式，主题模式，他们的相同点就是都使用了交换机，只不过在发送消息给队列时，添加了不同的路由规则。

订阅模式没有路由规则，路由模式为完全匹配规则，主题模式为模糊匹配（正则表达式，完全匹配规则）。

在交换机模式下：队列和路由规则有很大关系，生产者只用关心交换机与路由规则即可，无需关心队列。

消费者不管在什么模式下：永远不用关心交换机和路由规则，消费者永远只关心队列，消费者直接和队列交互。

RabbitMQ的常见队列模型，simple模式、work模式、fanout模式、direct模式、topic模式、headers模式、RPC_毅大师的博客-CSDN博客_headers模式

消息队列的高级用法： QUEUE：

1. 消息的持久化

2 在消费者端做限流

3 Ack和Nack 和Reject的区别

在服务器端的客户端页面从队列中获取消息是一个危险的动作，生产环境一定要了解业务之后再做操

Act Mode

• Nack message requeue true

        获取消息，但是不做ack应答确认，消息重新入队【队列是先进先出，拿到了消息这个消息就出队列了，现在这句话就是拿到了消息，然后又重新将消息给丢到队列里面去，其他人还可以获取到】

• Ack message requeue false

        获取消息，应答确认，消息不重新入队，将会从队列中删除

• reject requeue true

        拒绝获取消息，消息重新入队

• reject requeue false

        拒绝获取消息，消息不重新入队，将会被删除

Encoding
        AMQP消息负载可以包含任何的二进制内容，因此他们很难再浏览器中展示，编码的选         项含义有如下内容：string/base64,如果消息负载可以使用UTF-8字符串编码，就执行此 操作，否则就按照base64编码进行返回。

Messages
        定义一次从队列中获取的消息数量

• type：此queue的类型，默认为classic 主队列，也可以设置为quorum 从队列
• name：此queue的名称
• durability：queue中的消息是否要持久化到硬盘
• auto delete：如果此queue没有绑定到任何一个exchange，是否自动删除此queue
• arguments：设置一些其它参数
• exchange、queue的消息持久化能力，保证了rabbitmq的高可靠性。

https://www.cnblogs.com/1024llh/articles/15918851.html

消息确认可以让RabbitMQ知道消费者已经接受并处理完消息。但是如果消息本身或者消息的处理过程出现问题怎么办？需要一种机制，通知RabbitMQ，这个消息，我无法处理，请让别的消费者处理。这里就有两种机制，Reject和Nack。

1）Ack对于明确要消费的消息。可以通过Ack的方式告知mq，mq就会发送下一条消息给消费者

2）Nack 告知mq，这样的消息我不处理，丢弃掉，此时消息会成为死信。

3）Reject

reject与nack的用法相同，但是与nack只有一个区别，nack一次可以拒签多条消息（multiple:true）,但是reject一次只能拒签一条消息。

4 死信队列

DLX（死信队列）

• DLX定义 DLX为Dead Letter Exchange，死信队列。当一个消息在一个队列中变成死信（dead message）之后，它能重新publish到另一个Exchange，那么这个让消息变为死信的Exchange就是DLX（死信队列）。
• 消息变成死信的几种情况 1、消息被拒绝，ack为false，并且 requeue=false; 2、消息TTL(Time To Live)过期，指消息达到了过期时间； 3、队列达到最大长度。

如果设置了死信队列，当一个普通队列中的消息成为了死信之后，于是这样的消息就会自动被publish到死信队列中。

消息什么情况下会成为死信？

1）消息被拒签，并且不会重回队列

2）消息过期了

3）超出了队列的长度，装不下的消息将会成为死信。

通过消息的过期成为死信的机制，死信队列很容易就能做出一个延迟队列的效果。

死信队列很容易就做出一个延迟队列的效果