一、RabbitMQ的基本概念
RabbitMQ是一種消息中間件，用於處理來自客戶端的異步消息。服務端將要發送的消息放入到隊列池中。接收端能夠根據RabbitMQ配置的轉發機制接收服務端發來的消息。RabbitMQ依據指定的轉發規則進行消息的轉發、緩衝和持久化操做，主要用在多服務器間或單服務器的子系統間進行通訊，是分佈式系統標準的配置。服務器
Exchange
接受生產者發送的消息，並根據Binding規則將消息路由給服務器中的隊列。ExchangeType決定了Exchange路由消息的行爲。在RabbitMQ中，ExchangeType經常使用的有direct、Fanout和Topic三種。
異步
Message Queue
消息隊列。咱們發送給RabbitMQ的消息最後都會到達各類queue，而且存儲在其中(若是路由找不到相應的queue則數據會丟失)，等待消費者來取。分佈式
Binding Key
它表示的是Exchange與Message Queue是經過binding key進行聯繫的，這個關係是固定。學習
Routing Key
生產者在將消息發送給Exchange的時候，通常會指定一個routing key，來指定這個消息的路由規則。這個routing key須要與Exchange Type及binding key聯合使用才能生，咱們的生產者只須要經過指定routing key來決定消息流向哪裏。.net
二、RabbitMQ 使用場景
服務解耦
假設有這樣一個場景, 服務A產生數據, 而服務B,C,D須要這些數據, 那麼咱們能夠在A服務中直接調用B,C,D服務,把數據傳遞到下游服務便可。3d
可是,隨着咱們的應用規模不斷擴大,會有更多的服務須要A的數據,若是有幾十甚至幾百個下游服務,並且會不斷變動,再加上還要考慮下游服務出錯的狀況,那麼A服務中調用代碼的維護會極爲困難。中間件
這是因爲服務之間耦合度過於緊密。blog
再來考慮用RabbitMQ解耦的狀況。隊列
A服務只須要向消息服務器發送消息,而不用考慮誰須要這些數據;下游服務若是須要數據,自行從消息服務器訂閱消息,再也不須要數據時則取消訂閱便可。資源
流量削峯
假設咱們有一個應用,平時訪問量是每秒300請求,咱們用一臺服務器便可輕鬆應對。
而在高峯期,訪問量瞬間翻了十倍,達到每秒3000次請求,那麼單臺服務器確定沒法應對,這時咱們能夠考慮增長到10臺服務器,來分散訪問壓力。
但若是這種瞬時高峯的狀況天天只出現一次,每次只有半小時,那麼咱們10臺服務器在多數時間都只分擔每秒幾十次請求,這樣就有點浪費資源了。
這種狀況,咱們就可使用RabbitMQ來進行流量削峯,高峯狀況下,瞬間出現的大量請求數據,先發送到消息隊列服務器,排隊等待被處理,而咱們的應用,能夠慢慢的從消息隊列接收請求數據進行處理,這樣把數據處理時間拉長,以減輕瞬時壓力。
這是消息隊列服務器很是典型的應用場景。
異步調用
考慮定外賣支付成功的狀況。
支付後要發送支付成功的通知,再尋找外賣小哥來進行配送,而尋找外賣小哥的過程很是耗時,尤爲是高峯期,可能要等待幾十秒甚至更長。
這樣就形成整條調用鏈路響應很是緩慢。
而若是咱們引入RabbitMQ消息隊列,訂單數據能夠發送到消息隊列服務器,那麼調用鏈路也就能夠到此結束,訂單系統則能夠當即獲得響應,整條鏈路的響應時間只有200毫秒左右。
尋找外賣小哥的應用能夠以異步的方式從消息隊列接收訂單消息,再執行耗時的尋找操做。
上一篇：RabbitMQ學習：安裝RabbitMQ及RabbitMQ的初步配置(一) --- http://www.javashuo.com/article/p-puxmjike-nw.html
下一篇：RabbitMQ學習：RabbitMQ的六種工做模式之簡單和工做模式(三) --- http://www.javashuo.com/article/p-pldmjukv-nw.html