rabbitMQ學習筆記(八)——應用場景

MQ的應用場景

1 異步處理

場景說明：用戶註冊後，需要發註冊郵件和註冊短信,傳統的做法有兩種 1.串行的方式 2.並行的方式

• 串行方式: 將註冊信息寫入數據庫後,發送註冊郵件,再發送註冊短信,以上三個任務全部完成後才返回給客戶端。 這有一個問題是,郵件,短信並不是必須的,它只是一個通知,而這種做法讓客戶端等待沒有必要等待的東西.

• 並行方式:將註冊信息寫入數據庫後,發送郵件的同時,發送短信,以上三個任務完成後,返回給客戶端,並行的方式能提高處理的時間。
  

• 消息隊列:假設三個業務節點分別使用50ms,串行方式使用時間150ms,並行使用時間100ms。雖然並行已經提高的處理時間,但是,前面說過,郵件和短信對我正常的使用網站沒有任何影響，客戶端沒有必要等着其發送完成才顯示註冊成功,應該是寫入數據庫後就返回. 消息隊列: 引入消息隊列後，把發送郵件,短信不是必須的業務邏輯異步處理

由此可以看出,引入消息隊列後，用戶的響應時間就等於寫入數據庫的時間+寫入消息隊列的時間(可以忽略不計),引入消息隊列後處理後,響應時間是串行的3倍,是並行的2倍。

2 應用解耦

場景：雙11是購物狂節,用戶下單後,訂單系統需要通知庫存系統,傳統的做法就是訂單系統調用庫存系統的接口.

這種做法有一個缺點:

當庫存系統出現故障時,訂單就會失敗。 訂單系統和庫存系統高耦合. 引入消息隊列

• 訂單系統:用戶下單後,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功。

• 庫存系統:訂閱下單的消息,獲取下單消息,進行庫操作。 就算庫存系統出現故障,消息隊列也能保證消息的可靠投遞,不會導致消息丟失.

3 流量削峯

場景: 秒殺活動，一般會因爲流量過大，導致應用掛掉,爲了解決這個問題，一般在應用前端加入消息隊列。

作用:

​ 1.可以控制活動人數，超過此一定閥值的訂單直接丟棄(我爲什麼秒殺一次都沒有成功過呢^^)

​ 2.可以緩解短時間的高流量壓垮應用(應用程序按自己的最大處理能力獲取訂單)

1.用戶的請求,服務器收到之後,首先寫入消息隊列,加入消息隊列長度超過最大值,則直接拋棄用戶請求或跳轉到錯誤頁面.

2.秒殺業務根據消息隊列中的請求信息，再做後續處理.