【OpenStack源码分析之二】RabbitMQ分析

前言

正在捋Nova的代码，从服务启动的入口这块就用到了第三方的Oslo_messaging库，可能也是因为消息中间件确实是整个软件的瓶颈，Oslo_messaging试图隔离出消息中间件和应用之间的接口，使得不仅仅可以使用RabbitMQ,也可以使用Kafka等其他中间件。

RabbitMQ介绍

这里十分感谢anzhsoft的技术专栏http://blog.csdn.net/column/details/rabbitmq.html；把RobbitMQ这款中间件工具从使用者的视角写得很全面，我也不想深究里面的细节，在anzhsoft的基础之上我再提取一些用户关心的信息。

历史

RabbitMQ是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。AMQP 的出现其实也是应了广大人民群众的需求，虽然在同步消息通讯的世界里有很多公开标准（如 COBAR的 IIOP ，或者是 SOAP 等），但是在异步消息处理中却不是这样，只有大企业有一些商业实现（如微软的 MSMQ ，IBM 的 Websphere MQ 等），因此，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等联合制定了 AMQP 的公开标准。

RabbitMQ是由RabbitMQ Technologies Ltd开发并且提供商业支持的。该公司在2010年4月被SpringSource（VMWare的一个部门）收购。在2013年5月被并入Pivotal。其实VMWare，Pivotal和EMC本质上是一家的。不同的是VMWare是独立上市子公司，而Pivotal是整合了EMC的某些资源，现在并没有上市。

RabbitMQ的官网是http://www.rabbitmq.com

架构术语

1.Server(broker): 接受客户端连接，实现AMQP消息队列和路由功能的进程。

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

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

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

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

6.Binding:Binding联系了Exchange与Message Queue。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决定。

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

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

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

应用场景

场景1：单发送单接收
这个场景比较简单，只是个Helllo word，并没有太大的实际用途。不过要注意的是Queue和Binding的CURD权限，生产者和消费者是有的，但是vHost和Exchange的权限他们并没有，因为前者和特定用户相关，后者则是多个用户共享使用的。

send.py:

#!/usr/bin/env python  import pika  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.queue_declare(queue='hello')  channel.basic_publish(exchange='',                        routing_key='hello',                        body='Hello World!')  print " [x] Sent 'Hello World!'"  connection.close() 

receive.py:

#!/usr/bin/env python  import pika  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.queue_declare(queue='hello')  print ' [*] Waiting for messages. To exit press CTRL+C'  def callback(ch, method, properties, body):      print " [x] Received %r" % (body,)  channel.basic_consume(callback,                        queue='hello',                        no_ack=True)  channel.start_consuming()  

场景2：任务分发

这种场景是有实际用途的，比如Job的调度，所以Rabbit在这个场景上做了HA的保障工作以及调度的优化：

为了防止消息丢失做了持久化；防止消息不被处理又增加了消息确认机制。这里面要注意，Consumer端在完成任务处理之后要回复ACK，否则后果很严重。当Consumer退出时，Message会重新分发。然后RabbitMQ会占用越来越多的内存，由于RabbitMQ会长时间运行，可能导致“内存泄漏”。

在Job的调度这块支持多种算法，除了round robin机制还有Fair dispatch 公平分发机制，通过 basic.qos 方法设置prefetch_count=1 。这样RabbitMQ就会使得每个Consumer在同一个时间点最多处理一个Message。换句话说，在接收到该Consumer的ack前，他它不会将新的Message分发给它。

new_task.py script:

#!/usr/bin/env python  import pika  import sys  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.queue_declare(queue='task_queue', durable=True)  message = ' '.join(sys.argv[1:]) or "Hello World!"  channel.basic_publish(exchange='',                        routing_key='task_queue',                        body=message,                        properties=pika.BasicProperties(                           delivery_mode = 2, # make message persistent                        ))  print " [x] Sent %r" % (message,)  connection.close()  

worker.py script:

