資訊專欄INFORMATION COLUMN
摘要：數據遷移，主要利用阿里云數據傳輸服務的數據遷移能力，涉及到全量遷移增量遷移一致性校驗及反向任務。小結通過周密的遷移方案設計，以及強大的數據遷移工具的能力，閑魚商品庫順利完成億在線數據庫服務遷移，獨立的物理部署顯著提升商品庫在線服務的穩定性。
背景
在系統的快速迭代過程中，業務系統往往部署在同一個物理庫，沒有做核心數據和非核心數據的物理隔離。隨著數據量的擴大這種情況會帶來穩定性的風險，如庫的慢sql，磁盤，IO等等都會相互整體影響，從而影響核心系統的業務穩定性，因此需要將核心業務的業務表從原有庫里抽取出來，多帶帶到新庫里。而核心數據的遷移，涉及到的一個關鍵難點：如何平穩及用戶無感知的遷移數據，本文將結合閑魚商品庫遷移實踐，向大家展示如何解決這個難題的.
閑魚商品數據現狀閑魚商品數據量XX億級別以上，采用分表分庫和讀寫分離的MYSQL數據庫集群來支撐線上查詢服務,如下圖，通過TDDL[1]數據庫中間件進行高效統一管理。可能有些同學會對分表分庫相關概念不了解，這里先簡單做些介紹。
01分表分庫原理
本質是數據庫的水平拆分問題，把一個數據庫切分成多個部分放到不同的數據庫(server)上，從而緩解單一數據庫的性能問題，下圖描述分表分庫的核心原理：
當然分表分庫也有負面影響，就是表結構變更及相關管理相比單表麻煩，有一定風險，具體如何決擇，還是要根據實際情況來分析。
02分表分庫下全局Sequence生成
分表分庫解決在線服務容量和性能問題，但是也帶來使用上的復雜度提升。靈活的配置路由規則和路由數據并提供簡單易用的封裝都是要考慮的，以便業務對此無感知。阿里開源中間件產品TDDL提供了解決方案，對應阿里云上產品為：DRDS[2]。
TDDL關鍵原理不多做介紹，但是在數據庫遷移過程中主鍵沖突風險是故障重要風險點，這里簡要介紹下TDDL的全局唯一主鍵生成原理。
如上圖，TDDL Sequence是基于數據庫更新＋內存分配：每次操作批量分配id，分配id的數量就是sequence的內步長，而原有id值就加上外部長值，后續的分配直接就在內存里拿，這樣的優勢：簡單高效 缺點：無法保證自增順序。
另外數據遷移過程中，在新庫中，為了保證跟原數據庫主鍵非沖突，需要設置一個躍遷比較大的主鍵，防止出現兩個庫中的主鍵沖突，這是后續遷移中要注意的關鍵點之一。
數據遷移方案通過前文的簡單介紹，大家對閑魚商品庫現狀有了初步了解，下面將給大家介紹一下閑魚是如何做到穩定遷移商品庫的。
01核心思路
數據遷移核心思路抽象起來其實很簡單，即如何穩定平滑遷移數據，如下圖所示:
但圍繞這個過程細化下去，我們會遇到不少問題，如：
1、數據我們該如何遷移，是一次性？還是分階段？
2、如何校驗數據遷移過程的正確性?
3、我們業務改造有問題怎么辦？如何盡早發現？如何回滾？
4、我們的新庫性能如何？
帶著這些問題，我們進一下細化梳理遷移方案。
02實現方案
如上圖所示，整個方案分為幾個部份：
1、系統改造，包括SQL改造，雙寫開關，新庫sequence創建。
SQL改造：加載兩套TDDL數據源，一套是給老庫的，一套是給新庫的，并且生成兩套mybatis sql 模板。
雙寫開關：設置好寫新庫，寫老庫的開關，用于線上遷移過程中雙寫過程及遇到問題及時回滾。
sequence創建：遷移sequence表時，需要抬升新庫的sequence表中的值，用于防止主鍵沖突，并且需要按照主鍵消耗量評估一個安全值，這是非常重要的一個細節，再次強調一下。
2、穩定性保障，遷庫是大事，改造過程中，穩定性重中之重，主要有系統壓測，線上流量回放，故障演練。
系統壓測：主要針對新庫進行性能測，防止新庫有意外情況。
線上流量回放：Edsger W. Dijkstra說過如果調試程序是一種標準的可以鏟除BUG的流程，那么，編程就是把他們放進來的流程。通過引入線上數據在測試環境回放，可以盡可能的發現問題，保證改造后的穩定性。
故障演練：通過注入一些人為故障，如寫新庫失敗，新庫邏輯有問題，及時的演練回滾策略。
3、數據遷移，主要利用阿里云數據傳輸服務DTS[3]的數據遷移能力，涉及到全量遷移、增量遷移、一致性校驗及反向任務。
全量遷移:數據遷移首要目標如何將歷史全量數據遷移到新庫中，我們的做法是指定一個時間點，再根據這個時間點查找每張源表的最大及最小id,然后分別批量導到目標庫中，如圖：
整個過程都是查詢在線庫的備庫，因此不影響在線業務的數據庫服務。
增量遷移:由于遷移過程中業務服務一直運行，因此全量遷移完全成，并且要將全量時間點后的數據追回來，這里核心原理是同步全量時間位點后binlog日志數據來保證數據一致性，需要注意的是增量時間需要前移一小斷時間(如5分鐘)，其主要原因是全量遷移啟動的那刻會有時間差，需要增量前移來保證數據最終一致性，如下圖:
一致性校驗：通過全量及增量的遷移后，此時源庫跟目標的數據理論上是一致的,但實際上應用在經過功能測試，線上流量回放等階段，數據在這個過程中有可能會現不一致的情況,因此正式上線前，需要做數據一致性校驗，其原理是分批查詢源表(跟全量遷移的查詢方式類似)，再跟目標庫進行比對,如圖所示：
反向任務：遷移到新庫后，會有一線離線業務對老庫還有依賴，需要建立從新庫到老庫的回流任務，原理跟增量遷移一樣，只是變更一下原庫及目標庫。
03遷庫流程
到這里大家應該對遷庫所涉及到點比較清楚了，但還有一個非常重要的事，即梳理整個遷庫步驟非常關鍵，通常會有兩種方案。
方案一：
1、DTS數據追平，即全量同步完成，開啟增量同步，并且延遲在秒級以內。
2、上線前校驗，主要有線上流量回放、壓測、一致性校驗，故障演練。
3、線上開雙寫，線上同時寫新庫及老庫，這時需要關閉增量同步任務，防止無效覆蓋。
4、線上校驗，執行預先準備的測試腳本并結合一致性校驗工具，同時將讀流量慢慢切到新庫，驗證雙寫邏輯。
5、切換數據源，關閉雙寫并正式寫入新庫。
6、創建反向任務，數據回流老庫。
方案二：
1、DTS數據追平，即全量同步完成，開啟增量同步，并且延遲在秒級以內。
2、上線前校驗，主要有線上流量回放、壓測、一致性校驗，故障演練。
3、線上切開關，寫新庫， 同時需要關閉增量同步任務，防止無效覆蓋。
4、創建反向任務，數據回流老庫。
方案優缺點對比：
總結起來方案1遷移流程相對復雜，對遷移的控制力度更細，適合業務復雜，底層改造比較多，想精細化控制遷移步驟的場景，方案2遷移相對簡單，過程快速，適合業務流程相對簡單，可控，想快速切換的場景，具體選選擇哪個方案，同學們可以根據自身的業務情況做選擇。
這里考慮到閑魚商品業務復雜，底層改造較多，從穩定性的角度考慮，最終選擇方案1。
方案1，最關鍵的是3、4、5步驟，因此需要預先做好回滾計劃。
04回滾方案
回滾方案總原則是不丟數據。最有可能的發生點是雙寫期間新庫出問題，導致線上服務異常，這時只要立即關閉寫新庫即可，另外就是切到新庫后，新庫出問題了(如性能問題)，可以立即切回到老庫，并通過反向任務，保持數據一致性，最后若沒啟用分布式事務,雙寫的時間越短越好,有可能會有數據不一致情況。
小結通過周密的遷移方案設計，以及DTS強大的數據遷移工具的能力，閑魚商品庫順利完成XX億在線數據庫服務遷移，獨立的物理部署顯著提升商品庫在線服務的穩定性。然而不同業務系統的數據庫情況可能會有差異，如單庫向多庫遷移，單表向多表遷移等，不過整體方案大致類似，希望本文遷庫實踐方案能給大家提供一個可行的參考。
閱讀原文
本文來自云棲社區合作伙伴“閑魚技術”，如需轉載請聯系原作者。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/17940.html
摘要：從能力上分，一個是搬運工，一個是設計者能寫代碼是愚公移山為什么說能寫代碼是愚公移山呢我們中國大部分程序員都應該處于一個初級程序員的水平，怎么講只有少數的程序員處于中高級水平。 導語：你知道普通程序員和優秀程序員之間的差距嗎？其實答案很簡單，那就是「愚公移山」和「女媧補天」之間的區別。 之所以提這個話題，跟前兩天在微信群里的討論有關，年后本該是跳槽、找工作的高峰月份，各公司面試邀約應該很...
摘要：若函數不能執行有效的轉換，返回。如果數值超過可表示的范圍，則返回或。示例輸入輸出解釋轉換截止于數字，因為它的下一個字符不為數字。 這是我參與11月更文挑戰的第12天。一、寫在前面LeetCode 第一題兩數之和傳輸門：聽說你還在寫雙層for循環解兩數之和？LeetCode 第二題兩數之和傳輸門：兩個排序數組的中...
摘要：年系統第一次被一篇文章預測即將死亡，后來也撰寫報告稱，在全球企業中部署的高度定制化的企業資源規劃系統正在逐漸老化。到年，這些系統將成為遺留軟件。隨后又好幾次被傳死掉毫無疑問，云的廠商還會繼續這么做，但的成功也證明他存在的價值。本地ERP被SaaS ERP取代未來已來，在商業應用里，云的應用似乎無處不在，簡單的將其看作是應用部署的一個選項肯定是不對的。那么云到底是什么呢？好處又有哪些？2000...
閱讀 2801·2023-04-25 22:51
閱讀 2025·2021-10-11 10:58
閱讀 3307·2019-08-30 10:49
閱讀 1869·2019-08-29 17:09
閱讀 3135·2019-08-29 10:55
閱讀 838·2019-08-26 10:34
閱讀 3465·2019-08-23 17:54
閱讀 979·2019-08-23 16:06
