建站
咨詢
售后
建站咨詢
新聞中心
一、緣起
創(chuàng)新互聯(lián)成立于2013年，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都做網(wǎng)站、成都網(wǎng)站制作網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元寶山做網(wǎng)站,已為上家服務(wù),為寶山各地企業(yè)和個人服務(wù),聯(lián)系電話:13518219792
一切脫離業(yè)務(wù)的架構(gòu)設(shè)計與新技術(shù)引入都是耍流氓。
引入一個技術(shù)之前，首先應(yīng)該解答的問題是，這個技術(shù)解決什么問題。
就像微服務(wù)分層架構(gòu)之前，應(yīng)該首先回答，為什么要引入微服務(wù)，微服務(wù)究竟解決什么問題(詳見《互聯(lián)網(wǎng)架構(gòu)為什么要做微服務(wù)?》)。
最近分享了幾篇MQ相關(guān)的文章：
- 《MQ如何實現(xiàn)延時消息》
- 《MQ如何實現(xiàn)消息必達》
- 《MQ如何實現(xiàn)冪等性》
不少網(wǎng)友詢問，究竟什么時候使用MQ，MQ究竟適合什么場景，故有了此文。
二、MQ是干嘛的
消息總線(Message Queue)，后文稱MQ，是一種跨進程的通信機制，用于上下游傳遞消息。
在互聯(lián)網(wǎng)架構(gòu)中，MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的消息通信服務(wù)。
使用了MQ之后，消息發(fā)送上游只需要依賴MQ，邏輯上和物理上都不用依賴其他服務(wù)。
三、什么時候不使用消息總線
既然MQ是互聯(lián)網(wǎng)分層架構(gòu)中的解耦利器，那所有通訊都使用MQ豈不是很好?這是一個嚴重的誤區(qū)，調(diào)用與被調(diào)用的關(guān)系，是無法被MQ取代的。
MQ的不足是：
- 系統(tǒng)更復(fù)雜，多了一個MQ組件
- 消息傳遞路徑更長，延時會增加
- 消息可靠性和重復(fù)性互為矛盾，消息不丟不重難以同時保證
- 上游無法知道下游的執(zhí)行結(jié)果，這一點是很致命的
舉個栗子：用戶登錄場景，登錄頁面調(diào)用passport服務(wù)，passport服務(wù)的執(zhí)行結(jié)果直接影響登錄結(jié)果，此處的“登錄頁面”與“passport服務(wù)”就必須使用調(diào)用關(guān)系，而不能使用MQ通信。
無論如何，記住這個結(jié)論：調(diào)用方實時依賴執(zhí)行結(jié)果的業(yè)務(wù)場景，請使用調(diào)用，而不是MQ。
四、什么時候使用MQ
【典型場景一：數(shù)據(jù)驅(qū)動的任務(wù)依賴】
什么是任務(wù)依賴，舉個栗子，互聯(lián)網(wǎng)公司經(jīng)常在凌晨進行一些數(shù)據(jù)統(tǒng)計任務(wù)，這些任務(wù)之間有一定的依賴關(guān)系，比如：
- task3需要使用task2的輸出作為輸入
- task2需要使用task1的輸出作為輸入
這樣的話，tast1, task2, task3之間就有任務(wù)依賴關(guān)系，必須task1先執(zhí)行，再task2執(zhí)行，載task3執(zhí)行。
對于這類需求，常見的實現(xiàn)方式是，使用cron人工排執(zhí)行時間表：
- task1，0:00執(zhí)行，經(jīng)驗執(zhí)行時間為50分鐘
- task2，1:00執(zhí)行(為task1預(yù)留10分鐘buffer)，經(jīng)驗執(zhí)行時間也是50分鐘
- task3，2:00執(zhí)行(為task2預(yù)留10分鐘buffer)
這種方法的壞處是：
- 如果有一個任務(wù)執(zhí)行時間超過了預(yù)留buffer的時間，將會得到錯誤的結(jié)果，因為后置任務(wù)不清楚前置任務(wù)是否執(zhí)行成功，此時要手動重跑任務(wù)，還有可能要調(diào)整排班表
- 總?cè)蝿?wù)的執(zhí)行時間很長，總是要預(yù)留很多buffer，如果前置任務(wù)提前完成，后置任務(wù)不會提前開始
- 如果一個任務(wù)被多個任務(wù)依賴，這個任務(wù)將會稱為關(guān)鍵路徑，排班表很難體現(xiàn)依賴關(guān)系，容易出錯
- 如果有一個任務(wù)的執(zhí)行時間要調(diào)整，將會有多個任務(wù)的執(zhí)行時間要調(diào)整
無論如何，采用“cron排班表”的方法，各任務(wù)耦合，誰用過誰痛誰知道(采用此法的請評論留言)
優(yōu)化方案是，采用MQ解耦：
- task1準時開始，結(jié)束后發(fā)一個“task1 done”的消息
- task2訂閱“task1 done”的消息，收到消息后第一時間啟動執(zhí)行，結(jié)束后發(fā)一個“task2 done”的消息
- task3同理
采用MQ的優(yōu)點是：
- 不需要預(yù)留buffer，上游任務(wù)執(zhí)行完，下游任務(wù)總會在第一時間被執(zhí)行
- 依賴多個任務(wù)，被多個任務(wù)依賴都很好處理，只需要訂閱相關(guān)消息即可
- 有任務(wù)執(zhí)行時間變化，下游任務(wù)都不需要調(diào)整執(zhí)行時間
需要特別說明的是，MQ只用來傳遞上游任務(wù)執(zhí)行完成的消息，并不用于傳遞真正的輸入輸出數(shù)據(jù)。
【典型場景二：上游不關(guān)心執(zhí)行結(jié)果】
上游需要關(guān)注執(zhí)行結(jié)果時要用“調(diào)用”，上游不關(guān)注執(zhí)行結(jié)果時，就可以使用MQ了。
舉個栗子，58同城的很多下游需要關(guān)注“用戶發(fā)布帖子”這個事件，比如招聘用戶發(fā)布帖子后，招聘業(yè)務(wù)要獎勵58豆，房產(chǎn)用戶發(fā)布帖子后，房產(chǎn)業(yè)務(wù)要送2個置頂，二手用戶發(fā)布帖子后，二手業(yè)務(wù)要修改用戶統(tǒng)計數(shù)據(jù)。
對于這類需求，常見的實現(xiàn)方式是，使用調(diào)用關(guān)系：
帖子發(fā)布服務(wù)執(zhí)行完成之后，調(diào)用下游招聘業(yè)務(wù)、房產(chǎn)業(yè)務(wù)、二手業(yè)務(wù)，來完成消息的通知，但事實上，這個通知是否正常正確的執(zhí)行，帖子發(fā)布服務(wù)根本不關(guān)注。
這種方法的壞處是：
- 帖子發(fā)布流程的執(zhí)行時間增加了
- 下游服務(wù)當機，可能導(dǎo)致帖子發(fā)布服務(wù)受影響，上下游邏輯+物理依賴嚴重
- 每當增加一個需要知道“帖子發(fā)布成功”信息的下游，修改代碼的是帖子發(fā)布服務(wù)，這一點是最惡心的，屬于架構(gòu)設(shè)計中典型的依賴倒轉(zhuǎn)，誰用過誰痛誰知道(采用此法的請評論留言)
優(yōu)化方案是，采用MQ解耦：
- 帖子發(fā)布成功后，向MQ發(fā)一個消息
- 哪個下游關(guān)注“帖子發(fā)布成功”的消息，主動去MQ訂閱
采用MQ的優(yōu)點是：
- 上游執(zhí)行時間短
- 上下游邏輯+物理解耦，除了與MQ有物理連接，模塊之間都不相互依賴
- 新增一個下游消息關(guān)注方，上游不需要修改任何代碼
典型場景三：上游關(guān)注執(zhí)行結(jié)果，但執(zhí)行時間很長
有時候上游需要關(guān)注執(zhí)行結(jié)果，但執(zhí)行結(jié)果時間很長(典型的是調(diào)用離線處理，或者跨公網(wǎng)調(diào)用)，也經(jīng)常使用回調(diào)網(wǎng)關(guān)+MQ來解耦。
舉個栗子，微信支付，跨公網(wǎng)調(diào)用微信的接口，執(zhí)行時間會比較長，但調(diào)用方又非常關(guān)注執(zhí)行結(jié)果，此時一般怎么玩呢?
一般采用“回調(diào)網(wǎng)關(guān)+MQ”方案來解耦：
- 調(diào)用方直接跨公網(wǎng)調(diào)用微信接口
- 微信返回調(diào)用成功，此時并不代表返回成功
- 微信執(zhí)行完成后，回調(diào)統(tǒng)一網(wǎng)關(guān)
- 網(wǎng)關(guān)將返回結(jié)果通知MQ
- 請求方收到結(jié)果通知
這里需要注意的是，不應(yīng)該由回調(diào)網(wǎng)關(guān)來調(diào)用上游來通知結(jié)果，如果是這樣的話，每次新增調(diào)用方，回調(diào)網(wǎng)關(guān)都需要修改代碼，仍然會反向依賴，使用回調(diào)網(wǎng)關(guān)+MQ的方案，新增任何對微信支付的調(diào)用，都不需要修改代碼啦。
五、總結(jié)
MQ是一個互聯(lián)網(wǎng)架構(gòu)中常見的解耦利器。
什么時候不使用MQ?
- 上游實時關(guān)注執(zhí)行結(jié)果
什么時候使用MQ?
- 數(shù)據(jù)驅(qū)動的任務(wù)依賴
- 上游不關(guān)心多下游執(zhí)行結(jié)果
- 異步返回執(zhí)行時間長
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
網(wǎng)頁標題：到底什么時候該使用MQ？
轉(zhuǎn)載注明：http://www.5511xx.com/article/dpcseji.html
