RabbitMQ消息中間件在工做中的應用場景

  RabbitMQ（消息中間件）在工做中的應用場景有以下幾種：

  一、跨系統的異步通訊，全部須要異步交互的地方均可以使用消息隊列。就像咱們除了打電話（同步）之外，還須要發短信，發電子郵件（異步）的通信方式。

      2、多個應用之間的耦合，因爲消息是平臺無關和語言無關的，並且語義上也再也不是函數調用，所以更適合做爲多個應用之間的鬆耦合的接口。基於消息隊列的耦合，不須要發送方和接收方同時在線。在企業應用集成（EAI）中，文件傳輸，共享數據庫，消息隊列，遠程過程調用均可以做爲集成的方法。

      3、應用內的同步變異步，好比訂單處理，就能夠由前端應用將訂單信息放到隊列，後端應用從隊列裏依次得到消息處理，高峯時的大量訂單能夠積壓在隊列裏慢慢處理掉。因爲同步一般意味着阻塞，而大量線程的阻塞會下降計算機的性能。

      4、消息驅動的架構（EDA），系統分解爲消息隊列，和消息製造者和消息消費者，一個處理流程能夠根據須要拆成多個階段（Stage），階段之間用隊列鏈接起來，前一個階段處理的結果放入隊列，後一個階段從隊列中獲取消息繼續處理。

      5、應用須要更靈活的耦合方式，如發佈訂閱，好比能夠指定路由規則。

      6、跨局域網，甚至跨城市的通信（CDN行業），好比北京機房與廣州機房的應用程序的通訊。

       這裏還有一種狀況，同時有大量用戶註冊你的軟件，再高併發狀況下注冊請求開始出現一些問題，例如郵件接口承受不住，或是分析信息時的大量計算使cpu滿載，這將會出現雖然用戶數據記錄很快的添加到數據庫中了，可是卻卡在發郵件或分析信息時的狀況，致使請求的響應時間大幅增加，甚至出現超時，這就有點不划算了。面對這種狀況通常也是將這些操做放入消息隊列（生產者消費者模型），消息隊列慢慢的進行處理，同時能夠很快的完成註冊請求，不會影響用戶使用其餘功能。因此在軟件的正常功能開發中，並不須要去刻意的尋找消息隊列的使用場景，而是當出現性能瓶頸時，去查看業務邏輯是否存在能夠異步處理的耗時操做，若是存在的話即可以引入消息隊列來解決。不然盲目的使用消息隊列可能會增長維護和開發的成本卻沒法獲得可觀的性能提高，那就得不償失了。（轉載自知乎）