#!/usr/bin/env python  import pika  import time  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.queue_declare(queue='task_queue', durable=True)  print ' [*] Waiting for messages. To exit press CTRL+C'  def callback(ch, method, properties, body):      print " [x] Received %r" % (body,)      time.sleep( body.count('.') )      print " [x] Done"      ch.basic_ack(delivery_tag = method.delivery_tag)  channel.basic_qos(prefetch_count=1)  channel.basic_consume(callback,                        queue='task_queue')  channel.start_consuming() 

场景3：Pub-Sub
使用场景：发布、订阅模式，发送端发送广播消息，多个接收端接收。这个场景应用空间很广阔，尤其是在大型软件内部的子系统之间的消息传递。不过和前两者在使用上不同的是这里需要用到Exchange，类似于一个Router把消息转发到消费者Binding的消息队列上。

emit_log.py script:

#!/usr/bin/env python  import pika  import sys  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.exchange_declare(exchange='logs',                           type='fanout')  message = ' '.join(sys.argv[1:]) or "info: Hello World!"  channel.basic_publish(exchange='logs',                        routing_key='',                        body=message)  print " [x] Sent %r" % (message,)  connection.close()  

还有一点要注意的是我们声明了exchange。publish到一个不存在的exchange是被禁止的。如果没有queue bindings exchange的话，log是被丢弃的。
Consumer：receive_logs.py:

#!/usr/bin/env python  import pika  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.exchange_declare(exchange='logs',                           type='fanout')  result = channel.queue_declare(exclusive=True)  queue_name = result.method.queue  channel.queue_bind(exchange='logs',                     queue=queue_name)  print ' [*] Waiting for logs. To exit press CTRL+C'  def callback(ch, method, properties, body):      print " [x] %r" % (body,)  channel.basic_consume(callback,                        queue=queue_name,                        no_ack=True)  channel.start_consuming()  

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

1. Direct exchange
   Direct exchange的路由算法非常简单：通过binding key的完全匹配，可以通过下图来说明。
   
   exchange X和两个queue绑定在一起。Q1的binding key是orange。Q2的binding key是black和green。
   当P publish key是orange时，exchange会把它放到Q1。如果是black或者green那么就会到Q2。其余的Message都会被丢弃。

2. Multiple bindings
   多个queue绑定同一个key是可以的。对于下图的例子，Q1和Q2都绑定了black。也就是说，对于routing key是black的Message，会被deliver到Q1和Q2。其余的Message都会被丢弃。
   

最终代码：

The code for emit_log_direct.py:

#!/usr/bin/env python  import pika  import sys  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.exchange_declare(exchange='direct_logs',                           type='direct')  severity = sys.argv[1] if len(sys.argv) > 1 else 'info'  message = ' '.join(sys.argv[2:]) or 'Hello World!'  channel.basic_publish(exchange='direct_logs',                        routing_key=severity,                        body=message)  print " [x] Sent %r:%r" % (severity, message)  connection.close() 

The code for receive_logs_direct.py:

#!/usr/bin/env python  import pika  import sys  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.exchange_declare(exchange='direct_logs',                           type='direct')  result = channel.queue_declare(exclusive=True)  queue_name = result.method.queue  severities = sys.argv[1:]  if not severities:      print >> sys.stderr, "Usage: %s [info] [warning] [error]" % \                           (sys.argv[0],)      sys.exit(1)  for severity in severities:      channel.queue_bind(exchange='direct_logs',                         queue=queue_name,                         routing_key=severity)  print ' [*] Waiting for logs. To exit press CTRL+C'  def callback(ch, method, properties, body):      print " [x] %r:%r" % (method.routing_key, body,)  channel.basic_consume(callback,                        queue=queue_name,                        no_ack=True)  channel.start_consuming()  

场景5：使用主题Topic进行消息分发
在上文中，我们实现了一个简单的日志系统。Consumer可以监听不同severity的log。但是，这也是它之所以叫做简单日志系统的原因，因为是仅仅能够通过severity设定。不支持更多的标准。

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

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

