? robfig/cron是GO語言中一個定時執行注冊任務的package, 最近我在工程中使用到了它，由于它的實作優雅且簡單(主要是簡單)，所以將原始碼過了一遍，記錄和分享在此，
檔案：http://godoc.org/github.com/robfig/cron，repo: https://github.com/robfig/cron
-
基本玩法
Demo代碼如下，先用cron.New()初始化一個實體，然后呼叫AddFunc(spec string, cmd func()) 注冊你希望呼叫的func，第一個引數為調度的時間策略，第二個引數為到時間后執行的方法，robfig/cron支持非常多樣的時間策略(下面的代碼舉了一些例子)，最后通過cron.Start()方法啟動，
func TestCronDemo(t *testing.T) { c := cron.New() // 通過AddFunc注冊 c.AddFunc("30 * * * *", func() { fmt.Println("Every hour on the half hour") }) c.AddFunc("30 3-6,20-23 * * *", func() { fmt.Println(".. in the range 3-6am, 8-11pm") }) c.AddFunc("CRON_TZ=Asia/Tokyo 30 04 * * *", func() { fmt.Println("Runs at 04:30 Tokyo time every day") }) c.AddFunc("@every 5m", func() { fmt.Println("every 5m, start 5m fron now") }) // 通過AddJob注冊 // var cJob cronJobDemo // c.AddJob("@every 5s", cJob) // 啟動 c.Start() // 停止 c.Stop() } ? type cronJobDemo int ? func (c cronJobDemo) Run() { fmt.Println("5s func trigger") return }
上面代碼中，第9、10行的代碼呼叫方法AddJob(spec string, cmd Job)也可以實作AddFunc注冊的功能，Job是interface，需要入參型別實作方法：Run()，實際上，方法AddFunc內部將引數cmd 進行了包裝(wrapper)，然后也是呼叫方法AddJob進行注冊，
后面介紹都會說成AddJob，等效于AddFunc，
-
AddJob后發生了什么? (主要的資料結構)
對于Cron的整體邏輯，最關鍵的兩個資料結構就是struct Entry和Cron，
每當你用AddJob注冊一個定時呼叫策略，就會為這個策略生成一個唯一的Entry，不難想象，Entry里會存盤被執行的時間、需要被調度執行的物體Job，
生成entry后，再將entry放到struct Cron的entry串列里，Cron的結構里，主要是一些用來和外部互動的channel，比如通過channel添加、洗掉entry等，詳見下面的代碼，
// Entry 資料結構，每一個被調度物體一個 type Entry struct { // 唯一id，用于查詢和洗掉 ID EntryID // 本Entry的調度時間，不是絕對時間，在生成entry時會計算出來 Schedule Schedule // 本entry下次需要執行的絕對時間，會一直被更新 // 被封裝的含義是Job可以多層嵌套，可以實作基于需要執行Job的額外處理 // 比如抓取Job例外、如果Job沒有回傳下一個時間點的Job是還是繼續執行還是delay Next time.Time // 上一次被執行時間，主要用來查詢 Prev time.Time // WrappedJob 是真實執行的Job物體 WrappedJob Job // Job 主要給用戶查詢 Job Job } // Cron 資料結構，為robfig/cron的運行物體使用的s資料結構 type Cron struct { entries []*Entry // 調度執行物體串列 // chain 用來定義entry里的warppedJob使用什么邏輯（e.g. skipIfLastRunning） // 即一個cron里所有entry只有一個封裝邏輯 chain Chain stop chan struct{} // 停止整個cron的channel add chan *Entry // 增加一個entry的channel remove chan EntryID // 移除一個entry的channel snapshot chan chan []Entry // 獲取entry整體快照的channel running bool // 代表是否已經在執行，是cron為使用者提供的動態修改entry的介面準備的 logger Logger // 封裝golang的log包 runningMu sync.Mutex // 用來修改運行中的cron資料，比如增加entry，移除entry location *time.Location // 地理位置 parser ScheduleParser // 對時間格式的決議，為interface, 可以定制自己的時間規則， nextID EntryID // entry的全域ID，新增一個entry就加1 jobWaiter sync.WaitGroup // run job時會進行add(1)， job 結束會done()，stop整個cron，以此保證所有job都能退出 }
需要注意的是，WrappedJob和chain這兩個成員，這是Cron實作的Job封裝邏輯，目前是解決實際調度Job的例外處理，比如你希望自己的上一個時間點的JobA沒有結束，下一個時間點的JobA就不執行，這個“不執行”的邏輯實作就定義在chain，初始化時通過chain將JobA進行封裝寫入WrappedJob，那么每次JobA呼叫前會先執行封裝邏輯，進行判斷，-
Start后發生了什么? (程式的主體)
cron.Start()執行后，cron的后臺程式（方法run()）就開始運行了，而它的主體，就是一個定時器的實作和到時后的job運行，加上cron里的資料維護，
cron的定時器實作是一個簡潔而典型的業務層實作，著重了解下，具體的流程圖可見下圖，
它的關鍵和值得學習之處是：
-
- 每個entry都包含自己下一次執行的絕對時間
- 先對entries按下次執行時間升序排序，只需要對第一個entry啟動定時器
- 定時器到時，只輪詢entries里需要執行的entries，不需要全部輪詢，
- 且 執行的是當前時間之前的所有job，容錯高；
- 第一個定時器處理結束開啟下次定時器時，也只需要更新執行過的entries的下次執行時間，不需要更新所有的entries
上面的邏輯說完，程式主體已經清晰，除此之外，程式主體里的定時器監聽和其他多個channel共用了select-case，這些channel在struct Cron里能看到，實作了entries的動態添加、洗掉、entries快斬訓取等功能，代碼結構如下：
將這些操作通過channel讓程式主體來操作，可以有效的減少互斥鎖的使用，也會引入問題，會導致有的job執行時間不是非常精準，導致某些entry被遺漏：
-
- 比如最近的jobA的timer在1ms后就要到時，此時加入一個entry，耗時3ms
- 添加完entry后，再重新啟動timer(還是jobA的timer，此處還利 用了golang的time.NewTimer(d Duration)的入參為負數會立即到時的特點)
- 下次到時的時間必然不是jobA期待的執行時間（理論上晚了2ms）
當然，channel的操作首先是非常簡潔省時的，其次，定時器實作里，會掃描所有當前時間之前的entries來執行，增加了容錯性
-
值得稱贊的細節
-
interface的使用
struct Entry里的Schedule和Cron里的ScheduleParser都是interface，意味著我們是可以自己定制注冊job時的時間策略的格式的，只要自己實作時間策略的決議和獲取方法就好
這讓我想起了以前看過golang里什么時候用interface和struct的討論，我覺得這是個很好的例子：預期對同一個介面有多個實作時就抽象成interface，不知道該不該用就用struct，
-
wrapper的實作
上面有提到，通過對Job的封裝，cron實作了同一個job多次呼叫時的例外處理等，值得以后在實踐中借鑒，
最后是我加了一點注釋的代碼，https://github.com/jiangz222/cron/tree/comments-v3
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/41215.html
標籤：其他