xxl-job的一些感悟與規範
後台計劃任務設計思路：
- 日誌埋點處理，便於prd排查問題
- 2種主動job搭配規範（正向job、反查job）
- 1種消息接收的處理規範，重試機制，返回狀態
- job開關維度
- 數據流圖
- 線上暗job-便捷性-工具job
- 處理流水表的設計
- 分散式多副本考慮
一一說來
日誌埋點處理，便於prd排查問題
prd環境由於會受到嚴格管控，因此不可能讓你idea直接連接jvm instance調試，一般來說，都是需要通過查數據或者查日誌來看有沒有執行，執行有沒有報錯，怎樣的報錯
也就是說此時的日誌資訊越完善越好，並且人類看了需要顯而易懂，不需要倒騰來倒騰去，這樣的日誌資訊給到的話，對開發人員來說是最友好的
因此埋點很重要，日誌資訊要詳盡，越詳盡越好，比如搜索出來的List size這些資訊都要有，而不光是錯誤日誌，記住越詳盡越好，每個if/else節點的記錄都要有
上面是記錄，也就是日誌埋點要想盡，但是人類需要interface才能查看到這些日誌資訊，因此日誌的搜索也很重要，如：kibana等，因此針對kibana設計日誌格式也很重要，日誌記錄時就要考慮到查看的友好性，不要日誌記了，就是不好查。。。就麻煩了
也可以是日誌記錄歸記錄，中間加個處理切分豐富日誌的表示環節也可以，到查看端能更易且更豐富的表現形式。
避免由於日誌不詳盡導致需要重新發布程式才能細化查問題現象出現。
2種主動job搭配規範（正向job、反查job）
當需要和三方系統做對接時，一般是我方get/post請求到對方系統，這個調用方式我稱為正向調用
如果出現網路不通、或者對方系統正在發布而500報錯了怎麼辦？
如果調用結果返回的是部分完成狀態怎麼辦？比如我方系統把訂單post到三方做業務，對方系統可能做了半同步半非同步拆分，導致返回的業務狀態為：部分完成。
而我們的系統依賴於這個業務返回完整完成狀態後才能進行後續操作，同時我們也不想重複post訂單到對方系統時，怎麼辦？
這時引入反查job，專門用來定時到對方系統查詢業務最新狀態（此時依賴對方系統有這種業務查詢api供我方調用）
也就是寫2個job，管你是否存在網路問題啥的，統統能考慮的到（對方系統api需要提供+自身狀態機的流轉（如網路不通時就不應該讓反查job查了，因為根本還沒有post訂單過去））
1種消息接收的處理規範，重試機制，返回狀態
有時，對方系統會主動通知業務的狀況，可能是一次性的也可能是對方系統用了定時器定期推送的
此時，就需要和對方對應好是怎樣的通知機制了，多次通知，可能需要做冪等
也可能約定好我方系統返回怎樣的json內容，對方將終止推送等等
此時冪等必須要做了，因為從設計角度講，總是需要將外部系統設定為不可靠系統對待。
job開關維度
大點的系統，job肯定是很多的，不同模組都好多job，有的會考慮把所有相關的job都合併起來處理
我說的合併是指1個job里，撈出一個大的List集合，然後分別foreach item，再循環內部判斷這個item需要執行怎樣的子job
當然上述是1個維度
還有個維度，就是盡量拆分子job到獨立job里，單獨變化，單獨執行，要開要關都獨立進行，沒有job層面的依賴性（當然，數據層面必須會存在依賴先後順序）
這個時候一般來說會拆分job，這樣上了prd，會很方便的stop、start、臨時execute某個具體job，不會說由於突發業務，或者突發異常，導致執行大job而產生一大堆job跑，或者說需要改數據才行，不太方便
job拆分後，很可能越拆越細，如果後續拆到獨立docker中跑某幾個job，大job就得改，麻煩
數據流圖
job一多，其實對開發本身就越來越混淆了，再加上正向、反查job、工具job等，以及狀態機這種依賴，確實需要設計圖用來記錄，幫助開發人員理解這些job
流程圖（也包括跨系統的流程圖）+數據流圖
線上暗job-便捷性-工具job
其實上了生產環境後，很多時候系統還不太完善，有些小工具job還是要做的，比如紅沖這種，可能需要做成job，並且要job能接收參數，要能臨時紅沖某筆訂單等
這些其實很常見
處理流水表的設計
針對每筆業務的變動、每個三方api請求的參數、以及返回的response，都要記錄到流水表中記錄下來，這個和普通日誌埋點又有區別
- 日誌埋點一般來講不是結構化的，都是文本類型，對搜索不太友好
- 日誌一般來講，運維會在一定時間刪除的，如：3個月
- 對重要數據的變動必須要記錄到流水表中
- 流水表必須只insert，不update，不query的，因為表會越來越大；如果流水表不是mysql表，則另外的思路。
- 流水表關鍵資訊是長時間完備的
分散式多副本考慮
誰家的prd不是2副本以上？
因此得考慮job的並發問題、xxl-job能較好的解決並發問題，小概率的高並發在job層面不太多，實在出現了，就分散式鎖搞定。
job其實水也挺深，但是有了最佳實踐，就會好很多，你說呢
