前面的例子都有個共同點,就是發送端發送消息出去後沒有結果返回。若是隻是單純發送消息,固然沒有問題了,可是在實際中,經常會須要接收端將收到的消息進行處理以後,返回給發送端。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了。