摘要：在發送后端監聽聲明的排他隊列，當收到消息后比對正確則處理消息斷開監聽連接，然后此隊列被系統自動回收。并且通過也看到了這條消息的返回。此時我們基本已經將問題鎖定在端了。

公司的一個項目使用rabbitmq作為broker進行交互，并且數據的查詢方法使用RPC模式，RPC Client端使用java編寫并使用springAMQP包與rabbitmq交互，在RPC Server端使用python的 pika包與rabbitmq交互。兩端都使用標準官方例程，發現在Client端發送的消息可以被Server端接收并處理然后返回結果，但是Client端只會會收到一個null值。

傳統模式下 Client端向一個指定的隊列里推送消息，并聲明一個一次性排他隊列，然后將發送消息頭部的reply-to屬性的值設置為隊列的名字，correlation_id屬性設置為一個隨機生成的值用于消息鑒定然后發送消息。在發送后Client端監聽聲明的排他隊列，當收到消息后比對correaltiion_id,正確則處理消息斷開監聽連接，然后此隊列被系統自動回收。 在Server端收到消息后處理消息然后將消息返回，返回的消息的routing-key設置為reply-to的值，properties中設置correlation_id為收到的correlation_id值。這樣就完成一次RPC交互模式。
要解決今天這個問題我們還要知道幾個知識點：

1當消息發送到exchange后如果沒有隊列接收此消息，那么此消息就會丟失。

2 一次性的排他隊列在Client不在監聽此隊列就會自動被rabbitmq刪除。

因為我是使用python寫RPC Server端并且我也不怎么會java代碼。……
所以這個null值從那里來我就無法從Client端下手。那我們只能從Server端進行排查。（最后我認為是在java代碼編寫錯誤（是自己的代碼）的情況下 springAMQP返回的一個默認值）

在Server端打印收到的message并打印此消息的header信息和body信息，看到在reply-to中就是Client端設置的隊列。并且通過rabbitmq也看到了這條消息的返回。

然后我在Server端收到消息后的callback函數的頭部大了斷點，接收到消息后Server端程序掛起。此時我去查看reply-to中的隊列，發現其已經不存在于rabbitmq中了。 由上面的傳統RPC模式我推斷出 可能是Client端發送代碼后沒有監聽reply-to隊列造成隊列消失，然后Server端發送的消息因為沒有接收隊列而被丟棄。此時我們基本已經將問題鎖定在Client端了。但是Client端的代碼是按照rabbitmq官方給的例程書寫，應該是沒有問題的。此時似乎陷入了僵局。

這時候我Google一下SpringAMQP框架的是如何寫RPC代碼？在一些帖子中我發現有的代碼會添加一個Listener的類，但有的又不添加。我們假設他們都是可以運行的。那么是什么原因會造成這種情況呢？我第一個就是想到了版本問題。隨著版本的改變可能代碼也會發生變化。之后我就在SpringAMQP的官方文檔里面進行查找。果然被我找到了，官方文檔里面有這樣一段描述：

Starting with?version 3.4.0, the RabbitMQ server now supports?Direct reply-to; 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 configured.

springAMQP官方地址
翻譯一下大體意思就是在RabbitMQ3.4.0版本以后官方提供一種叫做Direct reply-to的方式來實現RPC（這種方式可以極大的提高RPC的性能，因為他不需要每次請求Client端都要新申請一個隊列，之后我會再寫一篇來詳細介紹（翻譯 o(∩_∩)o 哈哈 ）這個特性。并且在SpringAMQP version 1.4.1版本之后默認使用特性，看了一下服務器上的rabbitmq版本3.3.0 這個真的老果然不支持，SpringAMQP的版本果然也是高于這個版本，問題找到。開心 ， 但是怎么解決呢？
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


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)
        # 監聽隊列為 amp.rabbitmq.reply-to 啟動no_ack 模式
        self.channel.basic_consume(self.on_response,
                                   queue="amq.rabbitmq.reply-to",
                                   no_ack=True)

    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,
                                         # 更改了隊列名字
                                         reply_to="amq.rabbitmq.reply-to",
                                         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)

Server端代碼 沒有改動

#!/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()

這個辦法因為我不是寫java的所以我只能寫一些我在官方文檔里面理解的東西了。就是當你不使用SpringAMQP的默認RPC模式的化需要增加Listener對象來監聽自己的隊列。

RabbitTemplate rabbitTempete=new RabbitTemplate(connectionFactory);  
            rabbitTempete.setExchange(exchangeName);  
            rabbitTempete.setRoutingKey(topic);  
           //比官方文檔多的
            Queue  replyqQueue=replyQueue();  
            admin.declareQueue(replyqQueue); 
            rabbitTempete.setReplyQueue(replyqQueue);  
            SimpleMessageListenerContainer container = new SimpleMessageListenerContainer();  
            container.setConnectionFactory(connectionFactory);  
            container.setQueues(replyqQueue);  
            container.setMessageListener(rabbitTempete);  
            container.start();  
            //比官方文檔多的停止
            Object  response=rabbitTempete.convertSendAndReceive(t);  

SpringAMQP書寫官方文檔
相比較要自己申請隊列自己監聽。不過我也沒試過這段代碼就不知道能不能用了。

這個問題基本得到很好的解決了。解決一個問題首先你要明白一個東西正常情況下是一種什么狀況，然后出了問題就從前往后，從后往前，從中往兩邊等等等。然后Google，或者官方文檔，官方論壇。我個人認為官方文檔真的是好東西。無數的淺坑的解決辦法都在官方文檔。當然深坑就不說了那就是論壇加能力加運氣才能排查出來的了。不過官方大多都是英文。真是愁人，我 加強英語能力吧。