【高並發】為何高並發系統中都要使用消息隊列？這次徹底懂了！
寫在前面
很多高並發系統中都會使用到消息隊列中間件，那麼，問題來了，為什麼在高並發系統中都會使用到消息隊列中間件呢？立志成為資深架構師的你思考過這個問題嗎？
本文集結了眾多技術大牛的編程思想，由冰河匯聚並整理而成，在此，感謝那些在技術發展道理上默默付出的前輩們！
場景分析
現在假設這樣一個場景，用戶下單成功需要給用戶發簡訊，如果沒有消息隊列，我們會選擇同步調用發簡訊的介面並等待簡訊發送成功。現在假設簡訊介面實現出現了問題或者簡訊發送短時間內達到了上限，這個時候是選擇重試幾次還是放棄發送呢？這裡的設計會很複雜。如果使用了消息隊列，我們選擇將發簡訊的操作封裝成一條消息發送到消息隊列，消息隊列通知一個服務去發送一條簡訊，即使出現了上述的問題，可以選擇把消息重新放到消息隊列里等待處理。
消息隊列的好處
通過上述了例子，我們看到消息隊列完成了一個非同步解耦的過程，簡訊發送時我們只要保證簡訊發到消息隊列成功就可以了，接下來就可以去做別的事情；其次，設計變得更簡單，在下單的場景下，我們不用過多考慮發送簡訊的問題，交給消息隊列管理就行了，可能簡訊發送會有延遲，但是保證了最終的一致性。
消息隊列特性
- 業務無關，只做消息分發。
- FIFO，先投遞先到達。
- 容災：節點動態增刪和消息持久化。
- 性能：吞吐量提升，系統內部通訊效率提高。
高並發系統為何使用消息隊列？
（1）業務解耦
成功完成了一個非同步解耦的過程。簡訊發送時只要保證放到消息隊列中就可以了，接著做後面的事情就行。一個事務只關心本質的流程，需要依賴其他事情但是不那麼重要的時候，有通知即可，無需等待結果。每個成員不必受其他成員影響，可以更獨立自主，只通過一個簡單的容器來聯繫。
對於我們的訂單系統，訂單最終支付成功之後可能需要給用戶發送簡訊積分什麼的，但其實這已經不是我們系統的核心流程了。如果外部系統速度偏慢（比如簡訊網關速度不好），那麼主流程的時間會加長很多，用戶肯定不希望點擊支付過好幾分鐘才看到結果。那麼我們只需要通知簡訊系統「我們支付成功了」，不一定非要等待它處理完成。
（2）最終一致性
主要是用記錄和補償的方式來處理；在做所有的不確定事情之前，先把事情記錄下來，然後去做不確定的事，它的結果通常分為三種：成功，失敗或者不確定；如果成功，我們就可以把記錄的東西清理掉，對於失敗和不確定，我們可以採用定時任務的方式把所有失敗的事情重新做一遍直到成功為止。
保證了最終一致性，通過在隊列中存放任務保證它最終一定會執行。
最終一致性指的是兩個系統的狀態保持一致，要麼都成功，要麼都失敗。當然有個時間限制，理論上越快越好，但實際上在各種異常的情況下，可能會有一定延遲達到最終一致狀態，但最後兩個系統的狀態是一樣的。
業界有一些為「最終一致性」而生的消息隊列，如Notify（阿里）、QMQ（去哪兒）等，其設計初衷，就是為了交易系統中的高可靠通知。
以一個銀行的轉賬過程來理解最終一致性，轉賬的需求很簡單，如果A系統扣錢成功，則B系統加錢一定成功。反之則一起回滾，像什麼都沒發生一樣。
然而，這個過程中存在很多可能的意外：
- A扣錢成功，調用B加錢介面失敗。
- A扣錢成功，調用B加錢介面雖然成功，但獲取最終結果時網路異常引起超時。
- A扣錢成功，B加錢失敗，A想回滾扣的錢，但A機器down機。
可見，想把這件看似簡單的事真正做成，真的不那麼容易。所有跨JVM的一致性問題，從技術的角度講通用的解決方案是：
- 強一致性，分散式事務，但落地太難且成本太高。
- 最終一致性，主要是用「記錄」和「補償」的方式。在做所有的不確定的事情之前，先把事情記錄下來，然後去做不確定的事情，結果可能是：成功、失敗或是不確定，「不確定」（例如超時等）可以等價為失敗。成功就可以把記錄的東西清理掉了，對於失敗和不確定，可以依靠定時任務等方式把所有失敗的事情重新搞一遍，直到成功為止。
回到剛才的例子，系統在A扣錢成功的情況下，把要給B「通知」這件事記錄在庫里（為了保證最高的可靠性可以把通知B系統加錢和扣錢成功這兩件事維護在一個本地事務里），通知成功則刪除這條記錄，通知失敗或不確定則依靠定時任務補償性地通知我們，直到我們把狀態更新成正確的為止。
消息可能重複，注意消息的重複和冪等。
（3）廣播
如果沒有消息隊列，每當一個新的業務接入時，我們都需要連接一個新介面；有了消息隊列，我們只需要關係消息是否送到到消息隊列，新接入的介面訂閱相關的消息，自己去做處理就行了。
（4）錯峰與流控
利用消息隊列，轉儲兩個系統的通訊內容，並在下游系統有能力處理這些消息的時候再處理這些消息。試想上下游對於事情的處理能力是不同的。比如，Web前端每秒承受上千萬的請求，並不是什麼神奇的事情，只需要加多一點機器，再搭建一些LVS負載均衡設備和Nginx等即可。但資料庫的處理能力卻十分有限，即使使用SSD加分庫分表，單機的處理能力仍然在萬級。由於成本的考慮，我們不能奢求資料庫的機器數量追上前端。
這種問題同樣存在於系統和系統之間，如簡訊系統可能由於短板效應，速度卡在網關上（每秒幾百次請求），跟前端的並發量不是一個數量級。但用戶晚上個半分鐘左右收到簡訊，一般是不會有太大問題的。如果沒有消息隊列，兩個系統之間通過協商、滑動窗口等複雜的方案也不是說不能實現。但系統複雜性指數級增長，勢必在上游或者下游做存儲，並且要處理定時、擁塞等一系列問題。而且每當有處理能力有差距的時候，都需要單獨開發一套邏輯來維護這套邏輯。所以，利用中間系統轉儲兩個系統的通訊內容，並在下游系統有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。
總結
總而言之，消息隊列不是萬能的。對於需要強事務保證而且延遲敏感的，RPC是優於消息隊列的。
對於一些無關痛癢，或者對於別人非常重要但是對於自己不是那麼關心的事情，可以利用消息隊列去做。
支援最終一致性的消息隊列，能夠用來處理延遲不那麼敏感的「分散式事務」場景，而且相對於笨重的分散式事務，可能是更優的處理方式。
當上下游系統處理能力存在差距的時候，利用消息隊列做一個通用的「漏斗」。在下游有能力處理的時候，再進行分發。
如果下游有很多系統關心你的系統發出的通知的時候，果斷地使用消息隊列吧。
寫在最後
如果覺得文章對你有點幫助，請微信搜索並關注「 冰河技術 」微信公眾號，跟冰河學習高並發編程技術。
最後，附上並發編程需要掌握的核心技能知識圖，祝大家在學習並發編程時，少走彎路。
