RabbitMQ组成及原理介绍-3

rabbitmq作为成熟的企业消息中间件，实现了应用程序间接口调用的解耦，提高系统的吞吐量。

1.RabbitMQ组成

是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成，因此也是继承了这些优点。
AMQP 里主要要说两个组件：Exchange 和 Queue （在 AMQP 1.0 里还会有变动），如下图所示，绿色的 X 就是 Exchange ，红色的是 Queue ，这两者都在 Server 端，又称作 Broker ，这部分是 RabbitMQ 实现的，而蓝色的则是客户端，通常有 Producer 和 Consumer 两种类型：

RabbitMQ Server：也叫broker server，它不是运送食物的卡车，而是一种传输服务。原话是RabbitMQ isn’t a food truck, it’s a delivery service. 他的角色就是维护一条从Producer到Consumer的路线，保证数据能够按照指定的方式进行传输。但是这个保证也不是100%的保证，但是对于普通的应用来说这已经足够了。当然对于商业系统来说，可以再做一层数据一致性的guard，就可以彻底保证系统的一致性了。
Client A & B：也叫Producer，数据的发送方。create messages and publish (send) them to a broker server (RabbitMQ).一个Message有两个部分：payload（有效载荷）和label（标签）。payload顾名思义就是传输的数据。label是exchange的名字或者说是一个tag，它描述了payload，而且RabbitMQ也是通过这个label来决定把这个Message发给哪个Consumer。AMQP仅仅描述了label，而RabbitMQ决定了如何使用这个label的规则。
Client 1，2，3：也叫Consumer，数据的接收方。Consumers attach to a broker server (RabbitMQ) and subscribe to a queue。把queue比作是一个有名字的邮箱。当有Message到达某个邮箱后，RabbitMQ把它发送给它的某个订阅者即Consumer。当然可能会把同一个Message发送给很多的Consumer。在这个Message中，只有payload，label已经被删掉了。对于Consumer来说，它是不知道谁发送的这个信息的。就是协议本身不支持。但是当然了如果Producer发送的payload包含了Producer的信息就另当别论了。

对于一个数据从Producer到Consumer的正确传递，还有三个概念需要明确：exchanges, queues and bindings。

Exchanges are where producers publish their messages.
Queues are where the messages end up and are received by consumers
Bindings are how the messages get routed from the exchange to particular queues.

还有几个概念是上述图中没有标明的，那就是Connection（连接），Channel（通道，频道）。

Connection：就是一个TCP的连接。Producer和Consumer都是通过TCP连接到RabbitMQ Server的。以后我们可以看到，程序的起始处就是建立这个TCP连接。
Channels： 虚拟连接。它建立在上述的TCP连接中。数据流动都是在Channel中进行的。也就是说，一般情况是程序起始建立TCP连接，第二步就是建立这个Channel。
那么，为什么使用Channel，而不是直接使用TCP连接？

对于OS来说，建立和关闭TCP连接是有代价的，频繁的建立关闭TCP连接对于系统的性能有很大的影响，而且TCP的连接数也有限制，这也限制了系统处理高并发的能力。但是，在TCP连接中建立Channel是没有上述代价的。对于Producer或者Consumer来说，可以并发的使用多个Channel进行Publish或者Receive。有实验表明，1s的数据可以Publish10K的数据包。当然对于不同的硬件环境，不同的数据包大小这个数据肯定不一样，但是我只想说明，对于普通的Consumer或者Producer来说，这已经足够了。如果不够用，你考虑的应该是如何细化split你的设计。

Exchange

Exchange是属于Vhost的。同一个Vhost不能有重复的Exchange名称。 Exhange有四种类型：fanout，Direct，header，topic。

Exchange接受Producer发送的Message并根据不同路由算法将Message发送到Message Queue。

　从架构图可以看出，Procuder Publish的Message进入了Exchange。接着通过“routing keys”， RabbitMQ会找到应该把这个Message放到哪个queue里。queue也是通过这个routing keys来做的绑定。

Exchange的绑定功能，可以绑定queue，也可以绑定Exchange。这个看具体业务了。如果绑定数据，需要在分发或者重新被分派，使用To Exchange绑定。如果要被直接处理，使用queue绑定。如果Exchange绑定了Queue，如果Route Key不对，也会导致数据不可达，被丢掉。（一个数据可以被Queue处理，需要Exchange绑定Queue，并且在Message发送的时候，Route Key 与绑定的Key相等。我们发送一个空数据，Route Key随便制定了Hello，消息虽然发送，但是客户获得失败。

