在《大話分布式架構(二）》中我們介紹了RPC和RMI都有一個缺點就是必須是同步調用，這就導致了面向消息中間件的調用（- ，MOM）的產生。MOM的使用只需要應用程序發送一個消息給邏輯意義上的中轉者，通信中間件就會把這些消息移交給對應的程序數據接口業務邏輯圖，這種發布/訂閱系統就構成了一個重要且可擴展的分布式系統。
隨著RPC應用的場景越來越多，服務器之間消息通訊這種功能廣泛應用于這些中間件中，于是，將這種面向消息的中間件抽象出來，形成通用的消息中間件即MQ。PS：有過RPC開發經驗的同學可能會問異步RPC不是就是異步調用嗎？這里澄清一個概念：異步RPC（ RPC）是指服務端在接收到RPC請求后立即應答處理中，之后再回調客戶端的過程，這個過程中客戶端在發出RPC請求以后立即及需求執行，從下圖可以看出還是同步調用。
1.何為MQ
消息隊列（MQ）是一種不同應用程序之間(跨進程)的通信方法，用于上下游應用程序之間傳遞消息。我們拆分來看：
這樣就實現了上游與下游之間的解耦，上游向MQ發送消息，下游從MQ接收消息，上游下游互不依賴，它們只依賴MQ。因為有隊列的存在，MQ可在上下游之間進行緩沖，把上游信息先緩存起來，下游根據自己的能力從MQ中拉去信息，起到削峰的作用。
2.MQ架構
MQ的邏輯架構如下圖所示：
MQ架構設計時需要考慮的因素：
3.何時需要用MQ
當你需要使用消息隊列時，首先需要考慮它的必要性。可以使用MQ的場景有很多，最常用是業務解耦/最終一致性/廣播/錯峰流控等。反之，如果需要強一致性，關注業務邏輯的處理結果，則RPC顯得更為合適。
解耦是消息隊列要解決的最本質問題。所謂解耦，簡單點講就是一個事務，只關心核心的流程。而需要依賴其他系統但不那么重要的事情，有通知即可，無需等待結果。換句話說，基于消息的模型，關心的是“通知”，而非“處理”。
最終一致性指的是兩個系統的狀態保持一致，要么都成功，要么都失敗。實際上存在異常的情況下，可能會有一定延遲，但兩個系統最后狀態是一樣的。業界有一些為“最終一致性”而生的消息隊列，如（阿里）、QMQ（去哪兒）等，其設計初衷，就是為了交易系統中的高可靠通知。
以一個轉賬過程來理解最終一致性，轉賬的需求很簡單，如果A系統扣錢成功，則B系統加錢一定成功。反之則一起回滾，像什么都沒發生一樣。
消息隊列的基本功能之一是進行廣播。如果沒有消息隊列，每當一個新的業務方接入，我們都要聯調一次新接口。有了消息隊列，我們只需要關心消息是否送達了隊列，至于誰希望訂閱，是下游的事情，無疑極大地減少了開發和聯調的工作量。
下面以登錄場景為例來講解。
建設初期出于安全考慮我們每次用戶登錄金融APP后都要發送一條短信通知，這時通過RPC調用即可，如下圖所示：
隨著業務發展及出于安全和反欺詐考慮，建設了安全系統，需要登錄發送 登錄場景埋點數據，這個時候有兩種方案，一種是繼續使用RPC調用，如下圖所示，這時一次登錄的響應時間可能是登錄處理耗時A+短信調用時間B+安全系統調用時間C（也有可能是通過異步RPC調用：響應時間只是登錄處理耗時A多一點），除了耗時之外，還有系統的故障點也多了，如果安全系統或者短信服務宕機了數據接口業務邏輯圖，那么很大可能登錄系統會隨之宕掉（這里說很大可能是因為后面我會采用獨立一篇文章來介紹熔斷和隔離處理來規避跨系統間的調用）。
另第二種解決方案是未雨綢繆，既然現在有第二個系統需要了解事件，那么以后是不是還會有第三個、第N個呢？如下圖所示。這時登錄系統的穩定性進一步降低，復雜度急劇上升，在處理登錄邏輯的同時需要考慮N個系統的關聯需求。
如果從領域模型上看這些是登錄應該做的嗎？顯然不是，登錄系統只關注登錄用戶名密碼的校驗，其他系統是依賴登錄的事件來做后續的相關業務邏輯。在這樣的場景中適合用MQ來解耦。如下圖所示。
這樣各系統回歸到本來應該的樣子，登錄系統不用關注于別人對他的依賴，他只需要產生登錄事件的消息，有需要的系統各自去訂閱這個消息就好了，相互不受影響。
4.什么時候不需要MQ
既然MQ有這么多優點，那么所有的調用都使用MQ豈不是很好？無處不在的經濟學告訴我們：凡有收益必有代價。
MQ的不足：
（1）引入了負載度，多了一個MQ組件
（2）因為異步調用的延時大于RPC同步調用是，所以會出現短暫的不一致性
（3）無法做到事務的強一致，需要分布式事務方案來處理
（4）服務的消費方要做冪等設計，來規避重復調用的問題
（5）把消息放到隊列以便讓另一個組件來進行處理，對于這個場景，如果消息丟失是無法接受的 ，這也有一個很簡單的解決方案——數據庫。
所以在軟件的正常功能開發中，并不需要去刻意的尋找消息隊列的使用場景，而是當出現性能瓶頸時，去查看業務邏輯是否存在可以異步處理的耗時操作，如果存在的話便可以引入消息隊列來解決。否則盲目的使用消息隊列可能會增加維護和開發的成本卻無法得到可觀的性能提升，那就得不償失了。
5.消息中間件適用場景介紹
1.解耦：生產者不需要從消費者處獲得反饋
降低工程間的強依賴程度，針對異構系統進行適配。在項目啟動之初來預測將來項目會碰到什么需求，是極其困難的。通過消息系統在處理過程中間插入了一個隱含的、基于數據的接口層，兩邊的處理過程都要實現這一接口，當應用發生變化時，可以獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。
2.容許短暫的不一致性
有些業務不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。
3.削峰
如雙十一活動這樣的突發流量無法提前預知；使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。
4.設計時要考慮：用了確實有效果
如同下圖所示，異步調用相對于同步調用系統的負載進一步降低，同等配置的資源可以支撐更多的業務量。
5.其他場景：
如將非實時的調用通過MQ異步以后減少交易線響應時間，關鍵流程的TPS得到大幅提升等。
通過MQ異步調用外部三方系統，可以實現對內部系統的保障，避免三方系統故障影響到企業內部系統，也可平衡各企業系統QPS的差異，可以根據對方承諾不同的SLA進行調用。
6.如何選型
關于如何對MQ的進行選型，網上已經有很多不錯的描述了，我就過多展開。作為金融行很多場景都是需要數據的額強一致性和服務的持續可用，所以集群、支持事務和高可用性就是一個必不可少的要求。下面是常用MQ的各項內容對比，可以輔助進行MQ選型。
在MQ選型的過程中除了，考慮上圖的技術因素，還要結合團隊人員儲備情況，在引入前期選擇一個團隊熟悉又技術儲備又可以滿足要求的即可，不用過于最求新的技術，不經MQ這樣的基礎技術組件，在生產運行萬一出現問題是需要一個精通的人快速處理以消除業務影響。
6.遇到的那些坑
因為篇幅所限填坑指南將后面單獨一篇文章來寫。
7.小結：
