作者：京東科技 文濤

背景

金融社區優惠文章是基於京東商城優惠商品批量化自動生成的，每日通過不同的渠道獲取到待生成的SKU列表，並根據條件生成優惠文章。

但是，生成優惠文章之後續衍生問題：

該商品無優惠了，對應文章需要做取消推薦或下架處理，怎樣能更快的知道該商品無優惠了呢？

方案介紹

方案對比

方案1

承接該商品所有變更信息的消息，發生變更後二編文章。

優點：

實時，一旦變更立刻知道並更新文章。

缺點：

1 開銷大，是要承接的消息多，可能100台機器也不一定能承接（億級變更）。

2 耦合高，需要對接的業務方多，全部對接需要很長的周期及人力，同時對方發生業務變更需要通過人員同步更新邏輯。

方案2

通過任務輪訓文章，調外部介面判斷該商品是否有優惠，之後做相應的處理。

優點：

1 業務模型較簡單，只需要判斷是否有優惠或優惠變更即可。

2 優惠側投入較小，只需要投入調度任務的機器即可。

缺點：

不實時，數據量大了，對任務的實時性是個挑戰。

方案3

針對方式2的缺點，我們推出了【可伸縮自動任務】 + 【首次曝光監測】的組合模式。

即自己實現分散式調度增強，提高數據處理能力，提高調度魯棒性、自動化等能力，同時採用首次曝光監測的方式，利用用戶訪問文章時判斷是否有優惠，並做相應取消推薦或文章下線處理

優點：

1 較實時，第一批被推薦推到C端用戶的文章有可能會看到無優惠兜底方案，其它人便不再被推送。

2 方式2的優點

缺點：

需要實現可伸縮自動任務組件

至此，如何保證千萬量級的優惠文章監測優惠變更不至於周期太長成了難點。

接下來介紹可伸縮任務組件，是如何解決上述問題的：

可伸縮任務組件

關鍵能力

我們希望組件擁有的能力

•任務自動化，結束自動重新執行

•任務魯棒性強，意外中斷可從斷點處重新喚起

•任務可分治，可利用線程池及分散式集群將整體任務拆分成多個子任務執行

•任務可擴展，具備新任務探測能力

•任務可熔斷，可以監測連續異常並終止執行

實現

名詞解釋

任務指令：觸發某個任務的一條指令信息

任務開關：控制整體任務執行情況，如：停止執行，分時段執行等

redo指令：當任務執行完成後，發出的重做指令

任務監測：負責監測任務執行情況，根據任務狀態處理任務

實現思路

能否復用現有中間件？如：分散式任務，消息隊列等

答案是可以，並且個人覺得最好是優先利用中間件能力，並將中間件的能力定義成組件的可擴展能力，方便中間件替換，提高組件的通用性

如果使用現有中間件實現該如何實現？

傳統思路：

分散式任務負責查詢全量文章，將查詢結果發送MQ，消費者消費單條消息，併進行業務處理

那麼問題來了，

1 查詢一輪任務需要多長時間呢？隨著文章量的增加，調度周期設置多少合適呢？

2 MQ的消息將海量

顯然這種方式不太適合數據量大的情況

那麼我們的思路是：

1 將分散式調度抽象成一個心跳監測模塊，用於監測任務狀態，以及探測新任務，這樣任務執行周期固定10min即可，任務執行時間也不會太長（實際執行時間200ms左右）

2 將MQ抽象成任務指令的載體，用於發送指令，接收指令，利用分散式的能力處理任務

3 將千萬級的一次查詢，拆分成多個查詢，縮小單次指令執行的周期，將千萬級文章信息同步至ES，使用ES的滾動查詢能力，在執行單次任務時，可滾動查詢10-20萬的文章

4 將分散式共識組件用作開關能力，用於控制組件執行，在大促或下游壓力過高時動態控制任務執行

5 將Redis用於任務信息存儲和分散式指令防重

至此，我們使用到了分散式調度、消息隊列、Redis、分散式共識、ES等中間件能力。

實現方案

1 指令的定義：

2 工作流程圖：

工作流程說明：

1 任務監測模塊負責周期性的監測現有任務執行情況及是否有新任務加入到任務列表中。

首先當拿到某個任務時，檢驗該任務最近活躍時間是否超出10分鐘（可配置），如果超出則認為當前任務因某種原因已經終止執行了，此時發送喚起任務執行的指令。

接著執行新任務監測，如果有新任務加入，則將該任務加入到任務列表中。此時不需要發出任務喚起指令，下次任務監測則會根據上述邏輯發出喚起指令

2 任務執行模塊收到指令後首先會校驗當前任務的合法性，然後再執行任務

合法性校驗點包括：

1）任務控制能力監測即相關開關監測

2. 任務熔斷能力監測，異常信息是否超出閾值，如果超出終止執行

3. 任務防重監測，任務當前指令是否有其它線程在同時執行，如果有終止執行

執行的過程為：

1）任務採用非同步線程池模式，收到執行指令(MQ)後立即開啟非同步線程執行，防止單條指令執行時間太長

2）執行介面調用方法，分批滾動查詢待執行列表

3）迴圈待執行列表，執行相應業務邏輯

4）列表中每執行完一條數據，就會記錄一下任務執行情況，用於作於異常中斷後（機器重啟），從斷點處繼續執行

5）任務發生異常記錄異常信息

6）監測到任務真正執行完成，後發起redo指令，用於喚起下周期任務執行

目前效果

機器使用情況：微服務2台

任務拆分情況：目前任務被拆分成了30個子任務，平均每個掃描30萬文章

實時性：1千萬文章發生一次監測耗時4小時，下游介面TPS700左右

安全性：大促或下游壓力大，可隨時停止或分時段執行

魯棒性：在微服務上線時，或介面調用異常時，任務產生中斷，但過10分鐘後，又會被從斷點處重新喚起，不需要人工干預

中間件壓力：復用調度和MQ等中間件但不拖累中間件，每天產生300條左右MQ消息，每條消息消費耗時10ms以內，每次心跳監測模塊（分散式任務執行）耗時200ms左右

擴展

該組件，可根據業務邏輯做任何相關業務處理，如監測到已下架或取消推薦的文章，判斷優惠存在時，依然可以做重新上架處理，不過此能力依賴業務系統配合

該組件目前缺少兩個能力

1 任務出錯後，可將錯誤信息發送告警，可通過接入監控系統實現，提高組件的告警能力

2 如何動態控制任務拆分邏輯，比如覺得4小時監測不夠實時或太頻繁時，想動態調整任務分治的粒度目前未實現