RabbitMQ特点

RabbitMQ是部署最广泛的消息代理，也是AMQP（Advanced Message Queuing Protocol，高级消息队列协议）的标准实现；它有一下特点：

支持多种消息传递协议，消息队列，传递确认机制，灵活的路由消息到队列，多种交换类型
可在许多操作系统及云环境中运行，并为大多数流行语言提供各种开发工具
可插拔身份认证授权，支持TLS（Transport Layer Security，安全传输层协议）和LDAP（Lightweight Directory Access Protocol，轻量目录访问协议）。轻量且容易部署到内部、私有云或公有云中。
也可以部署在分布式和联合配置中，以满足高规模、高可用性的要求
有专门的用于管理和监督的http-API、命令行工具和UI

RabbitMQ结构

RabbitMQ基础知识简介

vhost虚拟主机

一个broker里可以开设多个虚拟主机；类似于许多流行web服务器使用的“虚拟主机”，并且提供AMQP实体所在的完全隔离的环境（用户组，exchange，queue等）。AMQP客户端指定在AMQP连接协商期间要使用的虚拟主机。

channel 消息通道

在客户端的每个连接里，可以建立多个channel，每个channel代表一个会话任务。（定义exchange, 定义queue，绑定队列和exchange，publishMessage...都是在channel中完成的）

AMQP（使用TCP进行可靠传递）Connection（连接）通常是长期存在的，AMQP连接使用身份验证，可以用TLS、SSL进行保护。当应用程序不需要连接到AMQP代理的时，应关闭AMQP连接，而不是突然关闭底层TCP连接。

如果直接在TCP基础上进行数据流动，频繁的建立关闭TCP连接会消耗很多系统资源并使配置防火墙变得更加困难，而且TCP连接数量有限额。所以AMQP在TCP连接的基础上建立了channel（通道，特定通道和另一个通道上的通信完全分开，所以每个AMQP方法还带有一个通道号，客户端通过该通道号确定该方法针对的通道）。

exchange消息交换机

exchange是发送消息的AMQP实体。它接收消息（生产者-->交换机时产生RoutingKey）并将其按照自己的交换类型和某种规则（Binding；在绑定queue和Exchange的时候产生BindingKey；当RoutingKey与BindingKey相同时就会发送到相应队列中）路由到0个或多个队列。

交换机的类型

Direct exchange	(Empty string) and amq.direct (RoutingKey === BindingKey)
Fanout exchange	amq.fanout （路由到所有绑到该exchange的queue）
Topic exchange	amq.topic （BindingKey与RoutingKey匹配）
Headers exchange	amq.match (and amq.headers in RabbitMQ) （不依赖BindingKey和RoutingKey，根据Headers属性，headers中属性的值等于绑定时指定的值，则消息匹配）

交换机的几个重要属性

Name
Durability：交换机可以是持久化的也可以是瞬时的。当broker重启时持久化的exchange仍旧存在，而瞬时的exchange则只能在broker上线后重新提交声明。
Auto-delete：当没有一个队列绑定到该交换机时，则删除该交换机。
Arguments：（可选，根据插件和特定于代理的功能使用）

注： default exchange是broker 预先声明的没有名字（空string）的直接交换机。它有一个特殊的属性，这对简单的应用程序非常有用：创建的每个队列都使用和队列名相同的BindingKey来绑定到该exchange上。（所以default exchange看起来好像能直接把消息发给队列一样，即使技术上根本不是看起来的那样）

Queue队列

Name
Durable：持久化（持久化到磁盘）后，当代理重启后该队列依旧存在。队列的持久性不会使路由到该队列的消息持久。如果代理被删除然后重新启动，则在代理启动期间将重新声明持久队列，但是，只会恢复持久性消息。
Excusive ：仅由一个连接使用，当该连接关闭时就删除队列。
Auto-delete ：当没有消费者订阅时，删除队列。
Arguments ：（可选，由插件和特定于代理的功能使用，例如消息TTL，队列长度限制等）

RabbitMQ消息持久化

RabbitMQ消息持久化，即数据写到磁盘上。需要exchange，queue，消息（投递时指定delivery_mode）都持久化。如果exchange和queue都是持久化的，那么它们之间的binding也是持久化的。如果exchange和queue两者之间有一个持久化，一个非持久化，就不允许建立绑定。