一，MQ作用
1，异步
2，解耦
3，削峰填谷：比如MQ现在消费消息速度为1000，当高峰期并发量突发到1000以上，将多出的请求保存在MQ中，在低峰期处理。
二，AMQP
RabbitMQ 是基于 AMQP 协议，用 Erlang 语言实现。
AMQP 是一个网络协议，它支持符合要求的客户端应用和消息中间件代理之间进行通信。
三，AMQP 0-9-1 模型简介
AMQP 0-9-1的工作过程如下图：消息（message）被发布者（publisher）发送给交换机（exchange），交换机常常被比喻成邮局或者邮箱。然后交换机将收到的消息根据路由规则（routing）分发给绑定的队列（queue）。最后AMQP代理会将消息推送给订阅了此队列的消费者，或者消费者按照需求自行拉取。
从安全角度考虑，网络是不可靠的，接收消息的应用也有可能在处理消息的时候失败。基于此原因，AMQP 模块包含了一个消息确认的概念：
当一个消息从队列中投递给消费者后，消费者默认会主动通知 broker，消息从 broker 中删除。当启用手动确认，消息者端须手动向 broker 确认消息，消息才会被从 broker 中删除。
在某些情况下，例如当一个消息无法被成功路由时，消息或许会被返回给发布者并被丢弃。或者，如果消息代理执行了延期操作，消息会被放入一个所谓的死信队列中。此时，消息发布者可以选择某些参数来处理这些特殊情况。
队列，交换机和绑定统称为AMQP实体。
四，交换机和交换机类型
交换机是用来发送消息的AMQP实体。
交换机拿到一个消息之后将它路由给一个或零个队列。它使用哪种路由算法是由交换机类型和被称作绑定的规则所决定的。
AMQP 0-9-1的代理提供了四种交换机：
交换机可以有持久和暂存两个状态。持久化的交换机会在消息代理（broker）重启后依旧存在，而暂存的交换机则不会。
五，队列
AMQP中的队列用来存储即将被应用消费的消息。
队列持久化
持久化队列（Durable queues）会被存储在磁盘上，当消息代理（broker）重启的时候，它依旧存在。没有被持久化的队列称作暂存队列。
持久化的队列并不会使得路由到它的消息也具有持久性。倘若消息代理挂掉了，重新启动，那么在重启的过程中持久化队列会被重新声明，无论怎样，只有经过持久化的消息才能被重新恢复。
六，绑定
绑定（Binding）是交换机（exchange）将消息路由（routing）给队列所需遵循的规则。
绑定操作需要定义一个可选的路由键（routing key）属性给某些类型的交换机。路由键的意义在于从发送给交换机的众多消息中选择出某些消息，将其路由给绑定的队列。
七，消息确认
消费者应用用来接受和处理消息的应用，在处理消息的时候偶尔会失败或者有时会直接崩溃掉，而且网络原因也有可能引起各种问题，那么AMQP代理在什么时候删除消息才是正确的 。
AMQP 0-9-1 规范给我们两种建议：当消息代理（broker）将消息发送给应用后立即删除或手动 ack 确认后再删除。
前者被称作自动确认模式，后者被称作显式确认模式。在显式模式下，由消费者应用来选择什么时候发送确认回执。如果一个消费者在尚未发送确认回执的情况下挂掉了，那AMQP代理会将消息重新投递给另一个消费者。如果当时没有可用的消费者了，消息代理会死等下一个注册到此队列的消费者，然后再次尝试投递。
7.1，手动确认和自动恢复
当使用手动确认的情况下，可能会发生连接在消息投递成功但并未进行确认的空挡中失效的情况。在连接恢复后，RabbitMQ 会在通道里重置投递标签。
这意味着旧的投递标签的 basic.ack, basic.nack, 和 basic.reject 会导致通道异常发生。为了避免这种情况，RabbitMQ 的 Java 客户端会保持对投递标签的追踪和更新，以使它们在恢复过程中单调增长。
之后，Channel.basicAck, Channel.basicNack, 和 Channel.basicReject 会将调整后的传递标签转换为RabbitMQ 使用的传递标签。
带有过时的投递标签的确认将不会发送。使用手动确认和自动恢复的应用必须能够对重新投递的消息进行处理。
八，连接
AMQP 连接通常是长连接。AMQP 是一个使用 TCP 提供可靠投递的应用层协议。AMQP 使用认证机制并且提供TLS（SSL）保护。当一个应用不再需要连接到 AMQP 代理的时候，需要优雅的释放掉 AMQP 连接，而不是直接将TCP连接关闭。
九，RabbitMQ工作模式
Work queues工作队列模式
多个消费端共同消费同一个队列中的消息。采用的是默认的交换机和默认的路由键。
应用场景：对于 任务过重或任务较多情况使用工作队列可以提高任务处理的速度。
订阅模式
P: 消息生产者
C: 消费者
红色部分: 消息队列
X: 交换机Exchange(Fanout): 只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！
Exchange有常见以下3种类型：
①Fanout: 广播：将消息交给所有绑定到交换机的队列；
②Direct：定向：把消息交给符合指定routing key的队列；
③Topic：通配符：把消息交给符合routing pattern（路由模式）的队列。
Exchange 为 fanout 时，生产者往此 Exchange 发送的消息会发给每个和其绑定的Queue，此时RoutingKey 并不起作用；
Exchange 为 topic 时，生产者可以指定一个支持通配符的 RoutingKey（如demo.*）发向此 Exchange，凡是 Exchange 上 RoutingKey 满足此通配符的 Queue 就会收到消息；
direct 类型的 Exchange 是最直接最简单的，生产者指定 Exchange 和 RoutingKey，然后往其发送消息，消息只能被绑定的满足 RoutingKey 的 Queue 接受消息。(通常如果不指定 RoutingKey 的具体名字，那么默认的名字其实是 Queue 的名字）
Publish/Subscribe发布与订阅模式
特点：
1，每个消费者监听自己的队列。
2，生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队列都将接收到消息。
Routing路由模式
特点：
1，队列与交换机的绑定，不能是任意绑定了，而是要指定一个RoutingKey；
2，消息的发送方在 向 Exchange发送消息时，也必须指定消息的 RoutingKey。
3，Exchange 根据消息的 RoutingKey 进行判断，只有队列的 Routingkey 与消息的 Routing key 完全一致，才会接收到消息
TOPIC通配符模式
Topic主题模式可以实现 Publish/Subscribe发布与订阅模式 和 Routing路由模式 的功能；只是Topic在配置routing key 的时候可以使用通配符，显得更加灵活。
下面我们用一副简单的思维导图把上面的概念组织起来:
文章参考
RabbitMQ中文文档
Consumer Acknowledgements and Publisher Confirms
评论区