訊息佇列中介軟體（MQ）可以說是大型分散式系統中必備的一個元件，它的一個重要的功能就是實現架構上的解耦。目前市面上存在的比較常見的有RabbitMQ、ZeroMQ、ActiveMQ和Kafka等，他們各有各自的優缺點，這裡不作詳細介紹，有興趣的可以結合不同的應用去做實際的對比分析，本文以RabbitMQ為例子來作介紹。
RabbitMQ是基於AMQP協議的一個開源實現，Server端用Erlang語言編寫，支援C、Java、Python、PHP、Ruby等常見語言。它除了具備優異的效能之外，更重要的一點是支援訊息的持久化，訊息的可靠性可以得到相應的保障。
一、安裝過程
簡單附上一個CentOS系統下的安裝教程。
安裝依賴
安裝RabbitMQ
安裝過程還是比較簡單的，完成之後需要檢查防火牆對應的埠是否可用。
二、應用場景
1.削峰降流
這個很好理解，比如秒殺活動中，我們就經常用到訊息佇列來防止後臺服務掛掉，同時也解決一部分併發的問題。
2.非同步處理
假如使用者註冊成功時需要發註冊郵件，傳統的做法是以序列的方式進行，使用者資訊入庫成功後傳送郵件，這種方式嚴重影響服務端的響應時間。
引入訊息中介軟體之後，註冊成功與否不再受到郵件服務的影響，服務端響應時間也明顯縮短，這種方式幾乎是所有高併發應用所採取的一種策略。
3.架構解耦
例如淘寶雙11購物節使用者下單時訂單系統使用通知庫存系統、使用者發帖時圖片鑑定等場景，這裡我們以發帖為例。
傳統的做法是帖子入庫之後呼叫各種RPC服務（積分RPC介面、圖片鑑定RPC介面、資料分析RPC）。
這裡就存在一些坑在這裡了，當有新的業務要接入的時候，發帖服務就需要跟著做調整；或者某個RPC服務做了修改，發帖服務可能就會受到影響。服務之間存在嚴重的耦合，負責這塊服務的人估計會很難過。
怎麼解決以上的坑呢？我們只要引入一個訊息中介軟體就可以解決以上的問題，結構變為這樣：
發帖服務只需要跟訊息中介軟體打交道，其他服務方也只需要訂閱訊息就可以了，各個服務之間的關係就不用再糾纏不清了。
小結
如果呼叫鏈上下文不存在強依賴關係，使用訊息中介軟體不失為一種合理的選擇。
