定時任務

定時任務

三豐 soft張三丰

常見的定時任務處理方式有線程的while(true)和sleep組合、使用Timer定時器觸發任務又或者是使用quartz框架。這些傳統的定時任務處理方式面臨以下幾個方面的挑戰：
Ø 高可用
單機版的定時任務調度只能在一臺機器上運行，若是程序或者系統出現異常就會致使功能不可用。雖然能夠在單機程序實現的足夠穩定，但始終有機會遇到非程序引發的故障，而這個對於一個系統的核心功能來講是不可接受的。
Ø 多任務管理複雜，系統負載不均
一個系統可能會有不少須要定時執行的任務，當出現單機沒法承載全部的任務時，通常會簡單地進行拆分，讓不一樣的機器各自分配必定數量的任務。在這種方式下，須要由開發人員人工管理和分配各個機器上所負責運行的任務，新的任務的加入，須要從新考慮各個機器的負載併合理安排任務分配，以保證總體集羣負載均衡。這種方式對開發人員的心智負擔過於沉重，而且可能由於人工分配的不合理而形成系統負載不均。
Ø 單機處理極限
本來1分鐘內須要處理1萬個訂單，可是如今須要1分鐘內處理10萬個訂單；原來一個統計須要1小時，如今業務方須要10分鐘就統計出來。能夠經過多線程、單機多進程處理來提升單位時間的處理效率。可是，單機畢竟資源有限（CPU、內存和磁盤等），始終會有單機能力處理不過來的狀況。
架構設計採用分佈式任務調度平臺來實現定時任務。它的設計思想爲：將調度行爲抽象造成「調度中心」公共平臺，而平臺自身並不承擔業務邏輯，「調度中心」負責發起調度請求；將任務抽象成分散的JobHandler，交由「執行器」統一管理，「執行器」負責接收調度請求並執行對應的JobHandler中業務邏輯。「調度」和「任務」兩部分能夠相互解耦，提升系統總體穩定性和擴展性。

單體調度
定義
一個集羣中只有一個節點運行調度進程，該調度進程負責集羣資源管理和任務調度，也就是說單體調度器擁有全局資源視圖和全局任務
特徵

1. 容易實現對做業的約束並實施全局性的調度策略，所以適合批處理任務和吞吐量較大、運行時間較長的任務
2. 容易進行狀態同步，而且很穩定
3. 調度算法所有內置在覈心調度器中，所以調度框架的靈活性和策略的擴展性不高，可是調度算法能夠擴展甚至自定義
4. 存在單點故障的可能性
   應用
   Google Borg/Kubernetes
   兩層調度
   定義
   資源的使用狀態同時由中央調度器和第二層調度器管理，中央調度器從總體上進行資源的管理和分配，將資源分配到第二層調度器；再由第二層調度器負責將資源和具體的任務進行配對，所以第二層調度能夠由多個調度器以支持不一樣的任務類型
   Mesos調度架構
   架構圖
   
   Resource Offer機制：Mesos Master主動將節點空閒資源，以相似發放的形式發送給每一個框架，若是框架須要則使用，不須要則歸還
   資源分配算法
   最大最小公平算法
   
   主導資源公平算法
   

共享狀態調度
架構圖

State Storage模塊負責存儲和維護資源以及任務狀態
Resource Pool爲多個節點集羣，接收並執行Scheduler調度的任務
Scheduler值包含任務調度操做
舉例：Google Omega

併發控制
樂觀併發控制：在樂觀併發控制中，用戶讀取數據時不鎖定數據。當一個用戶更新數據時，系統將進行檢查，查看該用戶讀取數據後其餘用戶是否又更改了該數據。若是其餘用戶更新了數據，將產生一個錯誤。通常狀況下，收到錯誤信息的用戶將回滾事務並從新開始。對應於樂觀併發調度，強調時候檢測，在事務提交時檢查是否避免了衝突，若避免則提交，不然回滾並自動從新執行
悲觀併發控制：一個鎖定系統，能夠阻止用戶以影響其餘用戶的方式修改數據。若是用戶執行的操做致使應用了某個鎖，只有這個鎖的全部者釋放該鎖，其餘用戶才能執行與該鎖衝突的操做。對應於悲觀併發控制，強調事前預防，在事務執行時檢查是否會存在衝突，不存在，則繼續執行，不然等待或回滾
總結對比