关于rabbitmq:一RabbitMQ消息路由机制

一、Rabbit 路由协定——AMQP 协定

AMQP（Advanced Message Queuing Protocol，高级音讯队列协定）是一个网络协议。它反对符合要求的客户端利用（application）和消息中间件代理（messaging middleware broker）之间进行通信。次要特色是面向音讯、队列、路由（包含点对点和公布 / 订阅）、可靠性、平安。
简略点说就是在异样通信中，音讯不会立刻达到接管方，而是被寄存到一个容器中，当满足肯定的条件之后，音讯会被容器发送给接管方，这个容器就是音讯队列（MQ），而实现这个性能须要单方和容器以及其中的各个组件遵循规定，AMQP 就是这样一种协定，音讯发送和接管的单方都要恪守。
AMQP 机制为：音讯（message）被发布者（publisher）发送给交换机（exchange），交换机将收到的音讯依据路由规定发给绑定的队列（queue）。最初 AMQP 代理会将音讯投递给订阅了此队列的消费者，或者消费者依照需要自行获取，如图：

这是一个简略的“Hello，world”示例，从发布者到生成者音讯的大抵流向，其中还省略了一些 AMQP 理论的组件细节。这里次要包含以下一些组件：

Publisher，数据的发送方。
Exchange，音讯交换机，它指定音讯按什么规定，路由到哪个队列，这里的规定前面会有介绍。
Queue，音讯队列载体，每个音讯都会被投入到一个或多个队列。
Consumer，数据的接管方。
发布者（Publisher）公布音讯时能够给音讯指定各种音讯属性（message meta-data）。有些属性有可能会被音讯代理（Brokers）应用，然而其余的属性则是齐全不通明的，它们只能被接管音讯的利用所应用。

从平安角度思考，网络是不牢靠的，接管音讯的利用也有可能在解决音讯的时候失败。基于此起因，AMQP 模块蕴含了一个音讯确认（message acknowledgements）的概念：当一个音讯从队列中投递给消费者后（Consumer），消费者会告诉一下音讯代理（Broker），这个能够是主动的，也能够由解决音讯的利用的开发者执行。当“音讯确认”被启用的时候，音讯代理不会齐全将音讯从队列中删除，直到它收到来自消费者的确认回执（acknowledgement）。

在某些状况下，例如当一个音讯无奈被胜利路由时，音讯或者会被返回给发布者并被抛弃。或者，如果音讯代理执行了延期操作，音讯会被放入一个所谓的死信队列中。此时，音讯发布者能够抉择某些参数来解决这些非凡状况。

队列，交换机和绑定统称为 AMQP 实体（AMQP entities）。

以上这些是在上图中显示进去的一些 AMQP 组件元件，除了这些外，还有一些额定的概念，次要为：
Binding，绑定，音讯队列与交换器间接关联的，它的作用就是把 Exchange 和 Queue 依照路由规定绑定起来。

Routing Key，路由关键字，Exchange 依据这个关键字进行音讯投递。

Channel，信道，多路复用连贯中的一条独立的双向数据流通道，为会话提供物理传输介质。Channel 是在 connection 外部建设的逻辑连贯，如果应用程序反对多线程，通常每个 thread 创立独自的 channel 进行通信，AMQP method 蕴含了 channel id 帮忙客户端和 message broker 辨认 channel，所以 channel 之间是齐全隔离的。Channel 作为轻量级的 Connection 极大缩小了操作系统建设 TCP connection 的开销。在客户端的每个连贯里，可建设多个 Channel，每个 Channel 代表一个会话工作。

Broker，AMQP 的服务端称为 Broker。其实 Broker 就是接管和散发音讯的利用，也就是说 RabbitMQ Server 就是 Message Broker。

Virtual Host，虚拟主机，一批交换器（Exchange），音讯队列（Queue）和相干对象。虚拟主机是共享雷同身份认证和加密环境的独立服务器域。同时一个 Broker 里能够开设多个 vhost，用作不同用户的权限拆散。

