AMPQ
欢迎光临我的博客[http://poetize.cn]，前端使用Vue2，聊天室使用Vue3，后台使用Spring Boot
AMPQ
AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，
是`应用层协议的一个开放标准，为面向消息的中间件设计`。
由于AMQP是一个网络协议，所以发布者、消费者以及消息中间件可以部署到不同的物理机器上面。
消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。
基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品、不同开发语言等条件的限制。
AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
AMQP在消息提供者和客户端的行为进行了强制规定，使得不同卖商之间真正实现了互操作能力。
交换器（exchange）
生产者生产消息至交换器之后，由交换器负责将消息转发出去。
根据交换器类型的不同，交换器将消息转发出去的转发规则也会有所不同。
目前，AMQP提供了四种不同的交换器类型：direct, fanout, topic, header
交换器还有许多属性可供设置。其中比较重要的属性有：name, durability, auto-delete, arguments
默认交换器
不指定交换器类型时，交换器默认是direct类型，其name属性为空。
并且默认交换器有一个重要的特性：
每个队列都会使用它的队列名字作为路由关键字（routing key）去自动地绑定到默认交换器上。
换言之，对于默认的交换器，无需用队列对其进行绑定操作，因为所有的队列都会自动的与之绑定。
消息会转发给与该路由关键字同名的队列中去。
direct类型
该类型的交换器在分发消息到指定队列时要求：
生产者生产某条消息时指定的路由关键字 X 与队列绑定到交换器上时指定的路由关键字 Y 完全一致，即X = Y。
多个队列可以使用相同的路由关键字与交换器绑定（多个X=Y）。这样一来，消息就会被分发至多个队列中。
但是，需要注意的是，消息负载均衡并不在于队列间，而是在于消费者间。
fanout类型
该类型的交换器会将消息转发给所有与之绑定的队列上。
比如，有N个队列与fanout交换器绑定，当产生一条消息时，交换器会将该消息的N个副本分别发给每个队列。类似于广播机制。
topic类型
该类型的交换器会视消息路由关键字和绑定路由关键字之间的匹配情况，进行消息的路由转发。
比如，消息路由关键字为x.y.z的消息会转发给绑定路由关键字为*.y.*的队列，也会转发给绑定路由关键字为x.#的队列，
但却不会转发给绑定路由关键字为*.a.*的队列。
headers类型
该类型的交换器不再是基于路由关键字（routing key）进行路由，而是基于多个属性进行路由的
用于路由的属性是取自于消息header属性的，当消息header的值与队列绑定时指定的值相同时，消息就会路由至相应的队列中。
队列（Queues）
AMQP模型中的队列用来存储消费者待消费的消息。
主要的属性有：name, durable, exclusive, auto-delete, arguments。
需要注意的是，队列在使用之前必须先声明。
- 声明之前，如果该队列不存在，那么声明之后就会创建一个队列；
- 如果该队列已经存在了，并且声明的队列与存在的队列属性相同，则不产生任何影响；
- 如果该队列已经存在了，但是声明的队列与存在的队列属性不同，则会抛出一个错误码为406（PRECONDITION_FAILED）的异常。
name属性
指定队列名，当应用程序指定name属性为空时，代理（broker）会自动地为其生成一个唯一的队列名。
durability属性
durability属性对应两种情况，分别是durable（持久的）和transient（短暂的）。
durable类型的队列会持久化至硬盘上，所以当代理（broker）重启之后，它依然存在。
相反地，当代理重启之后，transient类型的队列就消失了。
需要注意的是，队列的持久化是相对队列而言，对存储在持久化队列中的消息来说，当代理重启之后：队列还存在、消息则不存在。
所以，当broker重启之后，如果想让消息仍然存在，这就是消息持久化机制干的事了。
绑定（binding）
队列获取来自交换器的消息的前提是该队列必须先与交换器进行绑定。
如果生产者生产的某条消息，没有与之匹配的任何一个队列可供路由。
那么，根据该条消息的属性，该消息要么丢弃，要么返回至生产者。
连接（connection）
我们已经知道，AMQP是一个应用层协议，并且是基于TCP可靠传输的应用层协议。
除此之外，AMQP也提供了加密传输的机制（使用TSL或SSL），让消息传递更加安全。
通道（channel）
有的应用程序需要与AMQP broker建立多个连接。
在AMQP模型中，我们不需要通过建立太多的TCP连接来实现。
假如针对每一个AMQP连接都建立一个TCP连接的话，会占用大量的系统资源。
对此，AMQP提供了通道（channel）机制。即，共享一个TCP连接，可创建多个通道。
在多线程/进程的应用程序中正确做法是，对于每一个线程/进程，应分别建立一个通道，而不是多个线程/进程之间去共享一个通道。
虚拟机（virtual hosts）
AMQP使用了虚拟机的概念，在一个broker上面划分出多个隔离的环境（各环境下的用户、交换器以及队列等互不影响）。
这样一来，AMQP客户端们在进行连接的时候，需要协商指定同一个vhost才能进行正常的往来业务。
消息确认（message acknowledgements）
AMQP给出了两种处理办法：
一是，当消息代理（broker）将一条消息发送给消费者应用程序之后就将其从队列中移除；
二是，当消费者应用程序返还一条确认信息之后（类似于TCP三次握手中的ack确认）就将其从队列中移除。
第一种处理方法是自动确认的，称为automatic acknowledgement；
第二种处理方法则需要由消费者进行确认操作，称为explicit acknowledgement。
拒绝消息（rejecting messages）
消费者应用程序在处理消息失败时，应用程序可以通知broker：消息处理失败，拒绝消息。
当拒绝消息时，消费者应用程序可以要求broker丢弃或重新发送该消息。
