RabbitMQ是采用Erlang语言实现AMQP（Advanced Message Queuing Protocol,高级消息队列协议）的消息中间件。
RabbitMQ架构模型
# Producer：生产者
就是投递消息的一方，生产者创建消息发布到RabbitMQ中。
消息包含2部分：
消息体（payload）：
一般是一个带有业务逻辑结构的数据，比如一个JSON字符串。
标签(Label)
用来描述这条消息，比如一个交换器的名称和一个路由键。
生产者把消息交由RabbitMQ，RabbitMQ之后会根据标签吧消息发送给感兴趣的消费者
# Consumer：消费方
就是接受消息一方
消费者连接到RabbitMQ服务器，并订阅到队列上。当消费者消费一条消息时，只是消费消息的消息体（payload）。在消息路由的过程中，消息的标签会丢弃，存入到队列中的消息只有消息体，消费者也只会消费到消息体。
消息如果只是存储在队列里是没有任何用处的。被应用消费掉，消息的价值才能够体现。在 AMQP 0-9-1 模型中，有两种途径可以达到此目的：
- 将消息投递给应用 (“push API”)
- 应用根据需要主动获取消息 (“pull API”)
# Broker：服务节点
可以将一个RabbitMQ Broker看作一台RabbitMQ服务器。
# Queue队列：
用于存储消息
队列属性
队列跟交换机共享某些属性，但是队列也有一些另外的属性。
- Name
- Durable（消息代理重启后，队列依旧存在）
- Exclusive（只被一个连接（connection）使用，而且当连接关闭后队列即被删除）
- Auto-delete（当最后一个消费者退订后即被删除）
- Arguments（一些消息代理用他来完成类似与 TTL 的某些额外功能）
队列创建
队列在声明（declare）后才能被使用。
如果一个队列尚不存在，声明一个队列会创建它。
如果声明的队列已经存在，并且属性完全相同，那么此次声明不会对原有队列产生任何影响。
如果声明中的属性与已存在队列的属性有差异，那么一个错误代码为 406 的通道级异常就会被抛出。
队列持久化
持久化队列（Durable queues）会被存储在磁盘上，当消息代理（broker）重启的时候，它依旧存在。没有被持久化的队列称作暂存队列（Transient queues）。并不是所有的场景和案例都需要将队列持久化。
持久化的队列并不会使得路由到它的消息也具有持久性。倘若消息代理挂掉了，重新启动，那么在重启的过程中持久化队列会被重新声明，无论怎样，只有经过持久化的消息才能被重新恢复。
# Exchange：交换器
生产者将消息发送到Exchange，由交换器将消息路由到一个或者多个队列中，如果路由不到，或许返回给生产者，或许直接丢弃。
交换机有两种状态：
持久（durable）：
持久化的交换机会在消息代理（broker）重启后依旧存在，而暂存的交换机则不会（它们需要在代理再次上线后重新被声明）。
并不是所有的应用场景都需要持久化的交换机。
暂存（transient）
类型：
–fanout广播
将所有发送到交换器的消息路由到所有与该交换器绑定对的队列中【扇形交换机，不再判断routeKey，直接将消息分发到所有绑定的队列】。
–direct直连
把消息路由到哪些BindKey和RoutingKey完全匹配的队列中。【判断touteKey的规则是完全 匹配模式，即发送消息时指定的routeKey要等于绑定的routeKey】。
–topic主题
主题交换机（topic exchanges）通过对消息的路由键和队列到交换机的绑定模式之间的匹配，将消息路由给一个或多个队列。主题交换机经常用来实现各种分发/订阅模式及其变种。主题交换机通常用来实现消息的多播路由（multicast routing）【判断routeKey的规则是模糊匹配方式】
RoutingKey为一个点号“.”分割的字符串（被点号“.”分隔开的每一段独立的字符串称为一个单词）
BindingKey中可以存在两种特殊的字符串“*”和“#”，用于做模糊匹配，
匹配0个或者多个单词
- 匹配一个单词
–headers头交换机
（不依赖与路由键的匹配规则，基本不用了）
绑定队列与交换器的时候指定一个键值对，当交换器在分发消息的时候会先解开消息体里的headers 数据，然后判断里面是否有所设置的键值对，如果发现匹配成功，才将消息分发到队列中;这种交换器类型在性能上相对来说较差，在实际工作中很少会用到
# RoutingKey：路由键
生产者将消息发送给交换器的时候，一般会指定一个RoutingKey，用来指定消息的路由规则，而这个RoutingKey需要与交换器类型和绑定键（BindingKey）联合使用才能最终生效。
在交换器类型和绑定键(BindingKey）固定的情况下，生产者可以发送消息给交换器时，通过指定RoutingKey来决定消息流向哪里。
# BindingKey：绑定
RabbitMQ通过绑定将交换器与队列关联起来，在绑定的时候一般会指定一个绑定键（BindingKey），这样RabbitMQ就知道如何正确的将消息路由到队列了。
# Connection:连接
:Connection 和Channel 。我们知道无论是生产者还是消费者，都需要和RabbitMQ Broker 建立连接，这个连接就是一条TCP 连接，也就是Connection 。
# Channel：信道
一旦TCP 连接建立起来，客户端紧接着可以创建一个AMQP 信道(Channel) ，每个信道都会被指派一个唯一的ID 。信道是建立在Connection 之上的虚拟连接， RabbitMQ 处理的每条AMQP 指令都是通过信道完成的。
我们完全可以直接使用Connection 就能完成信道的工作，为什么还要引入信道呢?
一个应用程序中有很多个线程需要从RabbitMQ 中消费消息，或者生产消息，那么必然需要建立很多个Connection ，也就是许多个TCP 连接。然而对于操作系统而言，建立和销毁TCP 连接是非常昂贵的开销，如果遇到使用高峰，性能瓶颈也随之显现。RabbitMQ 采用类似NIO’ (Non-blocking 1/0) 的做法，选择TCP 连接复用，不仅可以减少性能开销，同时也便于管理。
每个线程把持一个信道，所以信道复用了Connection 的TCP 连接。同时RabbitMQ 可以确保每个线程的私密性，就像拥有独立的连接一样。当每个信道的流量不是很大时，复用单一的Connection 可以在产生性能瓶颈的情况下有效地节省TCP 连接资源。但是当信道本身的流量很大时，这时候多个信道复用一个Connection 就会产生性能瓶颈，进而使整体的流量被限制了。此时就需要开辟多个Connection ，将这些信道均摊到这些Connection 中， 至于这些相关的调优策略需要根据业务自身的实际情况进行调节。
信道在AMQP 中是一个很重要的概念，大多数操作都是在信道这个层面展开的。在代码清单中也可以看出一些端倪，
比如channel.exchangeDeclare 、channel .queueDeclare 、channel.basicPublish 和channel.basicConsume 等方法。
RabbitMQ 相关的API 与AMQP紧密相连，比如channel.basicPublish 对应AMQP 的Basic.Publish 命令.
# vhosts：虚拟主机
为了在一个单独的代理上实现多个隔离的环境（用户、用户组、交换机、队列 等），AMQP 提供了一个虚拟主机（virtual hosts - vhosts）的概念。这跟 Web servers 虚拟主机概念非常相似，这为 AMQP 实体提供了完全隔离的环境。当连接被建立的时候，AMQP 客户端来指定使用哪个虚拟主机。
# RabbitMQ运转流程
生产者发送消息的时候
(1) 生产者连接到RabbitMQ Broker ， 建立一个连接( Connection) ，开启一个信道(Channel)
(2) 生产者声明一个交换器，并设置相关属性，比如交换机类型、是否持久化等
(3) 生产者声明一个队列井设置相关属性，比如是否排他、是否持久化、是否自动删除等
(4) 生产者通过路由键将交换器和队列绑定起来
(5) 生产者发送消息至RabbitMQ Broker，其中包含路由键、交换器等信息
(6) 相应的交换器根据接收到的路由键查找相匹配的队列。
(7) 如果找到，则将从生产者发送过来的消息存入相应的队列中。
(8) 如果没有找到，则根据生产者配置的属性选择丢弃还是回退给生产者
(9) 关闭信道。
(10) 关闭连接。
消费者接收消息的过程:
(1) 消费者连接到RabbitMQ Broker ，建立一个连接(Connection ) ，开启一个信道(Channel) 。
(2) 消费者向RabbitMQ Broker 请求消费相应队列中的消息，可能会设置相应的回调函数，
以及做一些准备工作
(3) 等待RabbitMQ Broker 回应并投递相应队列中的消息， 消费者接收消息。
(4) 消费者确认( ack) 接收到的消息。
(5) RabbitMQ 从队列中删除相应己经被确认的消息。
(6) 关闭信道。
(7) 关闭连接
# AMQP协议
RabbitMQ是采用Erlang语言实现AMQP（Advanced Message Queuing Protocol,高级消息队列协议）的消息中间件。
AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
AMQP 说到底还是一个通信协议，通信协议都会涉及报文交互，从low-level 举例来说，AMQP 本身是应用层的协议，其填充于TCP 协议层的数据部分。而从high-level 来说， AMQP是通过协议命令进行交互的。AMQP 协议可以看作一系列结构化命令的集合，这里的命令代表一种操作，类似于HTTP 中的方法(GET 、POST 、PUT 、DELETE 等)
# 消息机制
消息确认
消费者应用（Consumer applications） - 用来接受和处理消息的应用 - 在处理消息的时候偶尔会失败或者有时会直接崩溃掉。而且网络原因也有可能引起各种问题。这就给我们出了个难题，AMQP 代理在什么时候删除消息才是正确的？AMQP 0-9-1 规范给我们两种建议：
自动确认模式：当消息代理（broker）将消息发送给应用后立即删除。（使用 AMQP 方法：basic.deliver 或 basic.get-ok）)
显式确认模式：待应用（application）发送一个确认回执（acknowledgement）后再删除消息。（使用 AMQP 方法：basic.ack）
如果一个消费者在尚未发送确认回执的情况下挂掉了，那 AMQP 代理会将消息重新投递给另一个消费者。如果当时没有可用的消费者了，消息代理会死等下一个注册到此队列的消费者，然后再次尝试投递。
拒绝消息
当一个消费者接收到某条消息后，处理过程有可能成功，有可能失败。应用可以向消息代理表明，本条消息由于 “拒绝消息（Rejecting Messages）” 的原因处理失败了（或者未能在此时完成）。
当拒绝某条消息时，应用可以告诉消息代理如何处理这条消息——销毁它或者重新放入队列。
当此队列只有一个消费者时，请确认不要由于拒绝消息并且选择了重新放入队列的行为而引起消息在同一个消费者身上无限循环的情况发生。
在 AMQP 中，basic.reject 方法用来执行拒绝消息的操作。但 basic.reject 有个限制：你不能使用它决绝多个带有确认回执（acknowledgements）的消息。但是如果你使用的是 RabbitMQ，那么你可以使用被称作 negative acknowledgements（也叫 nacks）的 AMQP 0-9-1 扩展来解决这个问题。
预取消息
在多个消费者共享一个队列的案例中，明确指定在收到下一个确认回执前每个消费者一次可以接受多少条消息是非常有用的。这可以在试图批量发布消息的时候起到简单的负载均衡和提高消息吞吐量的作用。For example, if a producing application sends messages every minute because of the nature of the work it is doing.（例如，如果生产应用每分钟才发送一条消息，这说明处理工作尚在运行。）
注意，RabbitMQ 只支持通道级的预取计数，而不是连接级的或者基于大小的预取。
消息属性
AMQP 模型中的消息（Message）对象是带有属性（Attributes）的。有些属性及其常见，以至于 AMQP 0-9-1 明确的定义了它们，并且应用开发者们无需费心思思考这些属性名字所代表的具体含义。例如：
- Content type（内容类型）
- Content encoding（内容编码）
- Routing key（路由键）
- Delivery mode (persistent or not)
- 投递模式（持久化 或 非持久化）
- Message priority（消息优先权）
- Message publishing timestamp（消息发布的时间戳）
- Expiration period（消息有效期）
- Publisher application id（发布应用的 ID）
有些属性是被 AMQP 代理所使用的，但是大多数是开放给接收它们的应用解释器用的。有些属性是可选的也被称作消息头（headers）。他们跟 HTTP 协议的 X-Headers 很相似。消息属性需要在消息被发布的时候定义。
消息主体
AMQP 的消息除属性外，也含有一个有效载荷 - Payload（消息实际携带的数据），它被 AMQP 代理当作不透明的字节数组来对待。
消息代理不会检查或者修改有效载荷。消息可以只包含属性而不携带有效载荷。它通常会使用类似 JSON 这种序列化的格式数据，为了节省，协议缓冲器和 MessagePack 将结构化数据序列化，以便以消息的有效载荷的形式发布。AMQP 及其同行者们通常使用 “content-type” 和 “content-encoding” 这两个字段来与消息沟通进行有效载荷的辨识工作，但这仅仅是基于约定而已。
消息持久化
消息能够以持久化的方式发布，AMQP 代理会将此消息存储在磁盘上。如果服务器重启，系统会确认收到的持久化消息未丢失。
简单地将消息发送给一个持久化的交换机或者路由给一个持久化的队列，并不会使得此消息具有持久化性质：它完全取决与消息本身的持久模式（persistence mode）。将消息以持久化方式发布时，会对性能造成一定的影响（就像数据库操作一样，健壮性的存在必定造成一些性能牺牲）。