[转载] 专栏:RabbitMQ从入门到精通

最近有用到RabbitMQ,在网上搜到几篇介绍文章,除去CSDN的排版不说,文章内容还是很好的。

原文网址:http://blog.csdn.net/column/details/rabbitmq.html

下面是几篇文章的摘要,详情请跳转原文阅读。

文章摘要

RabbitMQ是一个在AMQP基础上完整的,可复用的企业消息系统。它可以用于大型软件系统各个模块之间的高效通信,支持高并发,支持可扩展。

RabbitMQ消息队列(一): Detailed Introduction 详细介绍

对于一个大型的软件系统来说,它会有很多的组件或者说模块或者说子系统或者(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。

RabbitMQ消息队列(二):“Hello, World”

首先复习一下上篇所学:RabbitMQ实现了AMQP定义的消息队列。它实现的功能“非常简单”:从Producer接收数据然后传递到Consumer。它能保证多并发,数据安全传递,可扩展。

和任何的Hello World一样,它们都不复杂。我们将会设计两个程序,一个发送Hello world,另一个接收这个数据并且打印到屏幕。

RabbitMQ消息队列(三):任务分发机制

在上篇文章中,我们解决了从发送端(Producer)向接收端(Consumer)发送“Hello World”的问题。在实际的应用场景中,这是远远不够的。从本篇文章开始,我们将结合更加实际的应用场景来讲解更多的高级用法。

当有Consumer需要大量的运算时,RabbitMQ Server需要一定的分发机制来balance每个Consumer的load。试想一下,对于web application来说,在一个很多的HTTP request里是没有时间来处理复杂的运算的,只能通过后台的一些工作线程来完成。接下来我们分别讲解。

应用场景就是RabbitMQ Server会将queue的Message分发给不同的Consumer以处理计算密集型的任务。

RabbitMQ消息队列(四):分发到多Consumer(Publish/Subscribe)

这篇文章中,我们将创建一个日志系统,它包含两个部分:第一个部分是发出log(Producer),第二个部分接收到并打印(Consumer)。我们将构建两个Consumer,第一个将log写到物理磁盘上;第二个将log输出的屏幕。

RabbitMQ 的Messaging Model就是Producer并不会直接发送Message到queue。实际上,Producer并不知道它发送的Message是否已经到达queue。

Producer发送的Message实际上是发到了Exchange中。它的功能也很简单:从Producer接收Message,然后投递到queue中。Exchange需要知道如何处理Message,是把它放到那个queue中,还是放到多个queue中?这个rule是通过Exchange的类型定义的。

我们知道有三种类型的Exchange:direct, topic 和fanout。fanout就是广播模式,会将所有的Message都放到它所知道的queue中。

RabbitMQ消息队列(五):Routing 消息路由

上篇文章中,我们构建了一个简单的日志系统。接下来,我们将丰富它:能够使用不同的severity来监听不同等级的log。比如我们希望只有error的log才保存到磁盘上。

RabbitMQ消息队列(六):使用主题进行消息分发

在上篇文章中,我们实现了一个简单的日志系统。Consumer可以监听不同severity的log。但是,这也是它之所以叫做简单日志系统的原因,因为是仅仅能够通过severity设定。不支持更多的标准。

比如syslog unix的日志工具,它可以通过severity (info/warn/crit…) 和模块(auth/cron/kern…)。这可能更是我们想要的:我们可以仅仅需要cron模块的log。

为了实现类似的功能,我们需要用到topic exchange。

RabbitMQ消息队列(七):适用于云计算集群的远程调用(RPC)

在云计算环境中,很多时候需要用它其他机器的计算资源,我们有可能会在接收到Message进行处理时,会把一部分计算任务分配到其他节点来完成。那么,RabbitMQ如何使用RPC呢?在本篇文章中,我们将会通过其它节点来求斐波纳契完成示例。

为了展示一个RPC服务是如何使用的,我们将创建一段很简单的客户端class。它将会向外提供名字为call的函数,这个call会发送RPC请求并且阻塞知道收到RPC运算的结果。

RabbitMQ消息队列的小伙伴: ProtoBuf(Google Protocol Buffer)

什么是ProtoBuf?

一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python 三种语言的 API。

它可以作为RabbitMQ的Message的数据格式进行传输,由于是结构化的数据,这样就极大的方便了Consumer的数据高效处理。当然了你可能说使用XML不也可以吗?与XML相比,ProtoBuf有以下优势:

  1. 简单
  2. size小了3-10倍
  3. 速度快了20-100倍
  4. 易于编程
  5. 减小了语义的歧义

RabbitMQ消息队列(九):Publisher的消息确认机制

在前面的文章中提到了queue和consumer之间的消息确认机制:通过设置ack。那么Publisher能不到知道他post的Message有没有到达queue,甚至更近一步,是否被某个Consumer处理呢?毕竟对于一些非常重要的数据,可能Publisher需要确认某个消息已经被正确处理。

在我们的系统中,我们没有是实现这种确认,也就是说,不管Message是否被Consume了,Publisher不会去关心。他只是将自己的状态publish给上层,由上层的逻辑去处理。如果Message没有被正确处理,可能会导致某些状态丢失。但是由于提供了其他强制刷新全部状态的机制,因此这种异常情况的影响也就可以忽略不计了。

对于某些异步操作,比如客户端需要创建一个FileSystem,这个可能需要比较长的时间,甚至要数秒钟。这时候通过RPC可以解决这个问题。因此也就不存在Publisher端的确认机制了。

那么,有没有一种机制能保证Publisher能够感知它的Message有没有被处理的?答案肯定的。