消息隊列的使用場景
消息隊列的做用主要有三個解耦、異步、削峯sql
解耦
B,C,D 系統須要使用 A 系統產生的關鍵數據。 無消息隊列時系統 A 爲系統 B、C、D 等提供各自的接口，致使系統 A 與它們緊密耦合添加系統 E 又須要接口，刪除 B 系統原接口又沒用了 有消息隊列時系統 A 做爲生產者，將消息發送到消息隊列系統 B、C、D 做爲消費者訂閱消息新增消費者只需訂閱消息，對原系統和業務沒有影響
異步
用戶請求數據時，系統的響應時間是保證用戶體驗很重要的一部分。 無消息隊列時用戶請求 A 系統，A 系統須要等待 BCD 執行完成以後響應用戶收到響應用時近 1 秒 用消息隊列時用戶請求 A 系統，A 系統將請求推到消息隊列中，B、C、D 異步執行用戶收到響應用時 200 毫秒
肖鋒
秒殺場景下，每秒有 5000 個請求，Mysql 每秒最大處理 2000 條 sql。 無消息隊列時用戶請求數據直接寫入數據庫，高併發時數據庫壓力劇增，甚至奔潰Mysql 宕機，整個系統都不能用了 有消息隊列時系統 B、C、D用戶請求數據先存入 MQ 中系統 A 每秒讀取 2000 條數據進行處理每秒多出 3000 條未處理數據按場景稍後處理
消息隊列有什麼缺點
系統可用性下降數據庫
- 系統引入的外部依賴越多，宕機的可能性就越大
- 系統引入消息隊列，就要考慮消息隊列的可靠性
- 好比本來只須要考慮 A,B,C,D 四個系統
- 引入消息隊列以後就須要考慮 A,B,C,D 四個系統外加消息隊列
系統複雜度提升併發
- 消息重複消費問題
- 消息丟失問題
- 消息傳遞順序問題
一致性問題異步
- A 系統處理完返回成功，即認爲請求成功
- 可是也存在 BC 系統寫入成功，而 D 系統寫入失敗的狀況
- 這樣的狀況就是數據不一致