1. 消息隊列
1.1 優缺點
優點/使用場景：
- 解耦。生產消息後直接給MQ，不用關心其他事務，監聽返回消息就行。
- 異步。異步執行，提高吞吐量。發送者將消息給MQ後，不需要同步等待處理完畢，而是可以進行其它操作。
- 削峯。請求放在MQ裏，Server根據處理能力處理消息，緩解服務器壓力，不至於GG。
缺點：
- 系統可用性降低。MQ掛了，整個系統通信GG。
- 系統複雜度增加。加入MQ，引出一致性、傳輸可靠性、消息不被重複消費等等問題。
- 數據一致性問題。A處理結束返回，BC寫庫成功，D失敗，數據不一致。
1.2 消息中間件
答：主要是ActiveMQ、RabbitMQ、RocketMQ和KafKa。
- ActiveMQ：老技術，現在用得不多。主從架構。
- RabbitMQ：開源，中小型用這個。主從架構。
- RocketMQ：阿里開發，和Dubbo RPC框架很像。分佈式架構。
- Kafaka：專門做大數據。分佈式架構。
1.3 常見問題
1.3.1 重複消費
因爲網絡問題導致Customer收到兩條一樣的消息，或者是消費模塊處理失敗請求重發消息。
解決方法
保證冪等性，即不管多少重複消息，最後處理結果還是一樣。分爲強校驗和弱檢驗。
- 強校驗：把多個流程放在一個事務，成功一起成功失敗一起失敗。通過唯一編號標識消息或者日誌表記錄去重。
- 弱檢驗：不重要的場景就用 id + 場景號放在redis中，有效時間內用redis判斷。
1.3.2 順序消費
因爲延遲等原因，使得消息消費順序和發送順序不同。
解決方法
- 保證生產者-MQ-消費者，一一對應，消費成功一個再發下一個。
- 缺陷問題：吞吐量不夠；耦合度太高。從業務層面保證消息順序。
1.4 分佈式事務
1.4.1 兩段式提交
答：2pc兩段式提交，最基礎的模型。通過消息中間件協調多個系統，等每個系統事務都鎖定了資源，通知中間件，中間件按順序通知系統提交事務。
- 缺陷：A事務提交成功，B事務提交失敗導致B事務一直鎖定資源。
1.4.2 最終一致性
- 業務主動方本地事務提交失敗，被動接收方不會收到消息的投遞；
- 只要業務主動方本地事務執行成功，那麼消息服務一定會投遞消息給下游的業務被動方，並最終保證業務被動方一定能成功消費該消息(消費成功或失敗，即最終一定會有一個最終態)。