2019獨角獸企業重金招聘python工程師標準》
背景
在系統的快速迭代過程中，業務系統往往部署在同乙個物理庫，沒有做核心資料和非核心資料的物理隔離。隨著資料量的擴大這種情況會帶來穩定性的風險，如庫的慢sql，磁碟，io等等都會相互整體影響，從而影響核心系統的業務穩定性，因此需要將核心業務的業務表從原有庫里抽取出來，單獨到新庫里。而核心資料的遷移，涉及到的乙個關鍵難點：如何平穩及使用者無感知的遷移資料，本文將結合閒魚商品庫遷移實踐，向大家展示如何解決這個難題的.
閒魚商品資料現狀
閒魚商品資料量xx億級別以上，採用分表分庫和讀寫分離的mysql資料庫集群來支撐線上查詢服務,如下圖，通過tddl[1]資料庫中介軟體進行高效統一管理。可能有些同學會對分表分庫相關概念不了解，這裡先簡單做些介紹。
01分表分庫原理
本質是資料庫的水平拆分問題，把乙個資料庫切分成多個部分放到不同的資料庫(server)上，從而緩解單一資料庫的效能問題，下圖描述分表分庫的核心原理：
當然分表分庫也有負面影響，就是表結構變更及相關管理相比單錶麻煩，有一定風險，具體如何決擇，還是要根據實際情況來分析。
02分表分庫下全域性sequence生成
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回滾方案
回滾方案總原則是不丟資料。最有可能的發生點是雙寫期間新庫出問題，導致線上服務異常，這時只要立即關閉寫新庫即可，另外就是切到新庫後，新庫出問題了(如效能問題)，可以立即切回到老庫，並通過反向任務，保持資料一致性，最後若沒啟用分布式事務,雙寫的時間越短越好,有可能會有資料不一致情況。
小結
**於:
21世紀了還愚公移山？資料庫這麼遷移更穩定！
在系統的快速迭代過程中，業務系統往往部署在同乙個物理庫，沒有做核心資料和非核心資料的物理隔離。隨著資料量的擴大這種情況會帶來穩定性的風險，如庫的慢sql，磁碟，io等等都會相互整體影響，從而影響核心系統的業務穩定性，因此需要將核心業務的業務表從原有庫里抽取出來，單獨到新庫里。而核心資料的遷移，涉及到...
21世紀的軟體測試
全程軟體測試，測試是重中之重。全程自動化測試，測試原來可以是這樣的。全程缺陷預防，測試工作已經不是那麼重要。譯文 由於當前商業和it環境的驅動，軟體測試的理念 實踐和工具正在發生一些革命性的變化。這種變化將給專業測試人員及其測試工作帶來什麼樣的影響？這些驅動正在改變專業測試人員的生活 it操作的商業...
21世紀 互動設計
21世紀 互動設計 隨著計算機 資訊科技的高速發展，資訊現在無處不在，怎樣有效地將自身的產品 資訊等，很好被使用者接受，越來越多地被提供商所關注。針對it行業，各種 軟體等到處都是，目的很明確都是為使用者提供更好的服務。然而我們是否真得做到完全滿足客戶的需求，使客戶完全滿意，為使用者提供更方便的服務...