返回首页 | 申博娱乐APP下载

合作共赢、快速高效、优质的网站建设提供商

更多精品源码-尽在织梦模板-www.moke8.com

[编码]rabbitmq direct reply

时间:2017-07-31 编辑:admin

公司的一个项目使用rabbitmq作为broker进行交互,并且数据的查询方法使用RPC模式,RPC Client端使用java编写并使用springAMQP包与rabbitmq交互,在RPC Server端使用python的 pika包与rabbitmq交互。两端都使用标准官方例程,发现在Client端发送的消息可以被Server端接收并处理然后返回结果,但是Client端只会会收到一个null值。

1 理解传统的RPC模式运行流程

传统模式下 Client端向一个指定的队列里推送消息,并声明一个一次性排他队列,然后将发送消息头部的reply-to属性的值设置为队列的名字,correlation_id属性设置为一个随机生成的值用于消息鉴定然后发送消息。在发送后Client端监听声明的排他队列,当收到消息后比对correaltiion_id,正确则处理消息断开监听连接,然后此队列被系统自动回收。 在Server端收到消息后处理消息然后将消息返回,返回的消息的routing-key设置为reply-to的值,properties中设置correlation_id为收到的correlation_id值。这样就完成一次RPC交互模式。
要解决今天这个问题我们还要知道几个知识点:

1当消息发送到exchange后如果没有队列接收此消息,那么此消息就会丢失。 2 一次性的排他队列在Client不在监听此队列就会自动被rabbitmq删除。 排查1 Client端收到的Null值从哪里来?

因为我是使用python写RPC Server端并且我也不怎么会java代码。……
所以这个null值从那里来我就无法从Client端下手。那我们只能从Server端进行排查。(最后我认为是在java代码编写错误(是自己的代码)的情况下 springAMQP返回的一个默认值)

排查2 Server端收到消息后是否正确的将消息返回

在Server端打印收到的message并打印此消息的header信息和body信息,看到在reply-to中就是Client端设置的队列。并且通过rabbitmq也看到了这条消息的返回。

排查3 观察消息有没有被推送回reply-to队列

然后我在Server端收到消息后的callback函数的头部大了断点,接收到消息后Server端程序挂起。此时我去查看reply-to中的队列,发现其已经不存在于rabbitmq中了。 由上面的传统RPC模式我推断出 可能是Client端发送代码后没有监听reply-to队列造成队列消失,然后Server端发送的消息因为没有接收队列而被丢弃。此时我们基本已经将问题锁定在Client端了。但是Client端的代码是按照rabbitmq官方给的例程书写,应该是没有问题的。此时似乎陷入了僵局。

定位问题:Google大发加官方文档

这时候我Google一下SpringAMQP框架的是如何写RPC代码?在一些帖子中我发现有的代码会添加一个Listener的类,但有的又不添加。我们假设他们都是可以运行的。那么是什么原因会造成这种情况呢?我第一个就是想到了版本问题。随着版本的改变可能代码也会发生变化。之后我就在SpringAMQP的官方文档里面进行查找。果然被我找到了,官方文档里面有这样一段描述:

Starting with?version 3.4.0, the RabbitMQ server now supports?; this eliminates the main reason for a fixed reply queue (to avoid the need to create a temporary queue for each request). Starting with?Spring AMQP version 1.4.1?Direct reply-to will be used by default (if supported by the server) instead of creating temporary reply queues. When no?replyQueue ?is provided (or it is set with the name?amq.rabbitmq.reply-to), the?RabbitTemplate?will automatically detect whether Direct reply-to is supported and either use it or fall back to using a temporary reply queue. When using Direct reply-to, a?reply-listener is not required and should not be configure**********>
翻译一下大体意思就是在RabbitMQ3.4.0版本以后官方提供一种叫做Direct reply-to的方式来实现RPC(这种方式可以极大的提高RPC的性能,因为他不需要每次请求Client端都要新申请一个队列,之后我会再写一篇来详细介绍(翻译 o(∩_∩)o 哈哈 )这个特性。并且在SpringAMQP version 1.4.1版本之后默认使用特性,看了一下服务器上的rabbitmq版本3.3.0 这个真的老果然不支持,SpringAMQP的版本果然也是高于这个版本,问题找到。开心 , 但是怎么解决呢?

一: 提升rabbitmq版本,并使两端代码适配direct reply-to 方式 难点1 python的官网没有给例程 ,不过给了介绍也告诉了如何来实现 难点2 服务器提升版本,已经有业务跑在上面了,我这种对rabbitmq的萌新对rabbitmq各版本升级后的改变并不是很了解,估计是难说动领导换了。

针对难点2 我就不想了 不过难点1的我已经写出来python如何适配direct reply-to的代码。
更改都是在Client端,Server端还是可以保持不变。主要主机这几个方面

1 reply-to的名字更改为‘amq.rabbitmq.reply-to’这条虚拟队列,你在rabbitmq的控制台上是看不到这条队列的。 2 然后Client监听这条队列的时候要设为为no-ack模式。

下面是根据官方python RPC代码更改的 适配 Direct reply-to的python代码
Client端 python代码

# -*- coding:utf-8 -*- 
#!/usr/bin/env python
import pika
import uuid

浏览:

网站建设

流程

    网站建设流程