【高并發】為何高并發系統中都要使用消息隊列？這次徹底懂了！

寫在前面

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

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

場景分析

現在假設這樣一個場景，使用者下單成功需要給使用者發短信，如果沒有消息隊列，我們會選擇同步調用發短信的接口并等待短信發送成功。現在假設短信接口實作出現了問題或者短信發送短時間内達到了上限，這個時候是選擇重試幾次還是放棄發送呢？這裡的設計會很複雜。如果使用了消息隊列，我們選擇将發短信的操作封裝成一條消息發送到消息隊列，消息隊列通知一個服務去發送一條短信，即使出現了上述的問題，可以選擇把消息重新放到消息隊列裡等待處理。

消息隊列的好處

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

消息隊列特性

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

對于一些無關痛癢，或者對于别人非常重要但是對于自己不是那麼關心的事情，可以利用消息隊列去做。

支援最終一緻性的消息隊列，能夠用來處理延遲不那麼敏感的“分布式事務”場景，而且相對于笨重的分布式事務，可能是更優的處理方式。

當上下遊系統處理能力存在差距的時候，利用消息隊列做一個通用的“漏鬥”。在下遊有能力處理的時候，再進行分發。

如果下遊有很多系統關心你的系統發出的通知的時候，果斷地使用消息隊列吧。

寫在最後

如果覺得文章對你有點幫助，請微信搜尋并關注「 冰河技術 」微信公衆号，跟冰河學習高并發程式設計技術。

最後，附上并發程式設計需要掌握的核心技能知識圖，祝大家在學習并發程式設計時，少走彎路。