【高并發(fā)】為何高并發(fā)系統(tǒng)中都要使用消息隊列？這次徹底懂了！

寫在前面

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

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

場景分析


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

消息隊列的好處


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

消息隊列特性

* 業(yè)務無關，只做消息分發(fā)。
* FIFO，先投遞先到達。
* 容災：節(jié)點動態(tài)增刪和消息持久化。
* 性能：吞吐量提升，系統(tǒng)內部通信效率提高。
高并發(fā)系統(tǒng)為何使用消息隊列？

（1）業(yè)務解耦


成功完成了一個異步解耦的過程。短信發(fā)送時只要保證放到消息隊列中就可以了，接著做后面的事情就行。一個事務只關心本質的流程，需要依賴其他事情但是不那么重要的時候，有通知即可，無需等待結果。每個成員不必受其他成員影響，可以更獨立自主，只通過一個簡單的容器來聯(lián)系。


對于我們的訂單系統(tǒng)，訂單最終支付成功之后可能需要給用戶發(fā)送短信積分什么的，但其實這已經不是我們系統(tǒng)的核心流程了。如果外部系統(tǒng)速度偏慢（比如短信網關速度不好），那么主流程的時間會加長很多，用戶肯定不希望點擊支付過好幾分鐘才看到結果。那么我們只需要通知短信系統(tǒng)“我們支付成功了”，不一定非要等待它處理完成。

（2）最終一致性


主要是用記錄和補償?shù)姆绞絹硖幚恚辉谧鏊械牟淮_定事情之前，先把事情記錄下來，然后去做不確定的事，它的結果通常分為三種：成功，失敗或者不確定；如果成功，我們就可以把記錄的東西清理掉，對于失敗和不確定，我們可以采用定時任務的方式把所有失敗的事情重新做一遍直到成功為止。

保證了最終一致性，通過在隊列中存放任務保證它最終一定會執(zhí)行。


最終一致性指的是兩個系統(tǒng)的狀態(tài)保持一致，要么都成功，要么都失敗。當然有個時間限制，理論上越快越好，但實際上在各種異常的情況下，可能會有一定延遲達到最終一致狀態(tài)，但最后兩個系統(tǒng)的狀態(tài)是一樣的。
業(yè)界有一些為“最終一致性”而生的消息隊列，如Notify（阿里）、QMQ（去哪兒）等，其設計初衷，就是為了交易系統(tǒng)中的高可靠通知。

以一個銀行的轉賬過程來理解最終一致性，轉賬的需求很簡單，如果A系統(tǒng)扣錢成功，則B系統(tǒng)加錢一定成功。反之則一起回滾，像什么都沒發(fā)生一樣。

然而，這個過程中存在很多可能的意外：

* A扣錢成功，調用B加錢接口失敗。
* A扣錢成功，調用B加錢接口雖然成功，但獲取最終結果時網絡異常引起超時。
* A扣錢成功，B加錢失敗，A想回滾扣的錢，但A機器down機。
可見，想把這件看似簡單的事真正做成，真的不那么容易。所有跨JVM的一致性問題，從技術的角度講通用的解決方案是：

* 強一致性，分布式事務，但落地太難且成本太高。
*
最終一致性，主要是用“記錄”和“補償”的方式。在做所有的不確定的事情之前，先把事情記錄下來，然后去做不確定的事情，結果可能是：成功、失敗或是不確定，“不確定”（例如超時等）可以等價為失敗。成功就可以把記錄的東西清理掉了，對于失敗和不確定，可以依靠定時任務等方式把所有失敗的事情重新搞一遍，直到成功為止。

回到剛才的例子，系統(tǒng)在A扣錢成功的情況下，把要給B“通知”這件事記錄在庫里（為了保證最高的可靠性可以把通知B系統(tǒng)加錢和扣錢成功這兩件事維護在一個本地事務里），通知成功則刪除這條記錄，通知失敗或不確定則依靠定時任務補償性地通知我們，直到我們把狀態(tài)更新成正確的為止。

消息可能重復，注意消息的重復和冪等。

（3）廣播


如果沒有消息隊列，每當一個新的業(yè)務接入時，我們都需要連接一個新接口；有了消息隊列，我們只需要關系消息是否送到到消息隊列，新接入的接口訂閱相關的消息，自己去做處理就行了。

（4）錯峰與流控


利用消息隊列，轉儲兩個系統(tǒng)的通信內容，并在下游系統(tǒng)有能力處理這些消息的時候再處理這些消息。試想上下游對于事情的處理能力是不同的。比如，Web前端每秒承受上千萬的請求，并不是什么神奇的事情，只需要加多一點機器，再搭建一些LVS負載均衡設備和Nginx等即可。但數(shù)據(jù)庫的處理能力卻十分有限，即使使用SSD加分庫分表，單機的處理能力仍然在萬級。由于成本的考慮，我們不能奢求數(shù)據(jù)庫的機器數(shù)量追上前端。


這種問題同樣存在于系統(tǒng)和系統(tǒng)之間，如短信系統(tǒng)可能由于短板效應，速度卡在網關上（每秒幾百次請求），跟前端的并發(fā)量不是一個數(shù)量級。但用戶晚上個半分鐘左右收到短信，一般是不會有太大問題的。如果沒有消息隊列，兩個系統(tǒng)之間通過協(xié)商、滑動窗口等復雜的方案也不是說不能實現(xiàn)。但系統(tǒng)復雜性指數(shù)級增長，勢必在上游或者下游做存儲，并且要處理定時、擁塞等一系列問題。而且每當有處理能力有差距的時候，都需要單獨開發(fā)一套邏輯來維護這套邏輯。所以，利用中間系統(tǒng)轉儲兩個系統(tǒng)的通信內容，并在下游系統(tǒng)有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。

總結

總而言之，消息隊列不是萬能的。對于需要強事務保證而且延遲敏感的，RPC是優(yōu)于消息隊列的。

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

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

當上下游系統(tǒng)處理能力存在差距的時候，利用消息隊列做一個通用的“漏斗”。在下游有能力處理的時候，再進行分發(fā)。
如果下游有很多系統(tǒng)關心你的系統(tǒng)發(fā)出的通知的時候，果斷地使用消息隊列吧。

寫在最后

如果覺得文章對你有點幫助，請微信搜索并關注「 冰河技術 」微信公眾號，跟冰河學習高并發(fā)編程技術。

最后，附上并發(fā)編程需要掌握的核心技能知識圖，祝大家在學習并發(fā)編程時，少走彎路。

• ? 上一篇：MySQL到底能有多少個字段
• ? 下一篇：javascript中判斷數(shù)據(jù)類型