【高併發】爲什麼高併發系統中都要使用消息隊列？此次完全懂了！

寫在前面

不少高併發系統中都會使用到消息隊列中間件，那麼，問題來了，爲何在高併發系統中都會使用到消息隊列中間件呢？立志成爲資深架構師的你思考過這個問題嗎？

本文集結了衆多技術大牛的編程思想，由冰河匯聚並整理而成，在此，感謝那些在技術發展道理上默默付出的前輩們！

場景分析

如今假設這樣一個場景，用戶下單成功須要給用戶發短信，若是沒有消息隊列，咱們會選擇同步調用發短信的接口並等待短信發送成功。如今假設短信接口實現出現了問題或者短信發送短期內達到了上限，這個時候是選擇重試幾回仍是放棄發送呢？這裏的設計會很複雜。若是使用了消息隊列，咱們選擇將發短信的操做封裝成一條消息發送到消息隊列，消息隊列通知一個服務去發送一條短信，即便出現了上述的問題，能夠選擇把消息從新放到消息隊列裏等待處理。

消息隊列的好處

經過上述了例子，咱們看到消息隊列完成了一個異步解耦的過程，短信發送時咱們只要保證短信發到消息隊列成功就能夠了，接下來就能夠去作別的事情；其次，設計變得更簡單，在下單的場景下，咱們不用過多考慮發送短信的問題，交給消息隊列管理就好了，可能短信發送會有延遲，可是保證了最終的一致性。

消息隊列特性

• 業務無關，只作消息分發。
• 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是優於消息隊列的。

對於一些無關痛癢，或者對於別人很是重要可是對於本身不是那麼關心的事情，能夠利用消息隊列去作。

支持最終一致性的消息隊列，可以用來處理延遲不那麼敏感的「分佈式事務」場景，並且相對於笨重的分佈式事務，多是更優的處理方式。

當上下游系統處理能力存在差距的時候，利用消息隊列作一個通用的「漏斗」。在下游有能力處理的時候，再進行分發。
若是下游有不少系統關心你的系統發出的通知的時候，果斷地使用消息隊列吧。

寫在最後

若是以爲文章對你有點幫助，請微信搜索並關注「 冰河技術 」微信公衆號，跟冰河學習高併發編程技術。

最後，附上併發編程須要掌握的核心技能知識圖，祝你們在學習併發編程時，少走彎路。