資訊專欄INFORMATION COLUMN
摘要：典型場景二上游不關(guān)心執(zhí)行結(jié)果上游需要關(guān)注執(zhí)行結(jié)果時要用調(diào)用，上游不關(guān)注執(zhí)行結(jié)果時，就可以使用了。
【典型場景一：數(shù)據(jù)驅(qū)動的任務(wù)依賴】
什么是任務(wù)依賴，舉個栗子，互聯(lián)網(wǎng)公司經(jīng)常在凌晨進行一些數(shù)據(jù)統(tǒng)計任務(wù)，這些任務(wù)之間有一定的依賴關(guān)系，比如：
1）task3需要使用task2的輸出作為輸入
2）task2需要使用task1的輸出作為輸入
這樣的話，tast1, task2, task3之間就有任務(wù)依賴關(guān)系，必須task1先執(zhí)行，再task2執(zhí)行，載task3執(zhí)行。
對于這類需求，常見的實現(xiàn)方式是，使用cron人工排執(zhí)行時間表：
1）task1，0:00執(zhí)行，經(jīng)驗執(zhí)行時間為50分鐘
2）task2，1:00執(zhí)行（為task1預(yù)留10分鐘buffer），經(jīng)驗執(zhí)行時間也是50分鐘
3）task3，2:00執(zhí)行（為task2預(yù)留10分鐘buffer）
這種方法的壞處是：
1）如果有一個任務(wù)執(zhí)行時間超過了預(yù)留buffer的時間，將會得到錯誤的結(jié)果，因為后置任務(wù)不清楚前置任務(wù)是否執(zhí)行成功，此時要手動重跑任務(wù)，還有可能要調(diào)整排班表
2）總?cè)蝿?wù)的執(zhí)行時間很長，總是要預(yù)留很多buffer，如果前置任務(wù)提前完成，后置任務(wù)不會提前開始
3）如果一個任務(wù)被多個任務(wù)依賴，這個任務(wù)將會稱為關(guān)鍵路徑，排班表很難體現(xiàn)依賴關(guān)系，容易出錯
4）如果有一個任務(wù)的執(zhí)行時間要調(diào)整，將會有多個任務(wù)的執(zhí)行時間要調(diào)整
無論如何，采用“cron排班表”的方法，各任務(wù)耦合，誰用過誰痛誰知道（采用此法的請評論留言）
優(yōu)化方案是，采用MQ解耦：
1）task1準(zhǔn)時開始，結(jié)束后發(fā)一個“task1 done”的消息
2）task2訂閱“task1 done”的消息，收到消息后第一時間啟動執(zhí)行，結(jié)束后發(fā)一個“task2 done”的消息
3）task3同理
采用MQ的優(yōu)點是：
1）不需要預(yù)留buffer，上游任務(wù)執(zhí)行完，下游任務(wù)總會在第一時間被執(zhí)行
2）依賴多個任務(wù)，被多個任務(wù)依賴都很好處理，只需要訂閱相關(guān)消息即可
3）有任務(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)注。
這種方法的壞處是：
1）帖子發(fā)布流程的執(zhí)行時間增加了
2）下游服務(wù)當(dāng)機，可能導(dǎo)致帖子發(fā)布服務(wù)受影響，上下游邏輯+物理依賴嚴重
3）每當(dāng)增加一個需要知道“帖子發(fā)布成功”信息的下游，修改代碼的是帖子發(fā)布服務(wù)，這一點是最惡心的，屬于架構(gòu)設(shè)計中典型的依賴倒轉(zhuǎn)
優(yōu)化方案是，采用MQ解耦：
1）帖子發(fā)布成功后，向MQ發(fā)一個消息
2）哪個下游關(guān)注“帖子發(fā)布成功”的消息，主動去MQ訂閱
采用MQ的優(yōu)點是：
1）上游執(zhí)行時間短
2）上下游邏輯+物理解耦，除了與MQ有物理連接，模塊之間都不相互依賴
3）新增一個下游消息關(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”方案來解耦：
1）調(diào)用方直接跨公網(wǎng)調(diào)用微信接口
2）微信返回調(diào)用成功，此時并不代表返回成功
3）微信執(zhí)行完成后，回調(diào)統(tǒng)一網(wǎng)關(guān)
4）網(wǎng)關(guān)將返回結(jié)果通知MQ
5）請求方收到結(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)用，都不需要修改代碼啦。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/72789.html
摘要：而每個文件系統(tǒng)又可以設(shè)置不同的調(diào)度算法，另外，還有虛擬內(nèi)存缺頁中斷帶來的性能毛刺良心的提供了調(diào)優(yōu)的腳本，這點做的不錯跑題了。測試環(huán)境核線程內(nèi)存磁盤讀寫左右虛擬內(nèi)存未關(guān)閉，大小測試注意點為了防止緩存的影響，每次都生成一個新的文件進行讀取。 前言 Java 在 JDK 1.4 引入了 ByteBuffer 等 NIO 相關(guān)的類，使得 Java 程序員可以拋棄基于 Stream ，從而使用基...
本文是公眾號讀者jianfeng投稿的面試經(jīng)驗恭喜該同學(xué)成功轉(zhuǎn)型目錄：毅然轉(zhuǎn)型，沒頭蒼蠅制定目標(biāo)，系統(tǒng)學(xué)習(xí)面試經(jīng)歷毅然轉(zhuǎn)崗，沒頭蒼蠅首先，介紹一下我的背景。本人坐標(biāo)廣州，2016年畢業(yè)于一個普通二本大學(xué)，曾經(jīng)在某機構(gòu)培訓(xùn)過Android。2018年初的時候已經(jīng)在兩家小公司工作干了兩年的android開發(fā)，然后會一些Tomcat、Servlet之類的技術(shù)，當(dāng)時的年薪大概也就15萬這樣子。由于個人發(fā)展...
摘要：已預(yù)留擴展，可以實現(xiàn)自己的模塊你想好了嗎你是否真的需要這樣的一個工具，到底是異步還是同步，什么樣的才可以稱的上任務(wù)。異步分布執(zhí)行雖然可以提高系統(tǒng)吞吐量，但它是在高于一定得計算量請求量的情況下才可以顯現(xiàn)出來這一特點。 Task系統(tǒng)設(shè)計與使用 Task是一個輕量級的分布式任務(wù)計算系統(tǒng),他可以幫助你快速編寫一個可以在集群環(huán)境下運行的分布式方法,而這只需要你使用一行代碼就可以在你原有的方法上做...
閱讀 1597·2023-04-25 14:12
閱讀 1070·2021-08-27 16:24
閱讀 2533·2019-08-30 15:44
閱讀 2913·2019-08-30 13:16
閱讀 1665·2019-08-29 14:10
閱讀 966·2019-08-29 13:54
閱讀 1297·2019-08-29 13:09
閱讀 1803·2019-08-26 18:37
