　　最近做一個活動，需要用到定時任務，於是使用了 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);

一、時間修改困難

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

　　測試環境雖然可以改時間，但是我們這邊是幾個組共用幾台服務器，修改了時間後，可能會影響其他組的業務，並且正式環境的時間是不能修改的。

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

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

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

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

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

　　為了讓JSON數據的展示更友好，就需要格式化數據，也就是要有空格。

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

二、錯誤查看困難

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

　　而一台跑着的服務器中會有很多其他的定時任務，在測試環境中，為了能看清楚日誌，可以只運行一個任務。

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

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

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

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

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

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

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