任何脫離業(yè)務(wù)的組件引入都是耍流氓。引入一個(gè)組件，最先該解答的問題是，此組件解決什么問題。

MQ，互聯(lián)網(wǎng)技術(shù)體系中一個(gè)常見組件，究竟什么時(shí)候不使用MQ，究竟什么時(shí)候使用MQ，MQ究竟適合什么場(chǎng)景，是今天要分享的內(nèi)容。

?

MQ是什么？

消息總線（Message Queue），后文稱MQ，是一種跨進(jìn)程的通信機(jī)制，用于上下游傳遞消息。

畫外音：這兩個(gè)進(jìn)程，一般不在同一臺(tái)服務(wù)器上。

?

在互聯(lián)網(wǎng)架構(gòu)中，MQ經(jīng)常用做“上下游解耦”：

（1）消息發(fā)送方只依賴MQ，不關(guān)注消費(fèi)方是誰(shuí)；

（2）消息消費(fèi)方也只依賴MQ，不關(guān)注發(fā)送方是誰(shuí)；

畫外音：發(fā)送方與消費(fèi)方，邏輯上和物理上都不依賴彼此。

什么時(shí)候不使用MQ？

當(dāng)調(diào)用方需要關(guān)心消息執(zhí)行結(jié)果時(shí)，通常不使用MQ，而使用RPC調(diào)用。

ret = PassportService::userAuth(name, pass);

switch(ret){

? ? case(YES) : return YesHTML();

? ? case(NO) : return NoHTML();

? ? case(JUMP) : return 304HTML():

? ? default : return 500HTML();

}

?

如上例所示，上游調(diào)用Passport服務(wù)，處理結(jié)果不同，業(yè)務(wù)會(huì)走不同的邏輯處理分支（登錄成功，登錄失敗，執(zhí)行錯(cuò)誤等），即“處理結(jié)果強(qiáng)依賴”，此時(shí)應(yīng)該使用RPC調(diào)用。

畫外音：絕大部分情況，應(yīng)該使用RPC。

?

此時(shí)如果強(qiáng)行使用MQ呢？

如果強(qiáng)行使用MQ通訊，調(diào)用方不能直接告之用戶登錄成功又或失敗，則要等待另一個(gè)MQ通知回調(diào)。這么玩，不但使得編碼復(fù)雜，還會(huì)引入消息丟失的風(fēng)險(xiǎn)，中間多加入一層，多此一舉。

?

究竟什么時(shí)候使用MQ呢？

下面四類典型場(chǎng)景，應(yīng)該使用MQ。

典型場(chǎng)景一：數(shù)據(jù)驅(qū)動(dòng)的任務(wù)依賴

什么是任務(wù)依賴？

舉個(gè)栗子，互聯(lián)網(wǎng)公司經(jīng)常在凌晨進(jìn)行一些數(shù)據(jù)統(tǒng)計(jì)任務(wù)，這些任務(wù)之間有一定的依賴關(guān)系，例如：

（1）task3需要使用task2的輸出作為輸入；

（2）task2需要使用task1的輸出作為輸入；

這樣的話，tast1, task2, task3之間就有任務(wù)依賴關(guān)系，必須task1先執(zhí)行，再task2執(zhí)行，載task3執(zhí)行。

對(duì)于這類需求，通常怎么實(shí)現(xiàn)呢？

常見的玩法是，crontab人工排執(zhí)行時(shí)間表。

如上圖，手動(dòng)設(shè)定如下：

（1）task1，0:00執(zhí)行，經(jīng)驗(yàn)執(zhí)行時(shí)間為50分鐘；

（2）task2，1:00執(zhí)行（為task1預(yù)留10分鐘buffer），經(jīng)驗(yàn)執(zhí)行時(shí)間也是50分鐘；

（3）task3，2:00執(zhí)行（為task2預(yù)留10分鐘buffer）；

?

crontab手動(dòng)排表有什么壞處呢？

