RabbitMQ学习总结(1)-基础概念
1. 概念
1.1 AMQP协议
AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。Erlang中的实现有RabbitMQ等。
AMQP协议中的基本概念：
Broker：接收和分发消息的应用，我们在介绍消息中间件的时候所说的消息系统就是Message Broker。
Virtual host（虚拟地址）: 出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于MySQL中库的概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。
Connection（连接）：publisher／consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。
Channel（通道）：如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel是在connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别channel，所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。
Exchange（交换机）：message到达broker的第一站，根据分发规则，匹配查询表中的routing key，分发消息到queue中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。
Queue（队列）：消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。
Binding（绑定）：exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。
Exchange的类型：
direct：这种类型的交换机的路由规则是根据一个routingKey的标识，交换机通过一个routingKey与队列绑定 ，在生产者生产消息的时候 指定一个routingKey 当绑定的队列的routingKey 与生产者发送的一样 那么交换机会吧这个消息发送给对应的队列。
fanout：这种类型的交换机路由规则很简单，只要与他绑定了的队列， 他就会把消息发送给对应队列（与routingKey没关系）
topic：这种类型的交换机路由规则也是和routingKey有关，只不过 topic他可以根据*，#（ *代表过滤一单词，#代表过滤后面所有单词， 用.隔开）来识别routingKey。
headers：这个类型的交换机很少用到，他的路由规则 与routingKey无关 而是通过判断header参数来识别的， 基本上没有应用场景，因为上面的三种类型已经能应付了。
1.2 RabbitMQ
MQ： message Queue 顾名思义 消息队列， 队列大家都知道， 存放内容的一个东西， 存放的内容先进先出， 消息队列， 只是里面存放的内容是消息而已。
RabbitMQ：是一个开源的，基于AMQP协议实现的一个完整的企业级消息中间件，服务端语言由Erlang（面向并发编程）语言编写，对于高并发的处理有着天然的优势，客户端支持非常多的语言。
2 消息状态、消息确认机制
1. 消息状态、消息确认机制
这个截图是RabbitMQ管理工具中，队列Queues的内容。
消息状态描述：
- Ready：准备状态，表示消息生产者已经发出了消息，消费者还没有消费。
- Unacked：待确认状态，消费者需要手动确认消息。
- Total：表示当前队列中的消息总量
Ready状态是一条消息的初始状态，是刚发出来的消息。如果发现此队列的消息是需要手动确认的，会改为Unacked状态。如果消息被消费掉，此条消息从队列里删除。Unacked状态是需要用户手动确认消息的，如果消息被消费者正常消费确认，这条消息就会被队列清除。如果在消息接收过程中，消费者与交换机断开了连接，Unacked状态会改变成Ready状态。
消息消费者确认消息分为：自动确认、手动确认。
消息丢失问题：在自动确认的情况，因为RibbitMQ在确认一条消息被消费者确认之后，就会从队列里删除。假设消费者收到了消息，就自动确认，但执行后续消息有关的业务逻辑失败，或者服务挂了，这个时候MQ队列已经没有了这条消息，而消费者又没有消费成功，这就造成了消息丢失的问题。
消息堆积问题：如果消息一直没有确认，就会造成消息堆积问题。