摘要：遷移&容災是數據庫的強需求，傳統的遷移&容災技術已經發展多年，隨着雲時代的來臨，在遷移&容災的使用場景、網絡、技術都有很大的變化，如何在雲時代下更簡單的實現數據庫的遷移&容災，雲廠商如何通過新的技術實現彎道超車，本文中阿里雲智能數據庫產品事業部高級技術專家付大超就爲大家分享了阿里雲在此領域的技術新進展和應用。
專家簡介：付大超（花名：千震），阿里雲智能數據庫產品事業部高級技術專家，2012年加入阿里巴巴，目前負責DTS&DBS團隊和研發，在阿里雲提供遷移、同步和容災的服務，支持阿里巴巴、螞蟻、阿里雲等異地多活單元化架構，曾負責阿里全球最大的HBase集羣的開發和維護工作，曾先後工作於IBM、Cisco。
直播回放
鏈接：https://yq.aliyun.com/live/1048
議題PPT下載，戳這裏！
https://yq.aliyun.com/download/3564
本文將主要圍繞以下四個方面進行分享：
現狀和問題
雲時代的機會
阿里雲的新進展
應用案例
遷移&容災現狀與問題
2014年，xx銀行核心數據庫出現故障，導致存取款、網銀、ATM等業務全部中斷長達37小時。2017年，xx遊戲數據庫故障，30小時無法服務，數據丟失，導致遊戲回檔。2018年，xx著名代碼託管服務商數據庫故障，24小時無法服務。以上這些問題的根源都是數據庫。而整體而言，數據庫的問題和程序開發是類似的，按照墨菲定律來講就是只要有出現問題的可能，那麼問題就一定會出現。
我們不能和墨菲定律賽跑，因此需要做好數據的遷移和容災等工作。從業界的兩個公開報告分析了數據庫出現問題的一些原因。可以看到，在2015年，備份恢復軟件收入達到44.49億美元，這一市場的份額還是比較大的。
國家標準《信息系統災難恢復規範》可以給大家一些參考，也就是說大家願意投入的成本和收益是正相關的，花費的錢越多，數據丟失的時間和恢復的市場就會越小。因此，需要在投入成本和數據丟失情況之間進行平衡。上圖中右側是國標中定義的一張表，雖然年代比較久遠，但是在今天仍舊有一定的參考意義。
數據複製技術現狀
對於遷移和容災本身而言，都是使用的數據複製技術，包括了邏輯複製和物理複製，這兩者之間各有優劣。兩者相比而言，邏輯數據複製對於數據庫的兼容比較好，實時性好，目的庫基本都是可用的，而物理備份目的庫卻可能是不可用的。
雲時代的機會
這裏列出了三份涉及到數據庫遷移和容災的Gartner報告，不同報告的金額不同。但是總體來講，數據庫遷移和容災市場在不斷增大，而云上市場更是在翻倍地增長。市場的現狀是數據庫多種多樣，所有的數據都存儲在各個數據庫系統或者其他存儲系統裏面，數據是企業的核心資產，一般而言，如果出現了問題都是最高級別的故障，因此可能會造成極大的影響。此外，災備事故本來發生的就比較多，可能出現數據無法恢復的情況，並且RPO、RTO也可能比較大。而新的變化在於，用戶在持續地上雲，對於阿里雲而言，從2016年到如今，用戶處於爆發式增長。而云廠商在快速推進雲上數據遷移和災備服務，而傳統軟件廠商仍屬於領導者，但都在快速雲化。
雲時代的變化
雲時代下，除了數據庫遷移和災備的市場發生了變化之外，其實玩法也變了。場景、網絡以及技術都發生了變化。對於場景而言，比如線下網絡是隔絕的，但是雲上就會出現一些問題，存在很多監管或着合規的要求。還有出海、混合雲、多活以及雲備份等，私有云自己搭建是比較困難的，但是上雲之後可能就會容易很多，可能只需要點擊幾下鼠標就好了。對於網絡而言比較複雜，因爲要做網絡隔離來保證安全性，因此需要做VPC、專線以及網關等，實現每個用戶互不干擾。對於技術而言，很多用戶從線下遷移上雲存在公網的問題，可能網絡質量不是特別好，並且需要解決用戶的秒級RPO問題和快照技術問題，還需要保證用戶的備份數據集能夠提供查詢。
雲時代的網絡架構
可以看到，雲服務與阿里雲之間、用戶本地自建數據庫與阿里雲之間以及訂閱消費與阿里雲之間，可能的網絡類型包括了公網、私網、VPC、專線和VPN網關，這就爲數據庫遷移備份帶來了很多困難，因爲網絡是基礎設施，如果網絡存在很大問題，那麼整個服務的性能和穩定性就會遇到非常大的挑戰。對於數據遷移而言，最大的不可控因素就是源庫和網絡。
阿里雲的思考
對於阿里雲而言，首先需要考慮數據如何流動起來，通過阿里雲數據傳輸服務DTS和數據庫備份能夠幫助用戶搞定遷移和備份問題。
數據高速公路—DTS
數據傳輸服務(Data Transmission Service，簡稱DTS) 支持以數據庫、大數據、文件爲核心的結構化存儲產品之間的數據傳輸，它是一種集數據遷移、數據訂閱及實時同步於一體的數據傳輸服務。DTS是支持增量數據傳輸的，其增量方法基於日誌解析實現，並且支持Oracle、SQL Server、PG、Redis、MongoDB等數據庫，這項能力目前在全球都處於領先地位。阿里雲DTS應該是公有云上第一個數據傳輸服務，處於技術的領先地位。並且無論是源端數據庫還是目標數據庫，DTS都支持友商以及用戶本地的數據庫。如果用戶想要做訂閱，比如流計算、搜索、廣告等數據庫下游業務都需要通過DTS服務來解決問題。
DTS核心模塊
如下圖所示，DTS整體分爲幾個模塊。爲了解決數據同步或者遷移過程中，因爲用戶的DDL而引起的數據庫表結構變更，此時就需要MetaBuilder進行解決。數據解析完成之後放入到DStore裏面，變成結構化的數據，其能夠支持索引，比如Tag或者Index，DStore類似於簡單的數據庫，因爲其能夠支持快速查找。此外，在數據寫入的時候還實現了一些Bucket衝突算法等。
日誌解析能力
這裏介紹一下DTS的DReader基本架構。DReader是插件化的，可插拔的架構，對於源端的各種數據庫開發一個插件，將這個插件放到DTS上去之後就能夠支持源端數據庫到目標數據庫的增量數據同步了。
日誌解析DReader
對於日誌解析而言，存在一定的問題，這裏選取幾個重點問題進行講解。第一個問題就是如何構建Schema快照，無論是什麼數據庫，在解析日誌的時候如果源端數據表發生了變更，如何實現對於變更的解析，這就需要將源端數據庫的Schema信息和本地適配起來，因此DReader需要Schema的構造和維護能力。第二個關鍵問題就是大事務、穿插以及回滾事務的解析，這對於MySQL而言比較簡單，但對於Oracle而言就會存在很多的問題，而DReader很好地解決了這個問題。
因爲Oracle有歸檔和Redo的功能，DReader可以同時支持這兩者，去解析日誌的時候需要通過Extractor將其轉化成結構化的Record，進而按照事務進行聚合，再實現二進制轉化，最終還要做Update回查數據。上圖中下側講的是斷點續傳，這裏也存在幾個問題，當面對大事務的時候，數據存在交叉，正常的安全位點都是記錄Commit的位置。而在用戶數據庫的遷移和同步過程中發現有些任務很奇怪，可能並沒有業務數據但是延遲很大，分析其原因是用戶存在一些無操作的長事務，只是開啓了Begin但是一直沒有Commit，這就導致了幾方面的問題。一個就是延遲很大，就是一旦重啓，因爲安全位點很老舊，就會將數據拉倒老舊的安全位點，需要拉取很長一段時間的增量數據，使得數據同步的速度非常慢。另外一點就是很有可能redo等日誌已經刪除掉了，那麼此時就可能無法恢復數據了。因此DReader希望能夠判斷出來事務是不是一個無操作的事務，這樣就能將安全位點移動到合適的位置上來解決相應的問題。對於大事務問題，可能一個事務提交過來100G的數據，那麼就需要通過落盤操作將事務解析出來進行進一步處理。這裏還有一些其他的問題，比如SQL Server的堆表頁遷移和DDL支持問題、PostgreSQL的DDL日誌問題以及Redis的resharding日誌問題等，還有分佈式事務解析問題以及反查對源庫影響問題。
冪等同步
冪等同步原理較爲簡單，但是非常有用。主要就是Insert唯一性衝突的時候，進行Replace語義操作；Update不命中的時候，插入新鏡像值；Update唯一性衝突的時候，Delete舊鏡像值，插入新鏡像值。這一點在DTS中可以做到，數據隨意回拉都能夠保持一致性。
DTS Any To Any 架構
Any To Any的意思就是任何一個源端數據庫到任何一個目標端數據庫都只需要開發一次即可。從源端數據到中間是確定的轉換，而從中間到目的端數據卻是不確定的轉換。阿里雲DTS爲用戶提供了轉換模型，但是用戶也可以自己選擇轉換邏輯。
分佈式解析和同步
如果源端數據庫屬於分佈式架構，採用了分庫分表的方式或者使用了集羣架構，這種情況下如何實現數據遷移呢？這裏支持分佈式架構的數據遷移的最關鍵的問題就是做協同，比如有DDL該怎麼辦，DDL誰先做誰後做都存在很大的問題。阿里雲DTS採用了分佈式Raft算法來解決這樣的問題。
數據庫時光機—DBS
數據庫備份服務（Database Backup Service，簡稱DBS）是爲數據庫提持續的、可靠的、低成本的備份服務。它可以爲多種環境的數據提供強有力的保護，包括企業數據中心、其他雲廠商、混合雲及公共雲。備份主要包括幾種環境，公網自建、本地IDC以及ECS自建的數據庫，可以支持將數據備份到阿里雲OSS和阿里雲NAS上。
DBS核心模塊
DBS核心模塊如下圖所示，Full表示全量備份，Inc表示增量備份，這兩者都屬於邏輯備份，此外DBS還提供了物理備份。
DBS秒級備份
DBS能夠實現秒級備份，做到秒級RPO。在做數據庫恢復時需要知道想要恢復到哪個庫和哪個表，但是因爲數據一直在變，難以知道恢復到哪個時間點，而DBS能夠幫助用戶恢復到任意時間點。
DBS物理備份
對於DBS物理備份而言，需要有一個Agent，比如用戶只有本地IDC而沒有公網IP，當他想要進行數據備份只需要下載一個Agent即可。Agent能夠自動升級，並且一旦啓動之後就能夠自動彙報心跳，所有的操作都在阿里雲上完成，只需要點擊幾下就能夠將全部數據備份或者恢復完成。
雙11大屏
下圖展示了雙11大屏的情況，大屏上展示了實時交易量，那麼2135億這個數字是怎麼計算出來的呢？因爲全球的交易都發生在不同的地方，想要實時統計並展現這個數字就需要剛纔講到的DTS技術，通過實時增量訂閱來獲取數據。
阿里雲Region單元化
阿里雲本身Region單元化的架構都是藉助了DTS技術完成的，從而實現了全球同步。
案例1：基於DTS搭建的銀泰新零售混合雲
舉例而言，銀泰在全球有幾十個商場，之前其數據庫都是Oracle，而爲了實現“去O”，銀泰基於DTS搭建了新零售混合雲架構。通過共享Store+源端過濾將銀泰專線帶寬佔用從300Mb->30Mb每秒，源庫CPU從40%降低到10%，並且實現了雙副本實現秒級容災。
案例2：某新零售公司異地多活
對於傳統架構而言，異地多活是一件比較困難的事情，而如果今天在阿里雲上做這件事情就會相對比較簡單了。該公司業務上在多地有多套服務，這些服務同時承擔業務流量，且服務之間互爲備份。藉助阿里雲，通過雙向同步功能，進行各業務中心的數據同步，實現數據全局一致。當某個節點出現異常時，業務秒級切換到其他節點。
案例3：某用戶備份數據在線查詢
數據庫備份DBS和Data Lake Analytics深度合作，發佈備份數據在線查詢能力，讓備份數據“活”起來。無需恢復，用戶可以通過SQL語句交互式查詢備份數據，查詢結果集立刻返回給用戶。相對於傳統備份，數據在恢復後才有價值，DBS備份數據在線查詢對用戶最大的價值：快速，在備份驗證、歸檔查詢、數據訂正、數據提取等場景上，用戶可以快速獲取備份數據。
案例4：某集成商集成DBS
阿里雲的某個用戶擁有幾十萬的SQL Server數據庫，想要爲用戶提供SQL Server能力，這個廠商就將阿里雲DTS封裝完成之後來提供服務。由此也可以看出，生態夥伴可以藉助阿里雲以很低的成本做很多事情，最終實現集成商、終端用戶、阿里雲的三贏。
案例5：某互聯網公司-緩存更新業務解耦
用戶爲了提升讀併發，在業務中引入緩存，業務更新請求落在DB，讀請求落在緩存。希望在不影響業務的情況下解決緩存更新問題。對於存在依賴關係的上下游業務，希望不影響上游穩定性的情況下，低成本得實現下游業務通知機制。使用阿里雲DTS的數據訂閱功能，實時獲取上游業務的數據庫更新數據，更新緩存內容，解決緩存更新問題；觸發下游業務邏輯。
案例6：某小視頻公司-業務數據實時分析
很多用戶會通過自己搭建的Flink集羣或者Storm集羣實現實時數據分析，想要將這些數據實現增量地寫入目的端數據庫，通過DTS就能輕鬆地完成。
案例7：城市大腦
城市大腦是阿里雲樹立的很好的名片，通過城市大腦幫助很多城市減輕了交通擁堵問題，城市大腦也使用了阿里雲的一系列產品，包括DTS、ADB、TSDB、DRDS、DMS等。