資料庫備份的動态排程設計和思路

關于資料庫備份任務的優化，整體可做的改進就是以下幾個方面：

1. 1. 備份任務不應該同時觸發，如果有100個備份，都是在同一時間觸發，那應該是一種很糟糕的情況
   2. 備份任務的執行時間應該可控，比如有100個任務，那麼這些任務總體的起始時間和結束時間應該可控，如果截止時間不可控，那麼也是一種混亂狀态

在此之上，就是一些細節的改善了。之前介紹過一篇MySQL備份任務的文章

通用crontab接入任務排程的思考

總體來說，如果切入點是備份，其實直接接入celery不是一個很理想的方案，因為備份任務的執行時間一般都偏長，而且任務的執行結果很重要，如果沒備份或者備份任務重複執行，對于線上業務的影響還是很大的，是以對于celery的切入點建議有兩個：

1. 1. 1. 最好執行粒度是一些小任務，比如執行個簡單的腳本或者檢查。
      2. 執行的頻率和數量要多，通過大量的實踐來驗證會得到更多的思路。

在這個基礎之上，接入備份任務是一個相對自然的事情。 做到的一個折中就是通過crontab來觸發任務，而celery隻是支援了異步修改crontab的時間配置。是以目前來看，需要做到的深度定制就是任務的編排和時間的編排。 

目前基本就是靜态的處理，通過自定義的算法是可以支援的。換句話說，我要排程哪些任務都是提前做好配置，然後啟用排程器來完成排程分布。這些配置是靜态的，一成不變的。是以我們如果需要做得更好，更可控，我們需要引入動态排程。 

動态排程的意義是什麼，主要就是因為變化，可能的變化有：

1. 1. 1. 備份集個數的變化，如果發生變化，需要手工辨別
      2. 資料庫的資料量很可能随着時間的變化而變化，這個通過曆史的資料可能不夠準确
      3. 備份的結果集大小可能随着資料量的變化而變化
      4. 備份的時間區間也會随着手工排程觸發而産生變化，比如之前是1:30觸發，結果重新排程之後是2:30
      5. 如果有的任務是全新的，那麼它缺少一些必備的次元資料，比如曆史備份資料量，備份時間等

這些因素中，我們需要做一些改進，需要通過動态排程來滿足幾個大體的需求或者改進，而且這個改進目标要足夠清晰。 我這邊考慮了兩個：

1. 1. 1. 備份任務的編排，到底開啟幾個并行程序最佳
      2. 備份任務的區間，可以改進到什麼程度，比如之前是1：00-3:00，如果通過編排的方式，優化到1:30-2:30，那麼這就是一種可見的改進。

是以動态排程不光是啟用排程器，而是需要通過大量的計算來得到一個相對高效的執行計劃，然後通過曆史的執行記錄來不斷的校正，最終讓任務的執行高效可控，而且支撐一鍵式變化。

    這裡需要建立一類模型，首先是對于排程器中所做的算法實作，目前是基于備份時間來設計的，其實完全可以切換為另外一種機關形式，比如資料量，比如備份集大小等。

    第二類是對于排程基準的改進，如果新伺服器沒有曆史備份資料，我們可以根據預先設計的模型給予參考，比如備份1G需要1分鐘，這種粒度的資料配置是根據實踐和經驗共同組合完成的。有了基準模型，才能知道曆史的備份有沒有問題，有沒有明顯的排程問題。 同時，後續要接入備份配置的時候，也就有了相對準确的參考資料。

    第三類是對于曆史資料的分析，也是此次排程中的核心部分，那就是通過曆史資料的分析和計算，能夠得出初步的結論，比如開啟幾個并行最為合适，備份的時間視窗等。

    第四類是對于這個任務的排程，應該是自動觸發，需要通過事件或者門檻值的方式來觸發。盡可能保證不要無理由的頻繁變更，而是變更都在計劃内，改動幅度較小。