簡介： 本文作者就一個高德叫車彈外訂單系統進行了一次擴分庫分表和資料庫遷移。
一、 背景
2020年，筆者負責的一個高德叫車彈外訂單系統進行了一次擴分庫分表和資料庫遷移。該訂單系統整體部署在阿里雲上，服務使用阿里雲ECS部署，資料庫採用阿里雲RDS，配置中心基於阿里雲ACM自研，資料同步基於阿里雲DTS自研以及自研分庫分表元件、分散式ID元件等等。
此次進行擴分庫分表的背景是，原4例項4庫、每個庫64張表一共256張表，部分單表已超千萬量級，按當前每日單量量級，一年內單表會達到上億條記錄，單表資料量過大會帶來資料庫效能問題。
注：【彈內彈外】彈是指彈性計算，彈內與彈外其實是指兩套獨立的彈性計算網路環境。彈內主要是指部署在阿里生產網的彈性計算環境，最早是基於原有淘寶技術構建的，主要用於支撐淘寶業務。彈外主要是指部署在阿里公有云的彈性計算環境，支撐了阿里雲端計算業務。
二 、容量規劃
1 、當前分庫分表情況
4例項（16C/64G/3T SSD），4庫（每個例項一個庫），每庫64張表，共256張表。
通過RDS後臺一鍵診斷功能，來計算表空間使用情況（這裡拿測試環境資料庫舉例）。
2 、容量計算
例項數
資料庫的瓶頸主要體現在：磁碟、CPU、記憶體、網路、連線數，而連線數主要是受CPU和記憶體影響。CPU和記憶體可以通過動態升配來提升，但是SSD磁碟容量最大支援到6T（32C以下最大3T、32C及以上最大6T）。
但是現階段兼顧成本，可先將例項擴容一倍，採用8個例項(16C/64G/3T SSD)，每個例項建4個庫（database）、每個庫128張表（這裡實際上是一個成本取捨的過程，理論上應該採取"多庫少表"的原則，單庫128張表其實太多了，單庫建議32或64張表為宜）。
後續如果例項壓力提升可進行例項配置升級(16C/128G、32C/128G、32C/256G等)；未來如出現單例項升配無法解決，在考慮擴容例項，只需要將database遷移至新例項，遷移成本較小。
表數
按單表最多1000w條資料評估，4096張表可支援日5000w單3年(10.1壓測標準)、日2000w單5年的架構。（因業務表比較多，此處忽略掉單條資料大小的計算過程）
庫數
32個庫，每個庫128張表。未來可最大擴容到32個例項，無需rehash，只需要遷移資料。
阿里雲RDS規格和價格一覽
三、 資料遷移
因擴分庫分表涉及到rehash過程（256表變4096表），而阿里雲DTS只支援同構庫資料遷移，所以我們基於DTS的binlog轉kafka能力自研了資料同步中介軟體。
整個資料遷移工作包括：前期準備、資料同步環節（歷史資料全量同步、增量資料實時同步、rehash）、資料校驗環節（全量校驗、實時校驗、校驗規則配置）、資料修復工具等。
1 、準備工作
唯一業務ID
在進行資料同步前，需要先梳理所有表的唯一業務ID，只有確定了唯一業務ID才能實現資料的同步操作。
需要注意的是：
- 業務中是否有使用資料庫自增ID做為業務ID使用的，如果有需要業務先進行改造，還好訂單業務裡沒有。
- 每個表是否都有唯一索引，這個在梳理的過程中發現有幾張表沒有唯一索引。
一旦表中沒有唯一索引，就會在資料同步過程中造成資料重複的風險，所以我們先將沒有唯一索引的表根據業務場景增加唯一索引（有可能是聯合唯一索引）。
在這裡順便提一下，阿里雲DTS做同構資料遷移，使用的是資料庫自增ID做為唯一ID使用的，這種情況如果做雙向同步，會造成資料覆蓋的問題。解決方案也有，之前我們的做法是，新舊實體採用自增ID單雙號解決，保證新舊例項的自增ID不會出現衝突就行。因為這次我們使用的自研雙向同步元件，這個問題這裡不細聊。
分表規則梳理
分表規則不同決定著rehash和資料校驗的不同。需逐個表梳理是使用者ID緯度分表還是非使用者ID緯度分表、是否只分庫不分表、是否不分庫不分表等等。
2、 資料同步
資料同步整體方案見下圖，資料同步基於binlog，獨立的中間服務做同步，對業務程式碼無侵入。
接下來對每一個環節進行介紹。
歷史資料全量同步
單獨一個服務，使用遊標的方式從舊庫分批select資料，經過rehash後批量插入（batch insert）到新庫，此處需要配置jdbc連線串引數rewriteBatchedStatements=true才能使批處理操作生效。
另外特別需要注意的是，歷史資料也會存在不斷的更新，如果先開啟歷史資料全量同步，則剛同步完成的資料有可能不是最新的。所以這裡的做法是，先開啟增量資料單向同步（從舊庫到新庫），此時只是開啟積壓kafka訊息並不會真正消費；然後在開始歷史資料全量同步，當歷史全量資料同步完成後，在開啟消費kafka訊息進行增量資料同步（提高全量同步效率減少積壓也是關鍵的一環），這樣來保證遷移資料過程中的資料一致。
增量資料實時同步
增量資料同步考慮到灰度切流穩定性、容災和可回滾能力，採用實時雙向同步方案，切流過程中一旦新庫出現穩定性問題或者新庫出現資料一致問題，可快速回滾切回舊庫，保證資料庫的穩定和資料可靠。
增量資料實時同步採用基於阿里雲DTS的資料訂閱自研資料同步元件data-sync實現，主要方案是DTS資料訂閱能力會自動將被訂閱的資料庫binlog轉為kafka，data-sync元件訂閱kafka訊息、將訊息進行過濾、合併、分組、rehash、拆表、批量insert/update，最後再提交offset等一系列操作，最終完成資料同步工作。
- 過濾迴圈訊息：需要過濾掉迴圈同步的binlog訊息，這個問題比較重要後面將進行單獨介紹。
- 資料合併：同一條記錄的多條操作只保留最後一條。為了提高效能，data-sync元件接到kafka訊息後不會立刻進行資料流轉，而是先存到本地阻塞佇列，然後由本地定時任務每X秒將本地佇列中的N條資料進行資料流轉操作。此時N條資料有可能是對同一張表同一條記錄的操作，所以此處只需要保留最後一條（類似於redis aof重寫）。
- update轉insert：資料合併時，如果資料中有insert+update只保留最後一條update，會執行失敗，所以此處需要將update轉為insert語句。
- 按新表合併：將最終要提交的N條資料，按照新表進行拆分合並，這樣可以直接按照新表緯度進行資料庫批量操作，提高插入效率。
整個過程中有幾個問題需要注意：
問題1：怎麼防止因非同步訊息無順序而導致的資料一致問題？
首先kafka非同步訊息是存在順序問題的，但是要知道的是binlog是順序的，所以dts在對詳細進行kafka訊息投遞時也是順序的，此處要做的就是一個庫保證只有一個消費者就能保障資料的順序問題、不會出現資料狀態覆蓋，從而解決資料一致問題。
問題2：是否會有丟訊息問題，比如消費者服務重啟等情況下？
這裡沒有采用自動提交offset，而是每次消費資料最終入庫完成後，將offset非同步存到一個mysql表中，如果消費者服務重啟當機等，重啟後從mysql拿到最新的offset開始消費。這樣唯一的一個問題可能會出現瞬間部分訊息重複消費,但是因為上面介紹的binlog是順序的,所以能保證資料的最終一致。
問題3：update轉insert會不會丟欄位？
binlog是全欄位傳送,不會存在丟欄位情況。
問題4：迴圈訊息問題。
後面進行單獨介紹。
rehash
前文有提到，因為是256表變4096表，所以資料每一條都需要經過一次rehash重新做分庫分表的計算。
要說rehash，就不得不先介紹下當前訂單資料的分庫分表策略，訂單ID中冗餘了使用者ID的後四位，通過使用者ID後四位做hash計算確定庫號和表號。
資料同步過程中，從舊庫到新庫，需要拿到訂單ID中的使用者ID後四位模4096，確定資料在新庫中的庫表位置；從新庫到舊庫，則需要用使用者ID後四位模256，確定資料在舊庫中的庫表位置。
雙向同步時的binlog迴圈消費問題
想象一下，業務寫一條資料到舊例項的一張表，於是產生了一條binlog；data-sync中介軟體接到binlog後，將該記錄寫入到新例項，於是在新例項也產生了一條binlog；此時data-sync中介軟體又接到了該binlog......不斷迴圈，訊息越來越多，資料順序也被打亂。
怎麼解決該問題呢？我們採用資料染色方案，只要能夠標識寫入到資料庫中的資料使data-sync中介軟體寫入而非業務寫入，當下次接收到該binlog資料的時候就不需要進行再次訊息流轉。
所以data-sync中介軟體要求，每個資料庫例項建立一個事務表，該事務表tb_transaction只有id、tablename、status、create_time、update_time幾個欄位，status預設為0。
再回到上面的問題，業務寫一條資料到舊例項的一張表，於是產生了一條binlog；data-sync中介軟體接到binlog後，如下操作：
# 開啟事務，用事務保證一下sql的原子性和一致性
start transaction;
set autocommit = 0;
# 更新事務表status=1，標識後面的業務資料開始染色
update tb_transaction set status = 1 where tablename = ${tableName};
# 以下是業務產生binlog
insert xxx;
update xxx;
update xxx;
# 更新事務表status=0，標識後面的業務資料失去染色
update tb_transaction set status = 0 where tablename = ${tableName};
commit;此時data-sync中介軟體將上面這些語句打包一起提交到新例項，新例項更新資料後也會生產對應上面語句的binlog；當data-sync中介軟體再次接收到binlog時，只要判斷遇到tb_transaction表status=1的資料開始，後面的資料都直接丟棄不要，直到遇到status=0時，再繼續接收資料，以此來保證data-sync中介軟體只會流轉業務產生的訊息。
3、 資料校驗
資料校驗模組由資料校驗服務data-check模組來實現，主要是基於資料庫層面的資料對比，逐條核對每一個資料欄位是否一致，不一致的話會經過配置的校驗規則來進行重試或者報警。
全量校驗
- 以舊庫為基準，查詢每一條資料在新庫是否存在，以及個欄位是否一致。
- 以新庫為基準，查詢每一條資料在舊庫是否存在，以及個欄位是否一致。
實時校驗
- 定時任務每5分鐘校驗，查詢最近5+1分鐘舊庫和新庫更新的資料，做diff。
- 差異資料進行二次、三次校驗（由於併發和資料延遲存在），三次校驗都不同則報警。
4 、資料修復
經過資料校驗，一旦發現資料不一致，則需要對資料進行修復操作。
資料修復有兩種方案，一種是適用於大範圍的資料不一致，採用重置kafka offset的方式，重新消費資料訊息，將有問題的資料進行覆蓋。
四、 灰度切換資料來源
1 、整體灰度切流方案
整體灰度方案：SP+使用者緯度來實現，SP緯度：依靠灰度環境切量來做，使用者緯度：依賴使用者ID後四位百分比切流。
灰度切量的過程一定要配合停寫（秒級），為什麼要停寫，因為資料同步存在一定延遲（正常毫秒級），而所有業務操作一定要保障都在一個例項上，否則在舊庫中業務剛剛修改了一條資料，此時切換到新庫如果資料還沒有同步過來就是舊資料會有資料一致問題。所以步驟應該是：
- 先停寫
- 觀察資料全部同步完
- 在切換資料來源
- 最後關閉停寫，開始正常業務寫入
2 、切流前準備——ABC驗證
雖然在切流之前，在測試環境進過了大量的測試，但是測試環境畢竟和生產環境不一樣，生產環境資料庫一旦出問題就可能是滅頂之災，雖然上面介紹了資料校驗和資料修復流程，但是把問題攔截在發生之前是做服務穩定性最重要的工作。
因此我們提出了ABC驗證的概念，灰度環境ABC驗證準備：
- 新購買兩套資料庫例項，當前訂單庫為A，新買的兩套為分別為B、C
- 配置DTS從A單項同步到B（dts支援同構不需要rehash的資料同步），B做為舊庫的驗證庫，C庫做為新庫
- 用B和C做為生產演練驗證
- 當B和C演練完成之後，在將A和C配置為正式的雙向同步
3、 灰度切流步驟
具體灰度方案和資料來源切換流程：
- 程式碼提前配置好兩套資料庫分庫分表規則。
- 通過ACM配置灰度比例。
- 程式碼攔截mybatis請求，根據使用者id後四位取模，和ACM設定中設定的灰度比例比較，將新庫標識通過ThreadLocal傳遞到分庫分表元件。
- 判斷當前是否有灰度白名單，如命中將新庫標識通過ThreadLocal傳遞到分庫分表元件。
- 分庫分表元件根據ACM配置拿到新分庫的分表規則，進行資料庫讀寫操作。
- 切量時會配合ACM配置灰度比例命中的使用者進行停寫。
五 、總結
整個資料遷移過程還是比較複雜的，時間也不是很充裕（過程中還穿插著十一全鏈路壓測改造），在有限的時間內集大家之力重複討論挖掘可能存在的問題，然後論證解決方案，不放過任何一個可能出現問題的環節，還是那句話，把問題攔截在發生之前是做服務穩定性最重要的工作。
過程中的細節還是很多的，從資料遷移的準備工作到資料同步測試，從灰度流程確定到正式生產切換，尤其是結合業務和資料的特點，有很多需要考慮的細節，文中沒有一一列出。
最終經過近兩個月的緊張工作，無業務程式碼侵入、零事故、平穩地完成了擴分庫分表和資料遷移的工作。
作者：開發者小助手_LS
本文為阿里雲原創內容，未經允許不得轉載