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调用;
图示:
详解:
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 异常时会导致消息丢失。