现在我们要refine我们上篇的日志系统。routing keys 有两个部分: “.”。

The code for emit_log_topic.py:

#!/usr/bin/env python  import pika  import sys  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.exchange_declare(exchange='topic_logs',                           type='topic')  routing_key = sys.argv[1] if len(sys.argv) > 1 else 'anonymous.info'  message = ' '.join(sys.argv[2:]) or 'Hello World!'  channel.basic_publish(exchange='topic_logs',                        routing_key=routing_key,                        body=message)  print " [x] Sent %r:%r" % (routing_key, message)  connection.close()  

The code for receive_logs_topic.py:

#!/usr/bin/env python  import pika  import sys  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.exchange_declare(exchange='topic_logs',                           type='topic')  result = channel.queue_declare(exclusive=True)  queue_name = result.method.queue  binding_keys = sys.argv[1:]  if not binding_keys:      print >> sys.stderr, "Usage: %s [binding_key]..." % (sys.argv[0],)      sys.exit(1)  for binding_key in binding_keys:      channel.queue_bind(exchange='topic_logs',                         queue=queue_name,                         routing_key=binding_key)  print ' [*] Waiting for logs. To exit press CTRL+C'  def callback(ch, method, properties, body):      print " [x] %r:%r" % (method.routing_key, body,)  channel.basic_consume(callback,                        queue=queue_name,                        no_ack=True)  channel.start_consuming() 

场景6：适用于云计算集群的远程调用(RPC)
在云计算环境中，很多时候需要用它其他机器的计算资源，我们有可能会在接收到Message进行处理时，会把一部分计算任务分配到其他节点来完成。那么，RabbitMQ如何使用RPC呢？在本篇文章中，我们将会通过其它节点求来斐波纳契完成示例，同前几种使用场景不同，在这个场景下需要返回调用结果。

client发送请求的Message然后server返回响应结果。为了收到响应client在publish message时需要提供一个”callback“（回调）的queue地址。这又有其他问题了：收到响应后它无法确定是否是它的，因为所有的响应都写到同一个queue了。上一小节的correlation_id在这种情况下就派上用场了：对于每个request，都设置唯一的一个值，在收到响应后，通过这个值就可以判断是否是自己的响应。如果不是自己的响应，就不去处理。

AMQP 预定义了14个属性。它们中的绝大多很少会用到。以下几个是平时用的比较多的：

delivery_mode: 持久化一个Message（通过设定值为2）。其他任意值都是非持久化。请移步RabbitMQ消息队列（三）：任务分发机制
content_type: 描述mime-type 的encoding。比如设置为JSON编码：设置该property为application/json。
reply_to: 一般用来指明用于回调的queue（Commonly used to name a callback queue）。
correlation_id: 在请求中关联处理RPC响应（correlate RPC responses with requests）。
工作流程：

当客户端启动时，它创建了匿名的exclusive callback queue.
- 客户端的RPC请求时将同时设置两个properties： reply_to设置为callback queue；correlation_id设置为每个request一个独一无二的值.
- 请求将被发送到an rpc_queue queue.
- RPC端或者说server一直在等待那个queue的请求。当请求到达时，它将通过在reply_to指定的queue回复一个message给client。
- client一直等待callback queue的数据。当message到达时，它将检查correlation_id的值，如果值和它request发送时的一致那么就将返回响应。

The code for rpc_client.py:

