前面的例子都有个共同点,就是发送端发送消息出去后没有结果返回。若是只是单纯发送消息,固然没有问题了,可是在实际中,经常会须要接收端将收到的消息进行处理以后,返回给发送端。python
处理方法描述:发送端在发送信息前,产生一个接收消息的临时队列,该队列用来接收返回的结果。其实在这里接收端、发送端的概念已经比较模糊了,由于发送端也一样要接收消息,接收端一样也要发送消息,因此这里笔者使用另外的示例来演示这一过程。服务器
示例内容:假设有一个控制中心和一个计算节点,控制中心会将一个天然数N发送给计算节点,计算节点将N值加1后,返回给控制中心。这里用center.py模拟控制中心,compute.py模拟计算节点。测试
compute.py代码分析fetch
1spa 2rest 3code 4server 5rabbitmq 6队列 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
计算节点的代码比较简单,值得一提的是,原来的接收方法都是直接将消息打印出来,这边进行了加一的计算,并将结果发送回控制中心。
center.py代码分析
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
|
上例代码定义了接收返回数据的队列和处理方法,而且在发送请求的时候将该队列赋值给reply_to,在计算节点代码中就是经过这个参数来获取返回队列的。
打开两个终端,一个运行代码python compute.py,另一个终端运行center.py,若是执行成功,应该就能看到效果了。
笔者在测试的时候,出了些小问题,就是在center.py发送消息时没有指明返回队列,结果compute.py那边在计算完结果要发回数据时报错,提示routing_key不存在,再次运行也报错。用rabbitmqctl list_queues查看队列,发现compute_queue队列有1条数据,每次从新运行compute.py的时候,都会从新处理这条数据。后来使用/etc/init.d/rabbitmq-server restart从新启动下rabbitmq就ok了。