一. AMQP协议
1.概述
AMQP: Advanced Message Queuing Protocol
是一个提供统一消息服务的应用层标准高级消息队列协议,一种应用层协议的开放标准，面向消息，支持不同语言和不同的产品
2. 角色
a）生产者
消息的创建者，发送到amqp的消息中间件
b) 消费者
连接到amqp的消息中间件，订阅到队列上，进行消息的消费。分为持续订阅（basicConsumer）和单条订阅(basicGet)
c) 消息
包括有效载荷和标签。有效载荷就是要传输的数据。标签描述有效载荷的属性（rabbitmq用标签来决定谁获得当前消息。消费者只能拿到有效载荷）
d) 信道
虚拟的连接，建立在真实的tcp连接之上的。信道的创建没有限制的。
e) 交换器/队列/绑定/路由键
1). 队列通过路由键（routing key，某种确定的规则）绑定到交换器，生产者把消息发送到了交换器，交换器根据绑定的路由键将消息路由到特定的队列，订阅了队列的消费者进行接收。
i.如果消息到达了无人订阅的队列，消息会无限制的一直等待。
ii.RabbitMQ中的队列默认为无限长度。
iii.多个消费者订阅到同一个队列，消息会以轮询的方式发出，且每个消息只会发送给一个消费者。
iv.消息路由到了不存在的队列，会舍弃这条消息，消息会丢失。
2).消息的确认机制
消费者收到的每一条消息都必须进行确认。
i.自动确认：
消费者在声明队列时，指定autoAck参数，true。
ii.自行确认：
消费者在声明队列时，指定autoAck参数，false。
自行确认模式下，rabbitmq会等到消费者显示的发回一个ack信号才会删除消息。有足够时间让消费者处理消息，直到消费者显示调用basicAck为止。
3).RabbitMq中消息分为两种状态：
i.等待投递的消息
ii.已经投递，但是没有收到ACK信号的消息
R如果此时消费者断联，则该消息会被重新入队，投递给下一个消费者。（没有收到ACK的消息是没有超时时间的）
4).RabbitMQ拒绝消息
i.消费者断联时，队列会认为消费者拒绝了消息
ii.消费者使用reject命令拒绝消息。（reject=ture队列会重新分发，false队列会删除掉该消息）
iii.nack命令，批量拒绝
5).RabbitMQ的队列
i.创建队列
（生产/消费）declareQueue。消费者订阅了队列，不能再声明队列了。相关参数（
exclusive 队列为应用程序私有，
auto-delete 最后一个消费者取消订阅时，队列会自动删除，
durable 队列持久化 ）
Declare时的passive参数---检查队列是否存在。
6) .RabbitMQ的四种交换器
i. direct： 路由键完全匹配时，消息投放到对应队列。Amqp实现都必须有一个direct交换器（默认交换器）,名称为空白字符。队列不声明交换器，会自动绑定到默认交换器，队列的名称作为路由键。
ii. Fanout：可以理解为广播
iii. Topic：主题，使来自不同源头的消息到达同一个队列
iv. Headers: 匹配消息头，其余与direct一样，实用性不大
7). 路由键中的“*”和“#”
f) 虚拟主机
Vhost，真实rabbitmq服务器上的mini型虚拟的mq服务器。有自己的权限机制。Vhost提供了一个逻辑上的分离，可以区分客户端，避免队列和交换器的名称冲突。RabbitMq包含了一个缺省的vhost :“/”，用户名guest，口令 guest（guest用户只能在本机访问）。
4.消息持久化
a.消息持久化的条件
i.队列必须持久化
ii.交换器必须持久化
iii.消息的投递模式必须是int型
b.消息持久化的性能问题
会导致性能整体下降10倍左右
5. AMQP & JMS
|
JMS |
AMQP |
定义 |
Java api |
协议 |
Model |
P2P Pub/Sub |
Direct Fanout Topic headers |
支持消息类型 |
5种 |
Byte[] 自行消息序列化，Json化 |
综合评价 |
Java系统，模型满足要求，跨平台较差 |
协议，天然跨平台，跨语言 |
6. 事务/发送方确认
a. 事务
生产者不知道消息是否真正到达RabbitMq，也就是说发布操作不返回任何消息给生产者。
AMQP协议层面为我们提供的事务机制解决了这个问题，但是事务机制本身也会带来问题：
i、严重的性能问题
ii、使生产者应用程序产生同步
b. 发送方确认
RabbitMQ团队为我们拿出了更好的方案，即采用发送方确认模式，该模式比事务更轻量，性
能影响几乎可以忽略不计。
发送方确认模式的机制。
注意：发送方确认模式和消费者对消息的确认是不同的。