#!/usr/bin/env python  import pika  import uuid  class FibonacciRpcClient(object):      def __init__(self):          self.connection = pika.BlockingConnection(pika.ConnectionParameters(                  host='localhost'))          self.channel = self.connection.channel()          result = self.channel.queue_declare(exclusive=True)          self.callback_queue = result.method.queue          self.channel.basic_consume(self.on_response, no_ack=True,                                     queue=self.callback_queue)      def on_response(self, ch, method, props, body):          if self.corr_id == props.correlation_id:              self.response = body      def call(self, n):          self.response = None          self.corr_id = str(uuid.uuid4())          self.channel.basic_publish(exchange='',                                     routing_key='rpc_queue',                                     properties=pika.BasicProperties(                                           reply_to = self.callback_queue,                                           correlation_id = self.corr_id,                                           ),                                     body=str(n))          while self.response is None:              self.connection.process_data_events()          return int(self.response)  fibonacci_rpc = FibonacciRpcClient()  print " [x] Requesting fib(30)"  response = fibonacci_rpc.call(30)  print " [.] Got %r" % (response,) 

The code for rpc_server.py:

#!/usr/bin/env python  import pika  connection = pika.BlockingConnection(pika.ConnectionParameters(          host='localhost'))  channel = connection.channel()  channel.queue_declare(queue='rpc_queue')  def fib(n):      if n == 0:          return 0      elif n == 1:          return 1      else:          return fib(n-1) + fib(n-2)  def on_request(ch, method, props, body):      n = int(body)      print " [.] fib(%s)"  % (n,)      response = fib(n)      ch.basic_publish(exchange='',                       routing_key=props.reply_to,                       properties=pika.BasicProperties(correlation_id = \                                                       props.correlation_id),                       body=str(response))      ch.basic_ack(delivery_tag = method.delivery_tag)  channel.basic_qos(prefetch_count=1)  channel.basic_consume(on_request, queue='rpc_queue')  print " [x] Awaiting RPC requests"  channel.start_consuming()  

场景7：消息队列的小伙伴: ProtoBuf（Google Protocol Buffer）
ProtoBuf是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python 三种语言的 API。

RabbitMQ支持使用不同的序列化工具来进行编码，ProtoBuf和XML, Json相较而言是目前市面上性能最好的。

Publisher的消息确认机制

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

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

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

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

事务机制 VS Publisher Confirm
如果采用标准的 AMQP 协议，则唯一能够保证消息不会丢失的方式是利用事务机制 – 令 channel 处于 transactional 模式、向其 publish 消息、执行 commit 动作。在这种方式下，事务机制会带来大量的多余开销，并会导致吞吐量下降 250% 。为了补救事务带来的问题，引入了 confirmation 机制（即 Publisher Confirm）。

为了使能 confirm 机制，client 首先要发送 confirm.select 方法帧。取决于是否设置了 no-wait 属性，broker 会相应的判定是否以 confirm.select-ok 进行应答。一旦在 channel 上使用 confirm.select方法，channel 就将处于 confirm 模式。处于 transactional 模式的 channel 不能再被设置成 confirm 模式，反之亦然。

一旦 channel 处于 confirm 模式，broker 和 client 都将启动消息计数（以 confirm.select 为基础从 1 开始计数）。broker 会在处理完消息后，在当前 channel 上通过发送 basic.ack 的方式对其进行 confirm 。delivery-tag 域的值标识了被 confirm 消息的序列号。broker 也可以通过设置 basic.ack 中的 multiple 域来表明到指定序列号为止的所有消息都已被 broker 正确的处理了。

在异常情况中，broker 将无法成功处理相应的消息，此时 broker 将发送 basic.nack 来代替 basic.ack 。在这个情形下，basic.nack 中各域值的含义与 basic.ack 中相应各域含义是相同的，同时 requeue 域的值应该被忽略。通过 nack 一或多条消息，broker 表明自身无法对相应消息完成处理，并拒绝为这些消息的处理负责。在这种情况下，client 可以选择将消息 re-publish 。

在 channel 被设置成 confirm 模式之后，所有被 publish 的后续消息都将被 confirm（即 ack） 或者被 nack 一次。但是没有对消息被 confirm 的快慢做任何保证，并且同一条消息不会既被 confirm 又被 nack 。

参考资料：
http://blog.csdn.net/column/details/rabbitmq.html
http://www.cnblogs.com/luxiaoxun/p/3918054.html