RabbitMQ原理剖析

RabbitMQ原理剖析

都知道RabbitMQ是消息队列，是一种应用程序对应用程序的通信方法；应用程序通过读写消息对列来进行通信，而无需专用连接来链接他们。

RabbitMQ的网络架构图

可以看到，大致过程是数据发布者发布数据给Exchange，Exchange接受数据后与对应Queue Binding，然后消费者与Queue建立连接Connection，通过通道消费Queue中的消息。

可以看到整个过程可以分为四部分消息生产者、Exchange、消息队列Message Queue、与消费者Consumer

AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。

简单介绍AMQP的协议栈，AMQP协议本身包含三层，如下：

Model Layer，位于协议最高层，主要定义了一些供客户端调用的命令，客户端可以通过这些命令实现自己的业务逻辑，例如，客户端可以通过queue declare声明一个队列，利用consume命令获取队列的消息。

Session Layer，主要负责将客户端命令发送给服务器，在将服务器端的应答返回给客户端，主要为客户端与服务器之间通信提供可靠性、同步机制和错误处理。

Transport Layer，主要传输二进制数据流，提供帧的处理、信道复用、错误检测和数据表示。

这种分层架构类似于OSI网络协议，可替换各层实现而不影响与其它层的交互。AMQP定义了合适的服务器端域模型，用于规范服务器的行为（AMQP服务器端可称为broker）。在这里Model层决定这些基本域模型所产生的行为，这种行为在AMQP中用command表示。Session层定义客户端与broker之间的通信（通信双方都是一个peer，可互称做partner），为command的可靠传输提供保障。Transport层专注于数据传送，并与Session保持交互，接受上层的数据，组装成二进制流，传送到receiver后再解析数据，交付给Session层。Session层需要Transport层完成网络异常情况的汇报，顺序传送command等工作。

RabbitMQ是基于AMQP的，接下来了解下AMQP当中的一些概念。

Broker（Server）：接受客户端连接，实现AMQP消息队列和路由功能的进程。

Virtual Host：其实是一个虚拟概念，类似于权限控制组，一个Virtual Host里面可以有若干个Exchange和Queue，但是权限控制的最小粒度是Virtual Host。

Exchange：接受生产者发送的消息，并根据Binding规则将消息路由给服务器中的队列。ExchangeType决定了Exchange路由消息的行为，例如，在RabbitMQ中，ExchangeType有direct、Fanout和Topic三种，不同类型的Exchange路由的行为是不一样的。

Message Queue：消息队列，用于存储还未被消费者消费的消息。

Message：由Header和Body组成，Header是由生产者添加的各种属性的集合，包括Message是否被持久化、由哪个Message Queue接受、优先级是多少等。而Body是真正需要传输的APP数据。

Binding：Binding联系了Exchange与MessageQueue。Exchange在与多个MessageQueue发生Binding后会生成一张路由表，路由表中存储着Message Queue所需消息的限制条件即Binding Key。当Exchange收到Message时会解析其Header得到Routing Key，Exchange根据Routing Key与ExchangeType将Message路由到MessageQueue。Binding Key由Consumer在Binding Exchange与MessageQueue时指定，而Routing Key由Producer发送Message时指定，两者的匹配方式由ExchangeType决定。

Connection：连接，对于RabbitMQ而言，其实就是一个位于客户端和Broker之间的TCP连接。

Channel：信道，仅仅创建了客户端到Broker之间的连接后，客户端还是不能发送消息的。需要为每一个Connection创建Channel，AMQP协议规定只有通过Channel才能执行AMQP的命令。一个Connection可以包含多个Channel。之所以需要Channel，是因为TCP连接的建立和释放都是十分昂贵的，如果一个客户端每一个线程都需要与Broker交互，如果每一个线程都建立一个TCP连接，暂且不考虑TCP连接是否浪费，就算操作系统也无法承受每秒建立如此多的TCP连接。RabbitMQ建议客户端线程之间不要共用Channel，至少要保证共用Channel的线程发送消息必须是串行的，但是建议尽量共用Connection。

Command：AMQP的命令，客户端通过Command完成与AMQP服务器的交互来实现自身的逻辑。例如在RabbitMQ中，客户端可以通过publish命令发送消息，txSelect开启一个事务，txCommit提交一个事务。

消息中间件的主要功能是消息的路由(Routing)和缓存(Buffering)。在AMQP中提供类似功能的两种域模型：Exchange 和 Messagequeue。

总的来说消息队列中间件的主要功能就是消息的路由（Routing）与消息的缓存（Buffering）。分别对应AMQP中烦人Exchange与MessqgeQueue。

一个Message的处理流程类似于下图：

Message是当前模型中所操纵的基本单位，它由Producer产生，经过Broker被Consumer所消费。它的基本结构有两部分: Header和Body。Header是由Producer添加上的各种属性的集合，这些属性有控制Message是否可被缓存，接收的queue是哪个，优先级是多少等。Body是真正需要传送的数据，它是对Broker不可见的二进制数据流，在传输过程中不应该受到影响。

一个broker中会存在多个Message queue，Exchange怎样知道它要把消息发送到哪个Message queue中去呢? 这就是上图中所展示Binding的作用。Messagequeue的创建是由client application控制的，在创建Message queue后需要确定它来接收并保存哪个Exchange路由的结果。Binding是用来关联Exchange与Message queue的域模型。Clientapplication控制Exchange与某个特定Messagequeue关联，并将这个queue接受哪种消息的条件绑定到Exchange，这个条件也叫Binding key或是 Criteria。

在与多个Messagequeue关联后，Exchange中就会存在一个路由表，这个表中存储着每个Message queue所需要消息的限制条件。Exchange就会检查它接受到的每个Message的Header及Body信息，来决定将Message路由到哪个queue中去。Message的Header中应该有个属性叫Routing Key，它由Message发送者产生，提供给Exchange路由这条Message的标准。Exchange根据不同路由算法有不同有ExchangeType。比如有Direct类似，需要Bindingkey等于Routing key；也有Bindingkey与Routing key符合一个模式关系；也有根据Message包含的某些属性来判断。一些基础的路由算法由AMQP所提供，clientapplication也可以自定义各种自己的扩展路由算法。

在AMQP中，Client application想要与Broker沟通，就需要建立起与Broker的connection，这种connection其实是与Virtual Host相关联的，也就是说，connection是建立在client与Virtual Host之间。可以在一个connection上并发运行多个channel，每个channel执行与Broker的通信，我们前面提供的session就是依附于channel上的。

这里的Session可以有多种定义，既可以表示AMQP内部提供的command分发机制，也可以说是在宏观上区别与域模型的接口。正常理解就是我们平时所说的交互context，主要作用就是在网络上可靠地传递每一个command。在AMQP的设计中，应当是借鉴了TCP的各种设计，用于保证这种可靠性。

在Session层，为上层所需要交互的每个command分配一个惟一标识符(可以是一个UUID)，是为了在传输过程中可以对command做校验和重传。Command发送端也需要记录每个发送出去的command到ReplayBuffer，以期得到接收方的回馈，保证这个command被接收方明确地接收或是已执行这个command。对于超时没有收到反馈的command，发送方再次重传。如果接收方已明确地回馈信息想要告知command发送方但这条信息在中途丢失或是其它问题发送方没有收到，那么发送方不断重传会对接收方产生影响，为了降低这种影响，command接收方设置一个过滤器IdempotencyBarrier，来拦截那些已接收过的command。关于这种重传及确认机制，可以参考下TCP的相关设计。