作者：京東科技 文濤
背景
金融社區優惠文章是基于京東商城優惠商品批量化自動生成的，每日通過不同的渠道獲取到待生成的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 指令的定義：
| 屬性 | 說明 |
|---|---|
| breakPoint | 斷點標識 |
| rangeBegin | 邊界起 |
| rangeEnd | 邊界終 |
| startTime | 開始執行時間 |
| endTime | 結束時間 |
| lastExeTime | 最后一次執行時間 |
| exceptionTimes | 發生錯誤次數 |
| threadKey | 分布式任務執行緒標識 |
2 作業流程圖：
作業流程說明：
1 任務監測模塊負責周期性的監測現有任務執行情況及是否有新任務加入到任務串列中，
首先當拿到某個任務時，檢驗該任務最近活躍時間是否超出10分鐘（可配置），如果超出則認為當前任務因某種原因已經終止執行了，此時發送喚起任務執行的指令，
接著執行新任務監測，如果有新任務加入，則將該任務加入到任務串列中，此時不需要發出任務喚起指令，下次任務監測則會根據上述邏輯發出喚起指令
2 任務執行模塊收到指令后首先會校驗當前任務的合法性，然后再執行任務
合法性校驗點包括：
1）任務控制能力監測即相關開關監測
-
任務熔斷能力監測，例外資訊是否超出閾值，如果超出終止執行
-
任務防重監測，任務當前指令是否有其它執行緒在同時執行，如果有終止執行
執行的程序為：
1）任務采用異步執行緒池模式，收到執行指令(MQ)后立即開啟異步執行緒執行，防止單條指令執行時間太長
2）執行介面呼叫方法，分批滾動查詢待執行串列
3）回圈待執行串列，執行相應業務邏輯
4）串列中每執行完一條資料，就會記錄一下任務執行情況，用于作于例外中斷后（機器重啟），從斷點處繼續執行
5）任務發生例外記錄例外資訊
6）監測到任務真正執行完成，后發起redo指令，用于喚起下周期任務執行
目前效果
機器使用情況：微服務2臺
任務拆分情況：目前任務被拆分成了30個子任務，平均每個掃描30萬文章
實時性：1千萬文章發生一次監測耗時4小時，下游介面TPS700左右
安全性：大促或下游壓力大，可隨時停止或分時段執行
魯棒性：在微服務上線時，或介面呼叫例外時，任務產生中斷，但過10分鐘后，又會被從斷點處重新喚起，不需要人工干預
中間件壓力：復用調度和MQ等中間件但不拖累中間件，每天產生300條左右MQ訊息，每條訊息消費耗時10ms以內，每次心跳監測模塊（分布式任務執行）耗時200ms左右
擴展
該組件，可根據業務邏輯做任何相關業務處理，如監測到已下架或取消推薦的文章，判斷優惠存在時，依然可以做重新上架處理，不過此能力依賴業務系統配合
該組件目前缺少兩個能力
1 任務出錯后，可將錯誤資訊發送告警，可通過接入監控系統實作，提高組件的告警能力
2 如何動態控制任務拆分邏輯，比如覺得4小時監測不夠實時或太頻繁時，想動態調整任務分治的粒度目前未實作
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/542740.html
標籤：設計模式