Connection，连贯，一个网络连接，比方 TCP/IP 套接字连贯。Channel 是建设在 Connection 之上的，一个 Connection 能够建设多个 Channel。

Message，音讯体，是 AMQP 所操纵的根本单位，它由 Producer 产生，通过 Broker 被 Consumer 所生产。它的根本构造有两局部: Header 和 Body。Header 是由 Producer 增加上的各种属性的汇合，这些属性有管制 Message 是否可被缓存，接管的 Queue 是哪个，优先级是多少等。Body 是真正须要传送的数据，它是对 Broker 不可见的二进制数据流，在传输过程中不应该受到影响。

下面的简略实例图只是简略阐明了一些音讯传送的根本流程，可能其中的频道、虚拟主机、连贯、信道等都没有体现进去。到前面 RabbitMQ 的知识点都会缓缓介绍到。

总的 AMQP 的结构图如下所示：

上面对 AMQP 的一些重要概念做详细分析：

交换机（音讯交换机）

交换机是用来发送音讯的 AMQP 实体。交换机拿到一个音讯之后将它路由给一个或零个队列。它应用哪种路由算法是由交换机类型和被称作绑定（bindings）的规定所决定的。

四种交换机：

Direct exchange（直连交换机）
Fanout exchange（扇型交换机）
Topic exchange（主题交换机）
Headers exchange（头交换机）
交换机能够有两个状态：长久（durable）、暂存（transient）。长久化的替换机会在音讯代理（Broker）重启后仍旧存在，而暂存的交换机则不会（它们须要在代理再次上线后从新被申明）。然而并不是所有的利用场景都须要长久化的交换机。

不同的交换机的区别和用法，会在前面的文章中做介绍，这里只须要晓得有几种类型的交换机就能够了。

交换机的几个重要属性：
Name
Durability（音讯代理重启后，交换机是否还存在）
Auto-delete（当所有与之绑定的音讯队列都实现了对此交换机的应用后，删掉它）
Arguments（依赖代理自身）

队列

AMQP 中的队列（Queue）跟其余音讯队列或工作队列中的队列是很类似的：它们存储着行将被利用生产掉的音讯。队列跟交换机共享某些属性，然而队列也有一些另外的属性。

Name
Durable（音讯代理重启后，队列仍旧存在）
Exclusive（只被一个连贯（connection）应用，而且当连贯敞开后队列即被删除）
Auto-delete（当最初一个消费者退订后即被删除）
Arguments（一些音讯代理用他来实现相似与 TTL 的某些额定性能）

队列在申明（declare）后能力被应用。如果一个队列尚不存在，申明一个队列会创立它。如果申明的队列曾经存在，并且属性完全相同，那么此次申明不会对原有队列产生任何影响。如果申明中的属性与已存在队列的属性有差别，那么一个错误代码为 406 的通道级异样就会被抛出。

队列长久化
长久化队列（Durable queues）会被存储在磁盘上，当音讯代理（broker）重启的时候，它仍旧存在。没有被长久化的队列称作暂存队列（Transient queues）。
长久化的队列并不会使得路由到它的音讯也具备持久性。假使音讯代理挂掉了，重新启动，那么在重启的过程中长久化队列会被从新申明，无论怎样，只有通过长久化的音讯能力被从新复原。（队列长久化 ≠ 音讯长久化）

绑定
绑定（Binding）是交换机（Exchange）将音讯（Message）路由给队列（Queue）所需遵循的规定。如果要批示交换机“E”将音讯路由给队列“Q”，那么“Q”就须要与“E”进行绑定。绑定操作须要定义一个可选的路由键（Routing Key）属性给某些类型的交换机。路由键的意义在于从发送给交换机的泛滥音讯中抉择出某些音讯，将其路由给绑定的队列。

打个比方：

队列（Queue）是咱们想要去的目的地
交换机（Exchange）是一个转换站，比方车站
绑定（Binding）就是车站到目的地的路线。可能达到目的地的路线能够是一条或者多条
领有了交换机这个中间层，很多由发布者间接到队列难以实现的路由计划可能得以实现，并且防止了利用开发者的许多重复劳动。

