這段時間雖然因為疫情導致原本的一些工作有了延后，但是整體來說，大方向的事情還是基本成為定數。

[[321414]]

如果讓我來選擇今年要做的幾件事情，我覺得有三股清流是需要關注的，也就是說不單單從技術層面來考慮，而是綜合業務使用場景和整體的演進過程。

第一股清流就是備份恢復，似乎在這些年被淡忘了，淡忘了還好，一旦要記起來的時候基本就來不及了，你會發現所有你能想到的優化的地方都是一篇荒漠，基于云環境確實提供了一些便利和穩定性，但是不代表你不需要做投入去完善和補充。如何能夠更高效的完成備份，使用性價比最好的存儲模式，穩定可控的恢復效率，應該是我們需要持續不斷迭代改進備份恢復方向工作的大目標。在任何優先級面前，備份恢復可能在業務層代表的含義是很單薄的，但是這是數據生死攸關的大事，請先把它放在最基礎緊要的工作里面。

第二股清流就是高可用，我們有傳統概念中理解的高可用，也有基于分布式環境的高可用方案，高可用代表著我們的后端服務不是死板的，動不得的，而是在保證業務可用的前提下，實現業務和系統的可用性。高可用可做的事情非常多，不同階段對標的目標也大不相同，如何換句話說，我們可以不用苛求數據庫層100%的可用，而結合業務層，基于幾秒的閃斷來換取業務服務真正的高可用，其實可做的事情很多，改進的空間也一下子大了許多。

第三股清流就是數據流轉，數據流轉是一個較大的體系，數據遷移算是其中的一個子集。如何能夠讓數據流進來，走出去，實現環境間，異構環境間的數據同步，提供多維度，近實時的數據訪問，算是把原來散亂的數據盤活了。數據流轉可以打破很多技術層面的壁壘，能夠提供鞥更多更加靈活的數據側解決方案。

當然有的同學說這三個任務是不是太簡單了。我們可以在此基礎上做一些擴展和補充說明，讓這三股清流更加清晰一些。

備份恢復，毫無疑問我們要先改善已有的備份效率和存儲，在備份方式上，實現一次全量，永遠增量的目標，而對于增量方案，不局限于已有的增備方案，還需要充分結合binlog方案，實現全量+增量+binlog三者有效結合的快速恢復方案，在基于binlog的數據閃回方向上能夠做深做細，使得數據可恢復性更加靈活，比如提供自助的數據恢復服務，在數據采集方面，基于binlog側的備份可以逐步沉淀成為binlog集市，而基于集市的方案也為后續的數據流轉可以打好基礎。備份恢復不是呆板的，而是可以提供其他維度的功能，比如我們可以基于快照設計的思想來快速恢復某一個數據庫，然后在上面做真實數據量的業務壓力測試或者是SQL優化服務。

高可用，如果實現了同機房，跨機房的高可用方案，那么后面需要做的事情就是盤活高可用方案的發展空間，比如我們原本認為的高可用就是數據庫層老老實實，不要動，在滿足高可用目標的前提下，數據庫層可以更加主動，比如可以實現更加平滑的在線升級，實現秒級業務閃斷的服務快速切換，實現秒級別的服務切換和跨機房高可用方案。在這方面需要顛倒我們固化的高可用認知，而選擇更加主動，具有彈性的高可用方案。

數據流轉，同類型數據間同步和異構數據間同步是我們需要打通的部分，數據的流動性也能夠反映出業務側相應的成熟度，我們可以在流轉的采集側進行數據的實時提取，然后基于binlog服務或者binlog集市實現數據的實時消費，在環境間維護中引入數據生命周期管理，能夠實現基于版本化的管理模式，基于業務使用模式，實現緩存，持久化存儲，文件存儲等多個維度的數據存儲方案，能夠讓數據的接入成本更低，通過數據關聯發掘更多的數據價值。