前言

先介紹下問題：

組內有十來臺機器，上面用 cron 分別定時執行著一些腳本和 shell 命令，一開始任務少的時候，大家都記得哪臺機器執行著什么，隨著時間推移，人員幾經變動，任務也越來越多，再也沒人能記得清哪些任務在哪些機器上執行了，排查和解決后臺腳本的問題也越來越麻煩。

解決這個問題也不是沒有辦法：

• 維護一個 wiki，一旦任務有變動就更新 wiki，但一旦忘記更新 wiki，任務就會變成孤兒，什么時候出了問題更不好查。
• 布置一臺機器，定時拉取各機器的 cron 配置文件，進行對比統計，再將結果匯總展示，但命令的寫法各式各樣，對比命令也是個沒頭腦的事。
• 使用開源分布式任務調度任務，比較重型，而且一般要布置數據庫、后臺，比較麻煩。

除此之外，任務的修改也非常不方便，如果想給在 crontab 里修改某一項任務，還需要找運維操作。雖然解決這個問題也有辦法，使用 crontab cronfile.txt 直接讓 crontab 加載文件，但引入新的問題：任務文件加載的實時性不好控制。

為了解決以上問題，我結合 cron 和任務管理，每天下班后花一點時間，實現一個小功能，最后完成了 gotorch 的可用版?？粗?GitHub 的 commit 統計，還挺有成就感的~

這里放上 GitHub 鏈接地址: GitHub-zhenbianshu-gotorch ，歡迎 star/fork/issue。

介紹一下特色功能：

• cron+，秒級定時，使任務執行更加靈活；
• 任務列表文件路徑可以自定義，建議使用版本控制系統；
• 內置日志和監控系統，方便各位同學任意擴展；
• 平滑重加載配置文件，一旦配置文件有變動，在不影響正在執行的任務的前提下，平滑加載；
• IP、最大執行數、任務類型配置，支持更靈活的任務配置；

下面說一下功能實現的技術要點：

文章歡迎轉載，但請帶上本文源地址：http://www.cnblogs.com/zhenbianshu/p/7905678.html，謝謝。

cron+

在實現類似 cron 的功能之前，我簡單地看了一下 cron 的源碼，源碼在 https://busybox.net/downloads/ 可以下載，解壓后文件在miscutils > crond.c。

cron 的實現設計得很巧妙的，大概如下：

數據結構：

1.cron 擁有一個全局結構體 global ，保存著各個用戶的任務列表；

2.每一個任務列表是一個結構體 CronFile， 保存著用戶名和任務鏈表等；

3.每一個任務 CronLine 有 shell 命令、執行 pid、執行時間數組 cl_Time 等屬性；

4.執行時間數組的最大長度根據 “分時日月周” 的最大值確定，將可執行時間點的值置為 true，例如 在每天的 3 點執行則 cl_Hrs[3]=true；

執行方式：

1.cron是一個 while(true) 式的長循環，每次 sleep 到下一分鐘的開始。

2.cron 在每分鐘的開始會依次遍歷檢查用戶 cron 配置文件，將更新后的配置文件解析成任務存入全局結構體，同時它也定期檢查配置文件是否被修改。

3.然后 cron 會將當前時間解析為 第 n 分/時/日/月/周，并判斷 cal_Time[n] 全為 true 則執行任務。

4.執行任務時將 pid 寫入防止重復執行；

5.后續 cron 還會進行一些異常檢測和錯誤處理操作。

明白了 cron 的執行方式后，感覺每個時間單位都遍歷任務進行判斷于性能有損耗，而且我實現的是秒級執行，遍歷判斷的性能損耗更大，于是考慮優化成：

給每個任務設置一個 next_time 的時間戳，在一次執行后更新此時間戳，每個時間單位只需要判斷 task.next_time == current_time。

后來由于 “秒分時日月周” 的日期格式進位不規則，代碼太復雜，實現出來效率也不比原來好，終于放棄了這種想法。。采用了跟 cron 一樣的執行思路。

此外，我添加了三種限制任務執行的方式：