（1）如果有一個(gè)任務(wù)執(zhí)行時(shí)間超過了預(yù)留buffer的時(shí)間，將會(huì)得到錯(cuò)誤的結(jié)果，因?yàn)楹笾萌蝿?wù)不清楚前置任務(wù)是否執(zhí)行成功，此時(shí)要手動(dòng)重跑任務(wù)，還有可能要調(diào)整排班表；

（2）總?cè)蝿?wù)的執(zhí)行時(shí)間很長(zhǎng)，總是要預(yù)留很多buffer，如果前置任務(wù)提前完成，后置任務(wù)不會(huì)提前開始；

（3）如果一個(gè)任務(wù)被多個(gè)任務(wù)依賴，這個(gè)任務(wù)將會(huì)稱為關(guān)鍵路徑，排班表很難體現(xiàn)依賴關(guān)系，容易出錯(cuò)；

（4）如果有一個(gè)任務(wù)的執(zhí)行時(shí)間要調(diào)整，將會(huì)有多個(gè)任務(wù)的執(zhí)行時(shí)間要調(diào)整；

無(wú)論如何，采用“crontab排班表”的方法，各任務(wù)嚴(yán)重耦合，誰(shuí)用過誰(shuí)痛誰(shuí)知道。

畫外音：用過的，痛過的，請(qǐng)留言。

?

應(yīng)該如何優(yōu)化呢？

采用MQ解耦。

如上圖，任務(wù)之間通過MQ來傳遞“開始”與“結(jié)束”的通知：

（1）task1準(zhǔn)時(shí)開始，結(jié)束后發(fā)一個(gè)“task1 done”的消息；

（2）task2訂閱“task1 done”的消息，收到消息后第一時(shí)間啟動(dòng)執(zhí)行，結(jié)束后發(fā)一個(gè)“task2 done”的消息；

（3）task3同理；

?

采用MQ有什么好處呢？

（1）不需要預(yù)留buffer，上游任務(wù)執(zhí)行完，下游任務(wù)總會(huì)在第一時(shí)間被執(zhí)行；

（2）依賴多個(gè)任務(wù)，被多個(gè)任務(wù)依賴都很好處理，只需要訂閱相關(guān)消息即可；

（3）有任務(wù)執(zhí)行時(shí)間變化，下游任務(wù)都不需要調(diào)整執(zhí)行時(shí)間；

?

需要特別說明的是，MQ只用來傳遞上游任務(wù)執(zhí)行完成的消息，并不用于傳遞真正的輸入輸出數(shù)據(jù)。

?

典型場(chǎng)景二：上游不關(guān)心執(zhí)行結(jié)果

上游需要關(guān)注執(zhí)行結(jié)果時(shí)要用“RPC調(diào)用”，上游不關(guān)注執(zhí)行結(jié)果時(shí)，使用MQ。

?

舉個(gè)栗子，58同城的很多下游需要關(guān)注“用戶發(fā)布帖子”這個(gè)事件，比如：

（1）招聘用戶發(fā)布帖子后，招聘業(yè)務(wù)要獎(jiǎng)勵(lì)58豆；

（2）房產(chǎn)用戶發(fā)布帖子后，房產(chǎn)業(yè)務(wù)要送2個(gè)置頂；

（3）二手用戶發(fā)布帖子后，二手業(yè)務(wù)要修改用戶統(tǒng)計(jì)數(shù)據(jù)；

?

對(duì)于這類需求，可以采用什么方式實(shí)現(xiàn)呢？

比較無(wú)腦的，可以使用RPC調(diào)用來實(shí)現(xiàn)：

帖子發(fā)布服務(wù)執(zhí)行完成之后，調(diào)用下游招聘業(yè)務(wù)、房產(chǎn)業(yè)務(wù)、二手業(yè)務(wù)，來完成消息的通知。

但事實(shí)上，這個(gè)通知是否正常正確的執(zhí)行，帖子發(fā)布服務(wù)根本不關(guān)注。

