寫在前面

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

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

場景分析

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

消息隊(duì)列的好處

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

消息隊(duì)列特性

• 業(yè)務(wù)無關(guān)，只做消息分發(fā)。

• FIFO，先投遞先到達(dá)。

• 容災(zāi)：節(jié)點(diǎn)動態(tài)增刪和消息持久化。

• 性能：吞吐量提升，系統(tǒng)內(nèi)部通信效率提高。

高并發(fā)系統(tǒng)為何使用消息隊(duì)列？

（1）業(yè)務(wù)解耦

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

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

（2）最終一致性

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

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

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

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

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

• A扣錢成功，調(diào)用B加錢接口失敗。

• A扣錢成功，調(diào)用B加錢接口雖然成功，但獲取最終結(jié)果時網(wǎng)絡(luò)異常引起超時。

• A扣錢成功，B加錢失敗，A想回滾扣的錢，但A機(jī)器down機(jī)。

可見，想把這件看似簡單的事真正做成，真的不那么容易。所有跨JVM的一致性問題，從技術(shù)的角度講通用的解決方案是：

• 強(qiáng)一致性，分布式事務(wù)，但落地太難且成本太高。

• 最終一致性，主要是用“記錄”和“補(bǔ)償”的方式。在做所有的不確定的事情之前，先把事情記錄下來，然后去做不確定的事情，結(jié)果可能是：成功、失敗或是不確定，“不確定”（例如超時等）可以等價為失敗。成功就可以把記錄的東西清理掉了，對于失敗和不確定，可以依靠定時任務(wù)等方式把所有失敗的事情重新搞一遍，直到成功為止。

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

消息可能重復(fù)，注意消息的重復(fù)和冪等。

（3）廣播

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

（4）錯峰與流控

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

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

總結(jié)

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

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

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

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

寫在最后

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