AMQP
AMQP协议是一个高级抽象层消息通信协议，RabbitMQ是AMQP协议的实现。
1.Server(broker): 接受客户端连接，实现AMQP消息队列和路由功能的进程。
2.Virtual Host:其实是一个虚拟概念，类似于权限控制组，一个Virtual Host里面可以有若干个Exchange和Queue，但是权限控制的最小粒度是Virtual Host
3.Exchange:接受生产者发送的消息，并根据Binding规则将消息路由给服务器中的队列。ExchangeType决定了Exchange路由消息的行为，例如，在RabbitMQ中，ExchangeType有direct、Fanout和Topic三种，不同类型的Exchange路由的行为是不一样的。
4.Message Queue：消息队列，用于存储还未被消费者消费的消息。
5.Message: 由Header和Body组成，Header是由生产者添加的各种属性的集合，包括Message是否被持久化、由哪个Message Queue接受、优先级是多少等。而Body是真正需要传输的APP数据。
6.Binding:Binding联系了Exchange与Message Queue。Exchange在与多个Message Queue发生Binding后会生成一张路由表，路由表中存储着Message Queue所需消息的限制条件即Binding Key。当Exchange收到Message时会解析其Header得到Routing Key，Exchange根据Routing Key与Exchange Type将Message路由到Message Queue。Binding Key由Consumer在Binding Exchange与Message Queue时指定，而Routing Key由Producer发送Message时指定，两者的匹配方式由Exchange Type决定。
7.Connection:连接，对于RabbitMQ而言，其实就是一个位于客户端和Broker之间的TCP连接。
8.Channel:信道，仅仅创建了客户端到Broker之间的连接后，客户端还是不能发送消息的。需要为每一个Connection创建Channel，AMQP协议规定只有通过Channel才能执行AMQP的命令。一个Connection可以包含多个Channel。之所以需要Channel，是因为TCP连接的建立和释放都是十分昂贵的，如果一个客户端每一个线程都需要与Broker交互，如果每一个线程都建立一个TCP连接，暂且不考虑TCP连接是否浪费，就算操作系统也无法承受每秒建立如此多的TCP连接。RabbitMQ建议客户端线程之间不要共用Channel，至少要保证共用Channel的线程发送消息必须是串行的，但是建议尽量共用Connection。
9.Command:AMQP的命令，客户端通过Command完成与AMQP服务器的交互来实现自身的逻辑。例如在RabbitMQ中，客户端可以通过publish命令发送消息，txSelect开启一个事务，txCommit提交一个事务。
new Exchange 参数
durability：
durable/transient 是否持久化：是否在重启或者宕机后还保存
auto_delete: 当所有绑定队列都不再使用时，是否自动删除该交换机。
Internal YES表示这个exchange不可以被client用来推送消息，仅用来进行exchange和exchange之间的绑定。
new queue 参数
message TTL 消息过期时间
Auto-delete:自动删除，如果该队列没有任何订阅的消费者的话，该队列会被自动删除。这种队列适用于临时队列。
max length 消息队列最大长度
max length byte 消息body最大大小
overflow behavior 消息队列满策略：死信/拒绝
dead letter exchange 死信exchange
dead letter routing key 死信routingkey
maximum prority 最大优先级，不填的话默认不开启优先级
lazy mode 在lazy mode下使用磁盘空间而不是内存空间
master locator
四种Exchange
Exchange的类型主要有四种，分别是
1. Direct Exchange：
将消息中的Routing key与该Exchange关联的所有Binding中的Routing key进行比较，如果相等，则发送到该Binding对应的Queue中。
2. Topic Exchange：
将消息中的Routing key与该Exchange关联的所有Binding中的Routing key进行对比，如果匹配上了，则发送到该Binding对应的Queue中。
binding key 中 符号“#”匹配一个或多个词，符号“*”匹配不多不少一个词
3. Fanout Exchange：
直接将消息转发到所有binding的对应queue中，这种exchange在路由转发的时候，忽略Routing key。
4. Headers （已废弃）
Headers Exchange：将消息中的headers与该Exchange相关联的所有Binging中的参数进行匹配，如果匹配上了，则发送到该Binding对应的Queue中。
五种队列使用场景
1. 简单队列
一个生产者，一个消费者，一个队列
2. 工作队列模式Work Queue
一个发送端，多个接收端，如分布式的任务派发。为了保证消息发送的可靠性，不丢失消息，使消息持久化了。同时为了防止接收端在处理消息时down掉，只有在消息处理完成后才发送ack消息。
3. 发布/订阅模式
一个生产者，多个队列，发送端发送广播消息，多个接收端接收。
4.路由模式
生产者将消息发送到direct交换器，在绑定队列和交换器的时候有一个路由key，生产者发送的消息会指定一个路由key，那么消息只会发送到相应key相同的队列，接着监听该队列的消费者消费消息。
5. 主题(Topic)模式
发送端不只按固定的routing key发送消息，而是按字符串“匹配”发送，接收端同样如此。