Python 操作 Rabbit MQ 远程过程调用 (八)
一、远程过程调用(RPC)：
前面那些篇章，都是单向流，如果想实现，远程的机器执行完并且返回结果，这个需求前面那些篇章就无法实现了。
1.RPC概念：
RPC(Remote Procedure Call)远程过程调用，一次远程过程调用的流程是：客户端发送一个请求到服务端，服务端根据请求信息进行处理后返回响应信息，客户端收到响应信息后结束。
2.使用RabbitMQ 实现RPC：
使用RabbitMQ实现RPC，相应的角色是由生产者来作为客户端，消费者作为服务端。
PRC调用一般是同步的，客户端和服务器也是紧密耦合。
- 客户端通过IP/域名和端口连接到服务器，向服务器发送请求后等待服务器返回响应信息；
但是消息队列的生产者跟消费者是完全解耦的，那么如何用消息队列实现RPC呢？
- 就是把消息队列当作中间件，实现一次双向的消息传递；
- 客户端和服务端既是生产者也是消费者。客户端发布请求，消费响应；服务端消费请求，发布响应。
二、客户端：
为了展示RPC服务的使用，我们创建了一个简单的客户端类，它会调用一个"call"的方法用来发送一个RPC请求，并且在收到响应前保持阻塞。
fibonacci_rpc = FibonacciRpcClient()
result = fibonacci_rpc.call(6)
print "fib(4) is %r" % (result,)
三、回调队列：
上面已经介绍过，用RabbitMQ实现RPC其实蛮容易的。一个客户端发送请求信息，服务端将其应用到一个回复信息中。为了接收到回复消息，客户端需要在发送请求的时候同时发送一个回调队列(callback queue)的地址。
channel.basic_publish(exchange='',
routing_key='rpc_queue',
properties=pika.BasicProperties(
reply_to = callback_queue,
),
body=request)
AMQP协议消息常用属性：
- delivery_mode（投递模式）：将消息标记为持久的（值为2）或暂存的（除了2之外的其他任何值)。
- content_type（内容类型）:用来描述编码的mime-type。例如在实际使用中使用application/json来描述JOSN编码类型。
- reply_to（回复目标）：通常用来命名回调队列。
- correlation_id（关联标识）：用来将RPC的响应和请求关联起来。
四、关联标识：
RPC需要涉及消息两个重要属性：
- replyTo：存储回调队列的名称；
- correlationld：唯一标识本次的请求，主要用于RPC调用；
图示：
扫描二维码关注公众号，回复：
8490291 查看本文章
详解：
1.RPC客户端启动后，创建一个匿名、独立的、回调队列；
2.RPC客户端设置消息的2个属性：replyTo和correlationId，然后将消息发送到队列rpc_queue；
3.RPC服务端在队列rpc_queue上等待消息。RPC服务端处理完收到的消息后，将处理结果封装成消息发送到replayTo指定的队列上，并且此消息带上correlationId（此值为收到消息里的correlationId）。
4.RPC客户端在队列replyTo上等待消息，当收到消息后，它会判断收到消息的correlationId。如果值和自己之前发送的一样，则这个值就是RPC的处理结果。
五、代码整理：
1.本篇先整理服务端的代码rpc_server.py：
#!/usr/bin/python
# -*- coding: utf-8 -*-
import pika
# 配置连接工厂
connection = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
# 在TCP连接的基础上创建消息管道
channel = connection.channel()
# 声明一个队列名为: rpc_queue
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------{}".format(n, )
# 将数字传递到处理函数中, 并返回结果
response = fib(n)
print "[fib process result] {}".format(response)
# 将执行结果返回给客户端
ch.basic_publish(exchange='', routing_key=props.reply_to, # 客户端要求返回想用的queue
# 返回客户端发过来的correction_id 为了让客户端验证消息一致性
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)
# 在队列rpc_queue里收消息, 收到消息就调用on_request函数
channel.basic_consume(on_message_callback=on_request,
queue='rpc_queue')
# 开始消费消息
print "[X] Waiting RPC requests"
channel.start_consuming()
2.客户端代码rpc_client.py：
#!/usr/bin/python
# -*- coding: utf-8 -*-
import pika
import uuid
class FibonacciRpcClient(object):
def __init__(self):
# 创建连接
self.connection = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
# 在TCP连接的基础上创建管道
self.channel = self.connection.channel()
# 表示跟消费者断开连接后, 管道立即消除
result = self.channel.queue_declare(queue='', exclusive=True)
# 随机生成的队列名
self.callback_queue = result.method.queue
self.channel.basic_consume(on_message_callback=self.on_response,
queue=self.callback_queue, auto_ack=True)
def on_response(self, ch, method, props, body):
"""收到消息调用的函数:
注意：该处理函数必须有四个参数
"""
# 如果收到的ID和本地生成的ID相同, 则返回的结果就是我想要的指令返回结果
if self.corr_id == props.correlation_id:
self.response = body
def call(self, n):
# 初始化response = None
self.response = None
self.corr_id = str(uuid.uuid4()) # 随机生成唯一字符串
# 发送消息
self.channel.basic_publish(exchange='', # 使用默认交换机
routing_key='rpc_queue', # 将消息发送到rpc_queue队列
properties=pika.BasicProperties( # 使用消息持久化
reply_to=self.callback_queue, # 服务端回调的队列
correlation_id=self.corr_id # 把随机uuid同时发送给服务器
),
body=str(n) # 发送消息内容
)
# 如果服务器没有返回消息时, 就循环等待
while self.response is None:
# 非阻塞版的start_consuming()
# 是一个等待消息阻塞过程, 连接任何消息都可以使它脱离阻塞状态
self.connection.process_data_events()
# 收到消息就调用on_response
return int(self.response)
# 创建FibonacciRpcClient()实例
fibonacci_rpc = FibonacciRpcClient()
# 调用call方法
response = fibonacci_rpc.call(6)
print "Reponse------{}".format(response)
3.启动RPC服务器端：
python rpc_server.py
[X] Waiting RPC requests
4.启动RPC客户端，并请求一个fibonacci队列：
python rpc_client.py
Reponse------8 # 可以看到返回结果是8 (6-1) + (6-2) 服务端处理后返回给客户端
RPC服务器端的打印：
[.] fib------6
[fib process result] 8
6.总结：
- 如果RPC服务器运行的过慢的时候，可通过运行另外一个服务端扩展它
- 在客户端，PRC请求仅发送或接收一条消息。不需要像queue_declare这样异步调用。所以RPC客户端的单个请求仅需要一个网络往返。
六、pika版本不同导致问题：
以上所有版本使用的都是：pika 1.1.0，如果您使用的是pika 0.9.8，那么在basic_consume()中参数是no_ack=True，而不是auto_ack=True，这事因为版本不同，而导致参数的位置不同，需要特别的注意。
no_ack=true：自动应答
- consumer会接收到Basic.Deliver + Content-Header + Content-Body之后，立即回复Ack。而这个Ack是Tcp协议中的Ack。
no_ack=false：手动应答
- consunmer在处理完接收到的Basic.Deliver + Content-Header + Content-Body 之后才回复Ack。而这个Ack是AMQP协议中的Basic.Ack。
关于no_ack的总结：
- Basic.Ack 发回给 RabbitMQ 告知，可将相应的message从RabbitMQ的消息缓存中移除。
- Basic.Ack 没有被 Consumer发回给RabbitMQ前出现异常，RabbitMQ 发现与该Consumer对应的连接被断开，之后将该message 以轮询的发送给其他的Consumer。
- 在 no_ack=true 的情况下，RabbitMQ 认为 message 一旦被 deliver 出去了，就已被确认了，所以会立即将缓存中的 message 删除。所以在 consumer 异常时会导致消息丢失。
