作者個(gè)人研發(fā)的在高并發(fā)場(chǎng)景下，提供的簡(jiǎn)單、穩(wěn)定、可擴(kuò)展的延遲消息隊(duì)列框架，具有精準(zhǔn)的定時(shí)任務(wù)和延遲隊(duì)列處理功能。自開源半年多以來(lái)，已成功為十幾家中小型企業(yè)提供了精準(zhǔn)定時(shí)調(diào)度方案，經(jīng)受住了生產(chǎn)環(huán)境的考驗(yàn)。為使更多童鞋受益，現(xiàn)給出開源框架地址：https://github.com/sunshinelyz/mykit-delay

[[332765]]

寫在前面

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

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

場(chǎng)景分析

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

消息隊(duì)列的好處

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

消息隊(duì)列特性

• 業(yè)務(wù)無(wú)關(guān)，只做消息分發(fā)。
• FIFO，先投遞先到達(dá)。
• 容災(zāi)：節(jié)點(diǎn)動(dòng)態(tài)增刪和消息持久化。

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

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

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

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

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

(2)最終一致性

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

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

最終一致性指的是兩個(gè)系統(tǒng)的狀態(tài)保持一致，要么都成功，要么都失敗。當(dāng)然有個(gè)時(shí)間限制，理論上越快越好，但實(shí)際上在各種異常的情況下，可能會(huì)有一定延遲達(dá)到最終一致狀態(tài)，但最后兩個(gè)系統(tǒng)的狀態(tài)是一樣的。

業(yè)界有一些為“最終一致性”而生的消息隊(duì)列，如Notify(阿里)、QMQ(去哪兒)等，其設(shè)計(jì)初衷，就是為了交易系統(tǒng)中的高可靠通知。

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

然而，這個(gè)過(guò)程中存在很多可能的意外：

• A扣錢成功，調(diào)用B加錢接口失敗。
• A扣錢成功，調(diào)用B加錢接口雖然成功，但獲取最終結(jié)果時(shí)網(wǎng)絡(luò)異常引起超時(shí)。
• A扣錢成功，B加錢失敗，A想回滾扣的錢，但A機(jī)器down機(jī)。

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

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

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

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

(3)廣播

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

(4)錯(cuò)峰與流控

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

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

總結(jié)

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

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

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

當(dāng)上下游系統(tǒng)處理能力存在差距的時(shí)候，利用消息隊(duì)列做一個(gè)通用的“漏斗”。在下游有能力處理的時(shí)候，再進(jìn)行分發(fā)。

如果下游有很多系統(tǒng)關(guān)心你的系統(tǒng)發(fā)出的通知的時(shí)候，果斷地使用消息隊(duì)列吧。

本文轉(zhuǎn)載自微信公眾號(hào)「 冰河技術(shù)」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 冰河技術(shù)公眾號(hào)。