作者：京東科技 文濤
背景
金融社群優惠文章是基於京東商城優惠商品批次化自動生成的，每日透過不同的渠道獲取到待生成的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小時監測不夠實時或太頻繁時，想動態調整任務分治的粒度目前未實現