Node.js躬行記（5）——定時任務的調試

　　最近作一個活動，須要用到定時任務，因而使用了 node-schedule 庫。

　　用法很簡單，就是可配置開始、結束時間，以及重複執行的時間點，以下所示，從2020-12-23T09:00:00Z開始，每10分鐘執行一次，直至2020-12-23T09:30:30Z結束。

schedule.scheduleJob({ 
  start: '2020-12-23T09:00:00Z', 
  end: '2020-12-23T09:30:30Z', 
  rule: '* */10 * * * *' 
}, test);

1、時間修改困難

　　若是是須要在將來某個時間段執行的定時任務，那麼要還原真實場景，就得修改服務器時間。

　　測試環境雖然能夠改時間，可是咱們這邊是幾個組共用幾臺服務器，修改了時間後，可能會影響其餘組的業務，而且正式環境的時間是不能修改的。

　　一開始測試的時候，改過幾回時間，改時間畢竟太繁瑣，每次代碼發佈，服務器的時間就又會重置，又要修正一次，還收到了其餘組的投訴。

　　後面就改爲今天的時間段，此次的定時任務的時間段有7個，每次修改好後，就要提交一遍代碼，而後合併分支，最後發佈一下代碼，服務也會從新啓動。

　　這種純手工方式過於費時，後面想到能夠在後臺作個通用配置（下圖是個配置列表），將這些常量（例如時間參數）存在數據庫（例如MongoDB或MySQL）中，可隨時讀寫。

 　　

　　下圖是個增和改的彈框，在新增的時候須要格式化多行文本中的JSON數據，先用 eval()，再用JSON.stringify()，這樣的話在調用JSON.parse()的時候就不會出錯。

JSON.stringify(eval(`(${values.content})`))

　　

　　爲了讓JSON數據的展現更友好，就須要格式化數據，也就是要有空格。

JSON.stringify(JSON.parse(record.content), null, 2)

2、錯誤查看困難

　　在測試環境或正式環境，若是定時任務處理的數據錯誤了，那麼只能經過日誌來排查。

　　而一臺跑着的服務器中會有不少其餘的定時任務，在測試環境中，爲了能看清楚日誌，能夠只運行一個任務。

　　可是在正式環境中，是不能中止任務的，像目前運行的定時任務，可能幾秒內就有幾百行的日誌，用肉眼觀察有點累。

　　好在咱們這邊接入了阿里雲的日誌服務，能夠查看日誌控制檯，裏面有豐富的查詢過濾條件，能夠準確的定位到某條日誌。

　　

　　若是你有更好的調試方法，歡迎留言討論。

3、應急處理

　　在線上運行的時候，可能會由於這個那個的問題致使任務沒有在指定時間運行。

　　那麼就得開放一個入口，來手動執行這個任務。

　　一開始的想法是寫個臨時接口，而後用postman手動訪問，不過這樣的話對運營不太友好，畢竟運營會有人半夜值班盯着活動，但開發人員是不會半夜還盯着服務器的。

　　因而又快速搭了個後臺執行頁面，有個下拉框可選擇任務時間段，還有個運行按鈕，到時候出問題的話，就手動運行一次。