有四种类型的Exchanges：direct, fanout,topic。每个实现了不同的路由算法（routing algorithm）。

Direct exchange: 如果 routing key 匹配, 那么Message就会被传递到相应的queue中。其实在queue创建时，它会自动的以queue的名字作为routing key来绑定那个exchange。(转发消息到routigKey指定的队列)
Fanout exchange: 会向响应的queue广播。(转发消息到所有绑定队列)
Topic exchange: 对key进行模式匹配，比如ab*可以传递到所有ab*的queue。(按规则转发消息（最灵活）)

Queue：

　　Message Queue会在Message不能被正常消费时将其缓存起来，但是当Consumer与Message Queue之间的连接通畅时，Message Queue将Message转发给Consumer。
Message由Header和Body组成，Header是由Producer添加的各种属性的集合，包括Message是否客被缓存、由哪个Message Queue接受、优先级是多少等。而Body是真正需要传输的APP数据。

Exchange与Message Queue之间的关联通过Binding来实现。Exchange在与多个Message
Queue发生Binding后会生成一张路由表，路由表中存储着Message Queue所需消息的限制条件即Binding
Key。当Exchange收到Message时会解析其Header得到Routing Key，Exchange根据Routing
Key与Exchange Type将Message路由到Message Queue。

　　Binding Key由Consumer在Binding Exchange与Message Queue时指定，而Routing Key由Producer发送Message时指定，两者的匹配方式由Exchange Type决定。

Exchange Type分为Direct（单播）、Topic（组播）、Fanout（广播）。当为Direct（单播）时，Routing
Key必须与Binding Key相等时才能匹配成功，当为Topic（组播）时，Routing Key与Binding
Key符合一种模式关系即算匹配成功，当为Fanout（广播）时，不受限制。默认Exchange Type是Direct（单播）。

routing：exchange和queue之间绑定的媒介，成为routing key。

message acknowledgment: 消息确认，解决消息确认问题，只有收到ack之后才能从消息系统中删除。

message durability: 消息持久化，当rabbitmq退出或崩溃后，会把queue中的消息持久化。但注意，RabbitMQ并不能百分之百保证消息一定不会丢失，因为为了提升性能，RabbitMQ会把消息暂存在内存缓存中，直到达到阀值才会批量持久化到磁盘，也就是说如果在持久化到磁盘之前RabbitMQ崩溃了，那么就会丢失一小部分数据，这对于大多数场景来说并不是不可接受的，如果确实需要保证任务绝对不丢失，那么应该使用事务机制。

Virtual hosts

每个virtual host本质上都是一个RabbitMQ Server，拥有它自己的queue，exchange，和bind rule等等。这保证了你可以在多个不同的application中使用RabbitMQ。

　RabbitMQ的Vhost主要是用来划分不同业务模块。不同业务模块之间没有信息交互。Vhost之间相互完全隔离，不同Vhost之间无法共享Exchange和Queue。因此Vhost之间数据无法共享和分享。如果要实现这种功能，需要Vhost之间手动构建对应代码逻辑。

Vhost其实在用户之间是透明的，Vhost可以被多个用户访问，而一个用户可以同时访问多个Vhost。例如：peter可以同时访问"/"和"/vhost"。

Virtual Host是个虚拟概念，可以持有一些Exchange和Message Queue。一个Virtual Host可以是一台服务器，也可以是由多台服务器组成的集群。Exchange和Message Queue可以分别部署在一台或者多台服务器上。

2 应用场景

言归正传。RabbitMQ，或者说AMQP解决了什么问题，或者说它的应用场景是什么？

对于一个大型的软件系统来说，它会有很多的组件或者说模块或者说子系统或者（subsystem or Component or submodule）。那么这些模块的如何通信？这和传统的IPC有很大的区别。传统的IPC很多都是在单一系统上的，模块耦合性很大，不适合扩展（Scalability）；如果使用socket那么不同的模块的确可以部署到不同的机器上，但是还是有很多问题需要解决。比如：

1）信息的发送者和接收者如何维持这个连接，如果一方的连接中断，这期间的数据如何方式丢失？

2）如何降低发送者和接收者的耦合度？

3）如何让Priority高的接收者先接到数据？

4）如何做到load balance？有效均衡接收者的负载？

5）如何有效的将数据发送到相关的接收者？也就是说将接收者subscribe 不同的数据，如何做有效的filter。

6）如何做到可扩展，甚至将这个通信模块发到cluster上？

7）如何保证接收者接收到了完整，正确的数据？

AMDQ协议解决了以上的问题，而RabbitMQ实现了AMQP。