以Rabbit MQ为例讲透消息队列-mq消息队列

【51CTO.com快译】在早年的单体架构时代，由于应用程序的内部组件存在着紧密的耦合关系，因此它们之间存在着千丝万缕的直接关联。例如，在一个简单的电子商务应用中，其结帐服务需要与支付网关服务保持通信。这就得依靠TCP的直接连接来完成。由此，我们很容易碰到如下限制场景：

一旦结帐消息被发出后，应用需要能够及时侦听到，并予以答复，方可继续执行下一个任务。
如果库存服务出现了故障，应用将进行反复尝试，直至连接被成功建立为止。
如果同时有大量的支付请求产生，库存服务将由于供不应求，而导致整个系统陷入瘫痪。

可以说，这些都是创建消息队列和代理(message queues/brokers)的“刚需”。

什么是消息队列

如下图所示，消息队列往往处于需要彼此通信的两个服务之间：

通信服务的流程图

如上图所示，系统1通常作为生产者(producer)会将消息添加到队列中，以便立即执行下一个任务。

在准备就绪后，系统2作为使用者(consumer)会从队列中获取消息，予以处理，并在完成后立即转向下一条消息。据此，两个应用系统实现了逻辑上的解耦关系。

同时，消息代理也有助于提高系统的可扩展性。当系统中有大量并发的“获取”操作时，队列会出现拥堵，这就意味着我们需要提供更多的取出服务。那么在上述例子的系统2中，如果有多个使用者要从队列中读取内容，以满足由大量用户的支付请求所产生的负载时，应用系统需要具一定的可扩展能力。

此外，消息队列的另一个好处是：队列本身可以被构建在计算机或服务器的内部，以分担Web应用程序的某些工作，进而提高系统的整体性能。

生产者和使用者的流程图

不知您是否听说过RabbitMQ?它是高级消息队列协议(Advanced Message Queuing Protocol，AMQP)模型的实现。

在此类消息模型中，生产者会去获取那些由服务产生的消息。就效率而言，与其我们直接产生一个消息队列，不如产生消息的交换节点。而交换节点恰好可以像中转邮局一样，去接收所有的消息，然后根据它们的处理方式予以分发。

如上图所示，一个交换节点可以连接多个队列。在上面的例子中，使用者1、2、3在系统中扮演等待队列连接的使用者。它们需要用到(consume)结帐服务。也就是说，在该流程中，结帐操作将发送一条消息给交换节点。而此类交换是通过各种绑定(bindings)被连接到不同的队列上。当然，我们可以通过绑定键(binding key)，来引用这些绑定，以方便它们进入应用程序中使用者服务的子队列。