?

通過RPC來傳遞不需要知道處理結(jié)果的通知，有什么壞處呢？

（1）帖子發(fā)布流程的執(zhí)行時(shí)間增加了；

（2）下游服務(wù)當(dāng)機(jī)，可能導(dǎo)致帖子發(fā)布服務(wù)受影響，上下游邏輯+物理依賴嚴(yán)重；

（3）每當(dāng)增加一個(gè)需要知道“帖子發(fā)布成功”信息的下游，修改代碼的是帖子發(fā)布服務(wù)；

畫外音：這一點(diǎn)是最惡心的，屬于架構(gòu)設(shè)計(jì)中典型的反向依賴。

如何來進(jìn)行優(yōu)化呢?

采用MQ解耦，代替RPC。

如上圖所示:

（1）帖子發(fā)布成功后，向MQ發(fā)一個(gè)消息；

（2）哪個(gè)下游關(guān)注“帖子發(fā)布成功”的消息，主動(dòng)去MQ訂閱；

?

如此一來，有什么好處呢？

（1）上游執(zhí)行時(shí)間短；

（2）上下游邏輯+物理解耦，除了與MQ有物理連接，模塊之間都不相互依賴；

（3）新增一個(gè)下游消息關(guān)注方，上游不需要修改任何代碼；

?

典型場(chǎng)景三：上游關(guān)注執(zhí)行結(jié)果，但執(zhí)行時(shí)間很長(zhǎng)

有時(shí)候上游需要關(guān)注執(zhí)行結(jié)果，但執(zhí)行結(jié)果時(shí)間很長(zhǎng)（典型的是調(diào)用離線處理，或者跨公網(wǎng)調(diào)用），也經(jīng)常使用回調(diào)網(wǎng)關(guān)+MQ來解耦。

?

舉個(gè)栗子，微信支付，跨公網(wǎng)調(diào)用微信的接口，執(zhí)行時(shí)間會(huì)比較長(zhǎng)，但調(diào)用方又非常關(guān)注執(zhí)行結(jié)果，此時(shí)一般怎么玩呢？

一般采用“回調(diào)網(wǎng)關(guān)+MQ”方案來解耦：

（1）調(diào)用方直接跨公網(wǎng)調(diào)用微信接口；

（2）微信返回調(diào)用成功，此時(shí)并不代表返回成功；

（3）微信執(zhí)行完成后，回調(diào)統(tǒng)一網(wǎng)關(guān)；

（4）網(wǎng)關(guān)將返回結(jié)果通知MQ；

（5）請(qǐng)求方收到結(jié)果通知；

?

這里需要注意的是，不應(yīng)該由回調(diào)網(wǎng)關(guān)來RPC通知上游來通知結(jié)果，如果是這樣的話，每次新增調(diào)用方，回調(diào)網(wǎng)關(guān)都需要修改代碼，仍然會(huì)反向依賴，使用回調(diào)網(wǎng)關(guān)+MQ的方案，新增任何對(duì)微信支付的調(diào)用，都不需要修改代碼。

?

結(jié)尾總結(jié)

MQ是一個(gè)互聯(lián)網(wǎng)架構(gòu)中常見的解耦利器。

什么時(shí)候不使用MQ？

上游實(shí)時(shí)關(guān)注執(zhí)行結(jié)果，通常采用RPC。

?

什么時(shí)候使用MQ？

（1）數(shù)據(jù)驅(qū)動(dòng)的任務(wù)依賴；

（2）上游不關(guān)心多下游執(zhí)行結(jié)果；

（3）異步返回執(zhí)行時(shí)間長(zhǎng)；

知其然，知其所以然，希望大家有收獲。

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

新人創(chuàng)作打卡挑戰(zhàn)賽發(fā)博客就能抽獎(jiǎng)！定制產(chǎn)品紅包拿不停！

總結(jié)

以上是生活随笔為你收集整理的究竟什么时候该使用MQ？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。