打破數據邊界，是數字化時代常掛在嘴邊的一句話，數據的價值是在流動中體現的，數據應用也是如此。以往為了滿足開發、測試、數據保護容災和數據分析的需要，我們不斷對數據進行複製、備份、遷移，因此數據遷移非常重要。 混合多雲時代，用戶數據遷移需求與場景激增 今天我們來重點聊聊混合雲時代中數據遷移，先來看看常見 ...
打破數據邊界，是數字化時代常掛在嘴邊的一句話，數據的價值是在流動中體現的，數據應用也是如此。以往為了滿足開發、測試、數據保護容災和數據分析的需要，我們不斷對數據進行複製、備份、遷移，因此數據遷移非常重要。
混合多雲時代，用戶數據遷移需求與場景激增
今天我們來重點聊聊混合雲時代中數據遷移，先來看看常見的幾種企業數據遷移的需求與場景：
-
傳統雲化型：設備老舊，需要升級，硬體成本升級性價比不高，雲上更經濟；
-
價格敏感型：綜合對比多家廠商價格，靈活選型採用成本最優方案；
-
災備驅動型：需要多雲、異構雲來架構自己的災備體系，保證數據的安全
-
游戲客戶：異地開服，服務不同地域的用戶，因各地網路質量不一致需要多雲模式用於構建服務本地用戶的游戲伺服器。
-
泛金融客戶：要符合金融安全政策的要求，需要數據的遷移
這些客戶都因系統和技術升級、業務的發展、以及安全合規等因素採用混合多雲的方案，同時對其數據的遷移有著很高的訴求，在不同的業務模式和需求下也會面臨多種問題。
混合多雲時代下，數據遷移的困境
資料庫的發展多樣性提升遷移門檻
混合多雲時代，遷移是面臨的一大難題，其中數據安全遷移往往又是企業最關註的。提到數據遷移的困難，究其原因先粗略回顧下關係型資料庫到非關係型資料庫的發展。
關係型資料庫，是指採用了關係模型來組織數據的資料庫。關係模型是在1970年由IBM的研究員E.F.Codd博士首先提出的，在之後的幾十年中，關係模型的概念得到了充分的發展並逐漸成為主流。關係型資料庫具備事務一致性、讀寫實時性、結構化與規範化等特性，因而容易理解、使用方便、易於維護，在虛機時代，互聯網還未普及時它是最主流的資料庫，典型的代表有Oracle、Microsoft SQL Server、DB2、MySQL等。
但隨著互聯網的飛速發展，網站用戶併發高，海量數據的產生，傳統關係型資料庫已經不能滿足企業的數據存儲需求了，非關係型資料庫應勢而生，它高併發,讀寫能力強、弱化數據結構一致性,使用更加靈活有良好的可擴展性等優勢逐漸成為了企業的首選。
NoSQL一詞首先是Carlo Strozzi在1998年提出來的。典型代表Redis， Amazon DynamoDB， Memcached，Microsoft Azure Cosmos DB等
在面對這兩種資料庫之間的遷移，關係型資料庫SQL RDBMS發展久，遷移生態工具齊全，且大部分資料庫產品都自帶遷移工具；而非關係NoSQL，數據定義更寬鬆，產品體積輕量，放棄了一致性校驗，導致某些數據結構濫用，提升了遷移難度。而遷移工具大部分開放給生態來做，由於發展時間較短，工具完善度不如RDBMS高。
廠商試圖“數據綁架”，使遷移雪上加霜
分析完關係型資料庫到非關係資料庫的發展，可以看到數據存儲結構本身已發生了巨大的變化，這從根因上已大幅提升了遷移的難度，而一些雲廠商對資料庫的再次改造，且對關係型資料庫底層改造不透明，導致資料庫的複雜性大大加大，試圖用數據遷移成本高來長期綁定客戶，更是令數據的遷移雪上加霜。
“個體差異”導致通用型解決方案缺失
不同的企業由於自身需求不同與使用場景的多樣性，每一個客戶，對我們來說都是一個新的案例，我們必須“量身定製”化服務，但在過程中我們也總結出幾類常見難點：
-
難點一：多節點資料庫遷移，節點數量不一致
-
難點二：原生產品跨版本問題，版本不一致且上下版本相容性不夠好
-
難點三：緩存類數據易失性更高
面臨挑戰，京東雲破局遷移困境
下麵通過實際案例和大家分享我們是如何破局遷移困境，幫助用戶解脫數據枷鎖的。
重大挑戰，臨危不亂/從容不迫
2019年京東物流為了實現其輕資產化、降低成本、升級架構的三大目的，將其ES開始由本地機房遷移到雲上。依托京東云云搜索ES高可用、易擴展、近實時等特性，京東物流成功地將分揀中心自動化系統、冷鏈流程監控系統、開放訂單跟蹤系統等上百個系統遷移上雲。
在遷移過程中京東雲不僅提供了常規的停機遷移方案，還提供了特殊的不停機遷移方案，保證了物流業務不停服。不停機遷移方案如下：在雲端創建新集群，將雲上集群和用戶集群合併成一個大集群，利用Elasticsearch數據分佈API（cluster.routing.allocation.exclude）將用戶集群中的索引數據遷移到雲上集群的數據節點，最後將用戶集群和雲上集群構成的大集群拆分，關閉用戶集群即可完成遷移。（採用這種方式須註意同時滿足以下兩個條件：用戶集群版本和雲上集群版本相同；用戶集群所有節點和雲上集群所有節點網路能夠互通。）
通過上述方法，很快就就完成了京東物流近百個系統的數百個集群、數千個節點數據上雲工作。在此之上京東雲還配套提供了一鍵報警等核心功能，對上雲工作進行全天候、全方位的保障。
截止目前，京東物流已有超過90%的應用在公有雲上部署了實例，去年11.11期間業務量超過日常三倍以上的情況下，整體運營平穩。
遷移利器，上雲必備
關係型資料庫依然是各行業的主流應用之一，怎樣更快的將傳統關係型數據中的數據遷移上雲也是很多行業用戶關心的。為此京東雲特意打造了一款針對關係型資料庫的遷移工具——數據傳輸DTS。
數據傳輸DTS 提供實時數據流服務，支持數據遷移、數據訂閱和數據同步服務，可簡單方便的滿足數據上雲、業務非同步解耦、數據異地災備、業務系統數據流轉等業務場景。目前數據傳輸DTS支持MySQL、MariaDB、Percona、SQL Server、PostgreSQL等多種資料庫遷移，可以簡單快速地將本地自建資料庫遷移至京東雲，源資料庫在遷移過程中可繼續正常運行，從而最大程度地減少應用程式的停機時間。
不斷突破，技術創新
某家線上廣告公司需要將Redis從自有機房遷移到雲上。由於客戶系統承載著大量結算緩存和業務緩存所以要求在遷移過程中不能有業務中斷。當時有一些開源工具，但是不滿足要求。主要是由於版本問題，客戶用的Redis版本是4.0而當時開源的工具只支持3.28及以下版本。本著京東客戶業務為先的原則，和鼓勵創新的技術精神，我們思考，能不能為客戶自研一套工具，能夠Cover住Redis數據流轉大部分場景的通用工具，於是2019年7月redissyncer 1.0版本誕生，完成了數據源及目標校驗、原生集群同步、 大KV的拆解等基本功能。
1.0完後很快迎來了幾個客戶：
-
其一是互聯網行業用戶，Redis單實例，數據體量不大20Gb左右。我們通過啟動參數修複、調整每批次Value值等細節優化順利完成了遷移任務；
-
第二個用戶是游戲行業的用戶，用戶需要將自有IDC中的Redis遷移到京東雲。在使用我們的產品之前，用戶自己找過若幹開源產品但都不符合要求。由於用戶的實例數量較多，在瞭解過Redissyncer產品特性後，用戶決定使用我們的工具自行遷移。
貼近一線，無微不至
經過一個下午的培訓遠程培訓，用戶很快上手第一個實例遷移很順利。在接下來的幾天用戶通過我們的工具陸續完成遷移工作，並反饋中給予產品很高評價，並特意發來感謝信。
來自客戶的認可，是我們不斷向前的最大動力！
不斷打磨，精益求精
在剖析過更多客戶痛點與需求後， 2019年11月底，我們完成了2.0版本的升級，補充了同步模式拆分、斷點續傳、離線文件載入、跨版本遷移、流式載入等功能。
很快2019年12月我們又迎來了一個金融用戶。用戶需要將原生Redis集群遷移到自研的Redis集群。目標集群節點數多大16*2即16對主從構成的集群，遷移過程很順利，經過準備15分鐘完成應用割接。
（遷移部署圖）
經過實際場景的打磨，我們陸續修複了一些測試中很難遇到的bug，添加了一些新特性。使得產品不僅支持升級遷移同時支持降級遷移；為了提高用戶體驗，我們參考Redis、MySQL等優秀開源產品的方式做了一個命令行客戶端命名為redissyncer-cli。至此，完成了RedisSyncer3.X的升級，這個項目的體系建設基本上可以滿足Redis遷移同步場景中的大部分需求了。
不止於此，突破創新
起初，我們把RedisSyncer定位為一個Redis的同步工具。隨著開發和用戶側的實踐，我們下一步想把RedisSyncer打造成為具備企業級災備能力的Redis數據同步中間件。從工具到具備企業級災備能力還是有一定門檻的。所以下一步我們的工作重點是對軟體進行分散式改造，最終目標是在任意節點發生故障時任務可自動化持續，實現企業級災備能力的Redis數據同步中間件。
擁抱開源，包容開放
目前京東雲已經積累了覆蓋互聯網、游戲、金融、物流、零售等多場景領域的遷移經驗。隨著混合多雲趨勢到來，我們深知用戶遷移之苦，也願意以相容開放的心態為客戶提供技術服務，真正做到把選擇權交給用戶，同時為了讓更多人享受技術帶來的便利，我們在今年決定將自研RedisSyncer完全開源（開源地址：https://github.com/TraceNature/redissyncer-server），將技術回歸社區，給更多用戶和開發者帶來便利！
