RabbitMQ 02 使用場景

RabbitMQ 使用場景

服務解耦

1.假設有這樣一個場景, 服務A產生數據, 而服務B,C,D須要這些數據, 那麼咱們能夠在A服務中直接調用B,C,D服務,把數據傳遞到下游服務便可

可是,隨着咱們的應用規模不斷擴大,會有更多的服務須要A的數據,若是有幾十甚至幾百個下游服務,並且會不斷變動,再加上還要考慮下游服務出錯的狀況,那麼A服務中調用代碼的維護會極爲困難

這是因爲服務之間耦合度過於緊密

2.再來考慮用RabbitMQ解耦的狀況

A服務只須要向消息服務器發送消息,而不用考慮誰須要這些數據;下游服務若是須要數據,自行從消息服務器訂閱消息,再也不須要數據時則取消訂閱便可

流量削峯

1.假設咱們有一個應用,平時訪問量是每秒300請求,咱們用一臺服務器便可輕鬆應對

而在高峯期,訪問量瞬間翻了十倍,達到每秒3000次請求,那麼單臺服務器確定沒法應對,這時咱們能夠考慮增長到10臺服務器,來分散訪問壓力

但若是這種瞬時高峯的狀況天天只出現一次,每次只有半小時,那麼咱們10臺服務器在多數時間都只分擔每秒幾十次請求,這樣就有點浪費資源了

2.這種狀況,咱們就可使用RabbitMQ來進行流量削峯,高峯狀況下,瞬間出現的大量請求數據,先發送到消息隊列服務器,排隊等待被處理,而咱們的應用,能夠慢慢的從消息隊列接收請求數據進行處理,這樣把數據處理時間拉長,以減輕瞬時壓力

這是消息隊列服務器很是典型的應用場景

異步調用

考慮定外賣支付成功的狀況

支付後要發送支付成功的通知,再尋找外賣小哥來進行配送,而尋找外賣小哥的過程很是耗時,尤爲是高峯期,可能要等待幾十秒甚至更長

這樣就形成整條調用鏈路響應很是緩慢

而若是咱們引入RabbitMQ消息隊列,訂單數據能夠發送到消息隊列服務器,那麼調用鏈路也就能夠到此結束,訂單系統則能夠當即獲得響應,整條鏈路的響應時間只有200毫秒左右

尋找外賣小哥的應用能夠以異步的方式從消息隊列接收訂單消息,再執行耗時的尋找操做