1.假設有這樣乙個場景, 服務a產生資料, 而服務b,c,d需要這些資料, 那麼我們可以在a服務中直接呼叫b,c,d服務,把資料傳遞到下游服務即可
但是,隨著我們的應用規模不斷擴大,會有更多的服務需要a的資料,如果有幾十甚至幾百個下游服務,而且會不斷變更,再加上還要考慮下游服務出錯的情況,那麼a服務中呼叫**的維護會極為困難
這是由於服務之間耦合度過於緊密
2.再來考慮用rabbitmq解耦的情況
a服務只需要向訊息伺服器傳送訊息,而不用考慮誰需要這些資料;下游服務如果需要資料,自行從訊息伺服器訂閱訊息,不再需要資料時則取消訂閱即可
1.假設我們有乙個應用,平時訪問量是每秒300請求,我們用一台伺服器即可輕鬆應對
而在高峰期,訪問量瞬間翻了十倍,達到每秒3000次請求,那麼單台伺服器肯定無法應對,這時我們可以考慮增加到10臺伺服器,來分散訪問壓力
但如果這種瞬時高峰的情況每天只出現一次,每次只有半小時,那麼我們10臺伺服器在多數時間都只分擔每秒幾十次請求,這樣就有點浪費資源了
2.這種情況,我們就可以使用rabbitmq來進行流量削峰,高峰情況下,瞬間出現的大量請求資料,先傳送到訊息佇列伺服器,排隊等待被處理,而我們的應用,可以慢慢的從訊息佇列接收請求資料進行處理,這樣把資料處理時間拉長,以減輕瞬時壓力
這是訊息佇列伺服器非常典型的應用場景
考慮定外賣支付成功的情況
支付後要傳送支付成功的通知,再尋找外賣小哥來進行配送,而尋找外賣小哥的過程非常耗時,尤其是高峰期,可能要等待幾十秒甚至更長
這樣就造成整條呼叫鏈路響應非常緩慢
而如果我們引入rabbitmq訊息佇列,訂單資料可以傳送到訊息佇列伺服器,那麼呼叫鏈路也就可以到此結束,訂單系統則可以立即得到響應,整條鏈路的響應時間只有200毫秒左右
尋找外賣小哥的應用可以以非同步的方式從訊息佇列接收訂單訊息,再執行耗時的尋找操作
RabbitMQ使用場景介紹
場景說明 使用者註冊後，需要傳送郵件和註冊簡訊，傳統的方式有兩種 1 序列的方式，2 並行的方式 場景 雙十一是購物狂節，使用者下單後，訂單系統要通知庫存系統，傳統的做法就是訂單系統呼叫庫存系統的介面 這種做法有乙個缺點 當庫存系統出現故障之後，訂單系統就會失敗，訂單系統和庫存系統耦合，引入訊息佇列...
RabbitMQ 詳解以及使用場景
mq全稱為message queue,訊息佇列 mq 是一種應用程式對應用程式的通訊方法。應用程式通過讀寫出入佇列的訊息 針對應用程式的資料 來通訊，而無需專用連線來鏈結它們。訊息傳遞指的是程式之間通過在訊息中傳送資料進行通訊，而不是通過直接呼叫彼此來通訊，直接呼叫通常是用於諸如遠端過程呼叫的技術。...
RabbitMQ 簡介以及使用場景
目錄mq全稱為message queue,訊息佇列 mq 是一種應用程式對應用程式的通訊方法。應用程式通過讀寫出入佇列的訊息 針對應用程式的資料 來通訊，而無需專用連線來鏈結它們。訊息傳遞指的是程式之間通過在訊息中傳送資料進行通訊，而不是通過直接呼叫彼此來通訊，直接呼叫通常是用於諸如遠端過程呼叫的技...