• IP：在服務啟動時獲取本地內網 IP，執行前校驗是否在任務的 IP 列表中；
• 任務類型：任務為 daemon 的，當任務沒有正在執行時則中斷判斷直接啟動；
• 最大執行數：在每個任務上設置一個執行中任務的 pid 構成的 slice，每次執行前校驗當前執行數。

而任務啟動方式，則直接使用 goroutine 配合 exec 包，每次執行任務都啟動一個新的 goroutine，保存 pid，同時進行錯誤處理。由于服務可能會在一秒內多次掃描任務，我給每個任務添加了一個進程上次執行時間戳的屬性，待下次執行時對比，防止任務在一秒內多次掃描執行了多次。

守護進程

本服務是做成了一個類似 nginx 的服務，我將進程的 pid 保存在一個臨時文件中，對進程操作時通過命令行給進程發送信號，只需要注意下異常情況下及時清理 pid 文件就好了。

這里說一下 Go 守護進程的創建方式：

由于 Go 程序在啟動時 runtime 可能會創建多個線程(用于內存管理，垃圾回收，goroutine管理等)，而 fork 與多線程環境并不能和諧共存，所以 Go 中沒有 Unix 系統中的 fork 方法；于是啟動守護進程我采用 exec 之后立即執行，即 fork and exec 的方式，而 Go 的 exec 包則支持這種方式。

在進程最開始時獲取并判斷進程 ppid 是否為1 (守護進程的父進程退出，進程會被“過繼”給 init 進程，其進程號為1)，在父進程的進程號不為1時，使用原進程的所有參數 fork and exec 一個跟自己相同的進程，關閉新進程與終端的聯系，并退出原進程。

filePath, _ := filepath.Abs(os.Args[0]) // 獲取服務的命令路徑
cmd := exec.Command(filePath, os.Args[1:]...) // 使用自身的命令路徑、參數創建一個新的命令
cmd.Stdin = nil
cmd.Stdout = nil 
cmd.Stderr = nil // 關閉進程標準輸入、標準輸出、錯誤輸出
cmd.Start() // 新進程執行
return // 父進程退出

信號處理

將進程制作為守護進程之后，進程與外界的通信就只好依靠信號了，Go 的 signal 包搭配 goroutine 可以方便地監聽、處理信號。同時我們使用 syscall 包內的 Kill 方法來向進程發送信號。

我們監聽 Kill 默認發送的信號SIGTERM，用來處理服務退出前的清理工作，另外我還使用了用戶自定義信號SIGUSR2 用來作為終端通知服務重啟的消息。

一個信號從監聽到捕捉再到處理的完整流程如下：

1.首先我們使用創建一個類型為 os.Sygnal 的無緩沖channel，來存放信號。

2.使用 signal.Notify() 函數注冊要監聽的信號，傳入剛創建的 channel，在捕捉到信號時接收信號。

3.創建一個 goroutine，在 channel 中沒有信號時 signal := -channel 會阻塞。

4.Go 程序一旦捕捉到正在監聽的信號，就會把信號通過 channel 傳遞過來，此時 goroutine 便不會繼續阻塞。

5.通過后面的代碼處理對應的信號。

對應的代碼如下：

c := make(chan os.Signal)
signal.Notify(c, syscall.SIGTERM, syscall.SIGUSR2) 

// 開啟一個goroutine異步處理信號
go func() {
    s := -c
    if s == syscall.SIGTERM {
        task.End()
        logger.Debug("bootstrap", "action: end", "pid "+strconv.Itoa(os.Getpid()), "signal "+fmt.Sprintf("%d", s))
        os.Exit(0)
    } else if s == syscall.SIGUSR2 {
        task.End()
        bootStrap(true)
    }
}()

小結

gotorch 的開發共花了三個月，每天半小時左右，1~3 個 commits，經歷了三次大的重構，特別是在代碼格式上改得比較頻繁。 不過使用 Go 開發確實是挺舒心的，Go 的代碼很簡潔， gofmt 用著非常方便。另外 Go 的學習曲線也挺平滑，熟悉各個常用標準包后就能進行簡單的開發了。 簡單易學、高效快捷，難怪 Go 火熱得這么快了。

以上就是詳解Gotorch多機定時任務管理系統的詳細內容，更多關于Gotorch多機定時任務管理系統的資料請關注腳本之家其它相關文章！