大數據

AntScheduler之時間簡史

時間簡史

1.png
日出而作,日落而息。從古至今我們都有著強烈的時間觀念,時間對我們來說至關重要,小到個人日常起居、時間安排,大到國家儀式談判的時間分秒無差。 早在史前20000年,人類就開始以在木棍和骨頭上刻標記的方式來計時,關注一朝一夕的時間變化。
如影視節目看到的,我們瞭解的古代報時方式常見的有雞鳴、打更、鐘鼓。如 《晉書·祖逖傳》記載:
“中夜聞荒雞鳴,蹴琨覺,曰:‘此非惡聲也。’因起舞。”
這個便是我們熟悉的聞雞起舞的故事,祖逖通過雞鳴的叫聲提醒和告知自己要起床練劍。可以看出祖逖自律性格和遠大報復,也說明雞在當時是一個日出雞鳴的時間表示,一種常用報時動物。時至今日,在偏遠的山區同樣採用古老的雞鳴方式開啟新的美好一天。
影視作品裡經常看到的就是一個在深夜中提著小燈籠,漫步大街小巷裡打著梆子,喊著“天乾物燥,小心火燭!”的更夫。在古代,人們缺少精確的報時手段,晚上的報時就幾乎全靠打更了。古代將夜晚分為五個時段,常用鼓打更報時,所以叫作五更、五鼓。如詩句有云:"深山五鼓雞吹角,落月一窗鵝打更"。

2.png
3.png

晨鐘暮鼓,很多城市都有鐘樓鼓樓,他們在歷史上起著報時的作用。 看過《長安十二時辰》的人,都會對它以鼓傳信、快捷酷炫的信息傳遞系統——望樓系統記憶猶新。而望樓的雛形之一卻是鐘鼓樓,主要用於報時的建築物。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/dd97b69668c04f6d97b34adbd64f4ab6.png)

5.png

中國古代另一種常見的計時工具就是日晷,捕捉時間的影子,記錄著時間的軌跡。隨著整個工業的發展和科技的進步,人們對時間的掌握越來越精細,希望對時間提示要求也越來越精確。西方開始出現鐘樓,它們經常出現在教堂之中,以更加精確的方式計時。近代隨著石英(quartz)等材料的發現,出現了石英鐘,後來逐漸演變現代電子手錶等。 用過 java 調度框架的人都知道著名的開源調度框架quartz, 就是負責精準調度,像石英鐘一樣精確提示你時間。
從整個人類發展歷程看,人類對時間的掌握越來越精細,從天到毫秒到微秒;人類也對於時間的提示越來越關注,甚至毫秒不能偏差。印象最深的是《我和我的祖國》中再現香港迴歸祖國,需要保證7月1日0點0分準時升起,一秒鐘不能早,一秒也不能少。“一秒都不差”是我們的底線,“一刻也不能分”是我們原則。

定時調度簡史

時間對於人類來說一直是一個非常重要和寶貴的東西,大到國家尊嚴,小到個人守時。回到互聯網,從整個計算機發展過程中,我們也可以看到系統對於時間效率有極高的要求,追求提高資源利用率,提高系統性能。從最早穿孔卡片手動操作,到批處理系統,再到實時系統,也是一步步再優化系統響應時間,提高性能的過程。實時系統就是一個任務調度系統,負責任務切換和調度。實時系統以時間片為單位,以時間片輪轉策略為例,當進程一個時間片執行完成後,系統將重新分配時間片將並置於就緒隊列尾。
從業務系統或基礎組件中,我們也時常存在著定時調度的訴求。常見的有銀行的日切,希望在特定時間開始一天的日切任務;系統中定時指定特定的任務,例如計量計費統計時,每小時統計一次用戶使用情況,並將數據上報給計費系統。這樣的例子很多,也說明了定時調度在現代系統開發過程中起著舉足輕重的作用。如果未能及時調度則導致延遲打款等,造成資損和社會輿論。

單機定時調度
如果只考慮單機定時任務調度,則有很多選擇。比如使用linux 自帶的 crontab 配置定時任務,定時調度腳本、接口完成調度工作。 在java 中也可以使用 ScheduledExecutorService 定義間隔定時任務、或是使用 spring-scheduler 定時調度。

單機定時調度只關注應用在單臺機器的執行情況,一般是應用內容定時任務。但如果整個集群裡只希望被調度一次,單機定時調度則不能滿足需求,則需要尋找分佈式調度。

分佈式定時調度
在考慮高可用場景下,業務應用一般都是分佈式部署。但業務集群希望只能被調度一次或特定次數。避免每臺機器都執行定時任務,導致數據爭搶、重複執行等現象。例如每小時統計計量數據並上報到阿里,如果每臺機器都執行定時任務則需要考慮如何按機器區分數據處理的數據問題;或者就面臨爭搶、重複上報現象。所以依賴外置的定時服務調用,並配置域名(https)、RPC或slb等機器完成集群間的路由。
6.png

業務機器可以通過外置的方式解決自身高可用的定時調度需求,而定時調度器如果只是一個單機模式也會存在高可用問題。也需要對定時調度器進行分佈式部署,於是就會變成:
7.png

分佈式調度也有很多現成的服務框架,例如最經典的quartz, easy-task、xxj-job 等。 分佈式調度場景下需要考慮的核心問題是:
任務只能被一個觸發器調度,並下發給業務機器。避免多臺機器重複調度,調度業務機器多次。
如何做到高可用,單臺觸發調度器宕機後如何平滑遷移到其他機器而不發生漏觸發。
如何橫向拓展,如果任務真多後通過擴展機器就可以分攤其他機器的調度負載。

Leave a Reply

Your email address will not be published. Required fields are marked *