1. 你們系統里為什麼要使用消息隊列？ 2. 既然使用了消息隊列，說說他還有什麼使用場景？ 3. 消息隊列的優缺點是什麼？ ...
1. 引子
消息隊列分散式系統中重要的組件，一種存放消息的容器，主要作用有解耦、非同步、削鋒，是大型分散式系統不可缺少的中間件。
常見的消息隊列有 ActiveMQ，RabbitMQ，RocketMQ，Kafka。
簡歷中涉及到了消息隊列，面試官先問了這樣幾個問題：
- 你們系統里為什麼要使用消息隊列？
- 既然使用了消息隊列，說說他還有什麼使用場景？
- 消息隊列的優缺點是什麼？
2. 為什麼使用消息隊列？
我的回答：甲方提供 EOS 充值服務，我方進行調用。出於解耦的目的，引入了消息隊列。
一個類似應試的回答方法，就是思考面試官問這個問題是出於什麼目的，想獲得的是什麼樣的答案？
當問到為什麼使用消息隊列時，面試官期望的回答是公司的 xxx 業務遇到了挑戰，不用 MQ 會有麻煩，使用 MQ 之後帶來了好處。
通過一個問題就能看出是為了用而用，還是經過思考之後使用。
3. 消息隊列的使用場景？
問消息隊列的使用場景，和問消息隊列有什麼優點，消息隊列有什麼作用是等價的。
消息隊列的作用主要有三個解耦、非同步、削峰。
解耦
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 條未處理數據按場景稍後處理
4. 消息隊列有什麼缺點？
優點前面已經說過了，還需要討論一下缺點。
為什麼要問缺點是什麼？
凡事都有兩面性，如果只是考慮到消息隊列的優點，而沒有考慮缺點，這就是一個潘多拉的魔盒。打開魔盒，接踵而來的會是一系列的意外。
推廣到引入其他技術亦然，只有考慮到缺點之後才可以採取額外的技術方案或者架構來規避這些缺點。
系統可用性降低
- 系統引入的外部依賴越多，宕機的可能性就越大
- 系統引入消息隊列，就要考慮消息隊列的可靠性
- 比如原本只需要考慮 A,B,C,D 四個系統
- 引入消息隊列之後就需要考慮 A,B,C,D 四個系統外加消息隊列
系統複雜度提高
- 消息重覆消費問題
- 消息丟失問題
- 消息傳遞順序問題
一致性問題
- A 系統處理完返回成功，即認為請求成功
- 但是也存在 BC 系統寫入成功，而 D 系統寫入失敗的情況
- 這樣的情況就是數據不一致
總結
面試官問到 MQ 的時候，希望考察我們在使用 MQ 的時候是否有過自己的思考。沒有完美的技術，任何技術都具有兩面性，要考慮它的使用場景，並且對可能遇到的風險做到心中有數，提前預防。
思考
引入消息隊列之後：
- 如何保證高可用？
- 如何避免消息的重覆消費和消息丟失？
- 如何保證消息的順序執行？
下一篇文章一起討論。
