大家好，我是君哥。今天分享批量任務(wù)的重疊問題。

面試官：聊聊你用過的任務(wù)調(diào)度框架？

我：目前任務(wù)調(diào)度框架的選擇有很多，比如業(yè)內(nèi)熟悉的 QuartZ，Spring Batch，xxl-job，以及新一代的任務(wù)框架 PowerJob 等。我本人使用最多的還是 xxl-job。

面試官：使用 xxl-job 遇到過任務(wù)重疊的問題嗎？

我：任務(wù)重疊是批量任務(wù)調(diào)度中經(jīng)常遇到的問題，主流的分布式調(diào)度框架是可以解決部分任務(wù)重復(fù)問題的，但并不能解決全部問題。

面試官：能說一下 xxl-job 解決了哪些任務(wù)重疊的問題，還有哪些問題沒有解決嗎？

我：（下午來自 xxl-job 官網(wǎng)）

• FIRST（第一個(gè)）：固定選擇第一個(gè)機(jī)器。
• LAST（最后一個(gè)）：固定選擇最后一個(gè)機(jī)器。
• ROUND（輪詢）：按照注冊機(jī)器的列表順序進(jìn)行任務(wù)調(diào)度。
• RANDOM（隨機(jī)）：隨機(jī)選擇在線的機(jī)器。
• CONSISTENT_HASH（一致性HASH）：每個(gè)任務(wù)按照Hash算法固定選擇某一臺(tái)機(jī)器，且所有任務(wù)均勻散列在不同機(jī)器上。
• LEAST_FREQUENTLY_USED（最不經(jīng)常使用）：使用頻率最低的機(jī)器優(yōu)先被選舉。
• LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的機(jī)器優(yōu)先被選舉。
• FAILOVER（故障轉(zhuǎn)移）：按照順序依次進(jìn)行心跳檢測，第一個(gè)心跳檢測成功的機(jī)器選定為目標(biāo)執(zhí)行器并發(fā)起調(diào)度。
• BUSYOVER（忙碌轉(zhuǎn)移）：按照順序依次進(jìn)行空閑檢測，第一個(gè)空閑檢測成功的機(jī)器選定為目標(biāo)執(zhí)行器并發(fā)起調(diào)度。
• SHARDING_BROADCAST(分片廣播)：廣播觸發(fā)對應(yīng)集群中所有機(jī)器執(zhí)行一次任務(wù)，同時(shí)系統(tǒng)自動(dòng)傳遞分片參數(shù)；可根據(jù)分片參數(shù)開發(fā)分片任務(wù)。

雖然策略比較多，但是常用的策略就是固定在一臺(tái)機(jī)器上面跑或者輪詢策略。假設(shè)有一個(gè)密集的定時(shí)調(diào)度任務(wù)，每隔兩分鐘跑一次，如果在同一個(gè)機(jī)器上跑，遇到調(diào)用下游接口響應(yīng)慢，或者處理的業(yè)務(wù)數(shù)據(jù)暴增，可能出現(xiàn)前一次任務(wù)還沒有完成，下一次任務(wù)已經(jīng)發(fā)起了。為了防止任務(wù)重疊在一臺(tái)機(jī)器上，可以采用 xxl-job 輪詢的策略。

面試官：按照你剛才舉的例子，定時(shí)任務(wù)每隔兩分鐘跑一次，如果選擇固定在一臺(tái)機(jī)器上跑，比如選擇路由策略是 FIRST 或者 LAST，有多個(gè)任務(wù)重疊在一臺(tái)機(jī)器上，xxl-job 是怎樣解決的？