如果 AMQP 的音讯无奈路由到队列（例如，发送到的交换机没有绑定队列），音讯会被就地销毁或者返还给发布者。如何解决取决于发布者设置的音讯属性。

虚拟主机

为了在一个独自的代理上实现多个隔离的环境（用户、用户组、交换机、队列 等），AMQP 提供了一个虚拟主机（virtual hosts – vhosts）的概念。这跟 Web servers 虚拟主机概念十分类似，这为 AMQP 实体提供了齐全隔离的环境。当连贯被建设的时候，AMQP 客户端来指定应用哪个虚拟主机。

连贯

AMQP 连贯通常是长连贯。AMQP 是一个应用 TCP 提供牢靠投递的应用层协定。AMQP 应用认证机制并且提供 TLS（SSL）爱护。当一个利用不再须要连贯到 AMQP 代理的时候，须要优雅的开释掉 AMQP 连贯，而不是间接将 TCP 连贯敞开。

信道

有些利用须要与 AMQP 代理建设多个连贯。无论怎样，同时开启多个 TCP 连贯都是不适合的，因为这样做会消耗掉过多的系统资源并且使得防火墙的配置更加艰难。AMQP 0-9- 1 提供了信道（channels）来解决多连贯，能够把信道了解成共享一个 TCP 连贯的多个轻量化连贯。

在波及多线程 / 过程的利用中，为每个线程 / 过程开启一个信道（channel）是很常见的，并且这些通道不能被线程 / 过程共享。

二、RabbitMQ 的工作流程介绍

1. 建设信息。Publisher 定义须要发送音讯的构造和内容。
2. 建设 Conection 和 Channel。由 Publisher 和 Consumer 创立连贯，连贯到 Broker 的物理节点上，同时建设 Channel。Channel 是建设在 Connection 之上的，一个 Connection 能够建设多个 Channel。Publisher 连贯 Virtual Host 建设 Channel，Consumer 连贯到相应的 Queue 上建设 Channel。
3. 申明交换机和队列。申明一个音讯交换机（Exchange）和队列（Queue），并设置相干属性。
4. 发送音讯。由 Publisher 发送音讯到 Broker 中的 Exchange 中
5. 路由转发。RabbitMQ 收到音讯后，依据​​音讯指定的 Exchange(交换机) 来查找 Binding(绑定) 而后依据规定（Routing Key）散发到不同的 Queue。这里就是说应用 Routing Key 在音讯交换机（Exchange）和音讯队列（Queue）中建设好绑定关系，而后将音讯发送到绑定的队列中去。
6. 音讯接管。Consumer 监听相应的 Queue，一旦 Queue 中有能够生产的音讯，Queue 就将音讯发送给 Consumer 端。

7. 音讯确认。当 Consumer 实现某一条音讯的解决之后，须要发送一条 ACK 音讯给对应的 Queue。

   • Consumer 收到音讯时须要显式的向 RabbitMQ Broker 发送 basic.ack 音讯或者 Consumer 订阅音讯时设置 auto_ack 参数为 true。
   • 在通信过程中，队列对 ACK 的解决有以下几种状况：
   • 如果 Consumer 接管了音讯，发送 ack，RabbitMQ 会删除队列中这个音讯，发送另一条音讯给 Consumer。
   • 如果 Consumer 接管了音讯, 但在发送 ack 之前断开 Channel，RabbitMQ 会认为这条音讯没有被 deliver（递送）, 如果有其余的 Channel，会该音讯将被发送给另外的 Channel。如果没有，当在 Consumer 再次连贯的时候，这条音讯会被 redeliver（从新递送）。
   • 如果 consumer 接管了音讯，然而遗记了 ack,RabbitMQ 不会反复发送音讯。
   • 新版 RabbitMQ 还反对 Consumer reject 某条（类）音讯，能够通过设置 requeue 参数中的 reject 为 true 达到目地，那么 Consumer 将会把音讯发送给下一个注册的 Consumer。
8. 敞开音讯通道（channel）以及和服务器的连贯。