我：對于跑批間隔時(shí)間比較短的定時(shí)任務(wù)，因?yàn)檎{(diào)度很密集，執(zhí)行器很容易造成任務(wù)阻塞。xxl-job 提供了 3 種阻塞處理策略:

• 單機(jī)串行（默認(rèn)）：調(diào)度請求進(jìn)入單機(jī)執(zhí)行器后，調(diào)度請求進(jìn)入 FIFO 隊(duì)列并以串行方式運(yùn)行。
• 丟棄后續(xù)調(diào)度：調(diào)度請求進(jìn)入單機(jī)執(zhí)行器后，發(fā)現(xiàn)執(zhí)行器存在運(yùn)行的調(diào)度任務(wù)，本次請求將會(huì)被丟棄并標(biāo)記為失敗。
• 覆蓋之前調(diào)度：調(diào)度請求進(jìn)入單機(jī)執(zhí)行器后，發(fā)現(xiàn)執(zhí)行器存在運(yùn)行的調(diào)度任務(wù)，將會(huì)終止運(yùn)行中的調(diào)度任務(wù)并清空隊(duì)列，然后運(yùn)行本地調(diào)度任務(wù)。

采用單機(jī)串行的策略，如果前面的任務(wù)沒有處理完成，后面的任務(wù)只能排隊(duì)，等待被調(diào)度。

面試官：單機(jī)任務(wù)排隊(duì)執(zhí)行，這種策略看上去沒有什么問題。你有遇到過相關(guān)問題嗎？ 

我：一般場景下是不會(huì)有影響的，但如果一個(gè)任務(wù)跟日期相關(guān)，有任務(wù)排隊(duì)到第二天才能執(zhí)行，很可能會(huì)造成業(yè)務(wù)影響。

面試官：能舉一個(gè)具體的場景嗎？

我：舉一個(gè)貸款業(yè)務(wù)的例子，系統(tǒng)通過跑批任務(wù)給應(yīng)還款日是第二天的客戶發(fā)送還款短信通知，處理邏輯是每個(gè)任務(wù)查出應(yīng)還款日是第二天的一批用戶，然后發(fā)送短信通知。這里的第二天需要用系統(tǒng)日期來判斷。如果有排隊(duì)的任務(wù)到第二天才執(zhí)行，那應(yīng)還款的部分用戶會(huì)收不到通知。

面試官：這種場景 xxl-job 有解決方案嗎？

我：采用輪詢的路由策略，可以讓排隊(duì)的任務(wù)調(diào)度的不同的機(jī)器上，這樣可以減少單機(jī)器的任務(wù)積壓問題。

面試官：采用輪詢的路由策略，表面看是可以解決單機(jī)器的任務(wù)積壓問題。但如果任務(wù)積壓是因?yàn)橄掠谓涌陧憫?yīng)慢、sql 查詢性能差等造成的任務(wù)執(zhí)行慢，采用輪詢策略可以解決嗎？

我：這類問題造成的任務(wù)排隊(duì)，改為輪詢策略也是解決不了的，輪詢策略只能解決類似單機(jī)資源緊張?jiān)斐膳芘那闆r。

面試官：那這些問題有什么解決方案嗎？

我：業(yè)務(wù)上是有解決方案的，比如金融行業(yè)系統(tǒng)里面一般有“切日”的概念，跟日期相關(guān)的業(yè)務(wù)不會(huì)取系統(tǒng)日期，而是取數(shù)據(jù)庫保存的賬務(wù)日期，所有需要使用賬務(wù)日期的任務(wù)跑批完成后，才會(huì)把數(shù)據(jù)庫保存的賬務(wù)日期切換到第二天。

面試官：采用輪詢路由策略，還可能帶來哪些問題呢?

我：還可能造成冥等的問題。比如一個(gè)任務(wù)的處理邏輯是，每隔兩分鐘從數(shù)據(jù)庫查詢 100 條狀態(tài)是“未處理”的數(shù)據(jù)進(jìn)行處理，處理完成后更新狀態(tài)為“已處理”。如果機(jī)器一上的任務(wù)還沒有執(zhí)行完成，機(jī)器二上的任務(wù)已經(jīng)開始調(diào)度，那很可能會(huì)把機(jī)器一上正在執(zhí)行的 100 條數(shù)據(jù)查出來重復(fù)處理。

面試官：這個(gè)問題該怎么解決呢？

我：我提供兩種解決思路：

• 第一，最簡單的方式就是采用單機(jī)執(zhí)行；
• 第二，增加一個(gè)中間狀態(tài)“處理中”，執(zhí)行查詢數(shù)據(jù)的時(shí)候采用排它鎖，查出后更新成中間狀態(tài)，提交事務(wù)后再執(zhí)行處理邏輯，處理邏輯執(zhí)行完成后更新成“已處理”

select * from xxx where statsu='未處理' limit yy,100 for update
update xxx set statsu='處理中' where id in(...)

面試官：那如果數(shù)據(jù)源不能加鎖呢？比如數(shù)據(jù)源是郵件、接口查詢。

我：可以對郵件或接口查到的數(shù)據(jù)唯一鍵進(jìn)行保存，把唯一鍵做數(shù)據(jù)庫主鍵，下一個(gè)任務(wù)可以根據(jù)主鍵做排除，再實(shí)現(xiàn)業(yè)務(wù)邏輯。

面試官：好的，恭喜你進(jìn)入下一輪...