億級別大表拆分心路歷程

# 前言

筆者是在兩年前接手公司的財(cái)務(wù)系統(tǒng)的開發(fā)和維護(hù)工作。在系統(tǒng)移交的初期，筆者和團(tuán)隊(duì)就發(fā)現(xiàn)，系統(tǒng)內(nèi)有一張5000W+的大表。

跟蹤代碼發(fā)現(xiàn)，該表是用于存儲資金流水的表格，關(guān)聯(lián)著眾多功能點(diǎn)，同時也有眾多的下游系統(tǒng)在使用這張表的數(shù)據(jù)。

進(jìn)一步的觀察發(fā)現(xiàn)，這張表還在以每月600W+的數(shù)據(jù)持續(xù)增長，也就是說，不超過半年，這張表會增長到1個億！

這個數(shù)據(jù)量，對于mysql數(shù)據(jù)庫來說是絕對無法繼續(xù)維護(hù)的了，因此在接手系統(tǒng)兩個月后，我們便開起了大表拆分的專項(xiàng)工作。（兩個月時間實(shí)際上主要用來熟悉系統(tǒng)、消化堆積需求了）

# 拆表前系統(tǒng)狀態(tài)

涉及到流水表流水的接口超時頻發(fā)，部分接口基本不可用

每日新增流水緩慢，主要是插入數(shù)據(jù)庫的時候非常慢

單表占用空間過大，DBA的數(shù)據(jù)庫監(jiān)控經(jīng)常報(bào)警

無法對表進(jìn)行變更，任何alter操作都會引起主從的高延遲和長時間鎖表

# 拆表的目標(biāo)

將流水大表數(shù)據(jù)拆分至各個分表，保證每張分表數(shù)據(jù)在1000W左右（經(jīng)驗(yàn)上看單表1000W的量對mysql來說沒啥壓力）

在拆表的前提下，針對不同接口的查詢條件進(jìn)行優(yōu)化，保證各個對外、對內(nèi)接口的可用性。徹底殺死m(xù)ysql慢查詢。

# 難點(diǎn)分析

該表的數(shù)據(jù)可以說是整個財(cái)務(wù)系統(tǒng)最基礎(chǔ)的數(shù)據(jù)，相關(guān)功能和下游系統(tǒng)非常多。這要求開發(fā)、測試和上線流程必須極其嚴(yán)密，任何小失誤都會引起大問題。

涉及的場景非常多。統(tǒng)計(jì)下來，一共有26個場景，需要改造32個mapper方法，具體需要改造的方法就更加無計(jì)其數(shù)了。

數(shù)據(jù)量非常大，遷移數(shù)據(jù)的過程必須保證系統(tǒng)穩(wěn)定。

用戶較多且功能重要。分表功能上線時，必須盡量壓縮系統(tǒng)無法使用時長，同時需要保證系統(tǒng)可用性。這要求團(tuán)隊(duì)必須設(shè)計(jì)完整可靠的上線流程、數(shù)據(jù)遷移方案、回滾方案、降級策略。

上文提到，表的拆分勢必帶來部分接口的變化，接口的變化又會帶來其他系統(tǒng)的改造。如何推動其他系統(tǒng)進(jìn)行改造，如何協(xié)調(diào)多方合作的開發(fā)、測試和上線是另一個難點(diǎn)。

# 整體過程

# 具體細(xì)節(jié)

分表中間件調(diào)研

分表插件：采用sharding-jdbc作為分表插件。

其優(yōu)勢如下：

1、支持多種分片策略，自動識別=或in判斷具體在哪張分表里。

2、輕量級，作為maven依賴引入即可，對業(yè)務(wù)的侵入性極低。

為提升查詢速度，在整個項(xiàng)目的初期，團(tuán)隊(duì)成員考慮引入ES存儲流水以提升查詢速度。

經(jīng)過與ES維護(hù)團(tuán)隊(duì)的兩輪討論，發(fā)現(xiàn)公司提供的ES服務(wù)對于我們的業(yè)務(wù)場景并不匹配（見表），經(jīng)過反復(fù)考量，最終我們放棄了引入ES的計(jì)劃，直接從數(shù)據(jù)庫查詢數(shù)據(jù)，采用每張表設(shè)置一個查詢線程的方式提升查詢效率。

分表依據(jù)的選擇

分表的方式有很多種，有縱向分表，有橫向分表，有分為固定的幾個表存儲然后取模進(jìn)行表拆分等等?？偟膩碚f，適合我們具體業(yè)務(wù)的分表方式只有橫向分表。

因?yàn)閷τ谫Y金流水這種特殊數(shù)據(jù)來說，是不能清理數(shù)據(jù)的，那么縱向分表和拆成固定的幾個表都不能解決單表數(shù)據(jù)無限膨脹的問題。而橫向分表，可以把每張表的數(shù)據(jù)量恒定，到一定時間后可以進(jìn)行財(cái)務(wù)數(shù)據(jù)歸檔。

分表的依據(jù)一般都是根據(jù)表的某個或者某幾個字段進(jìn)行拆分，最終其實(shí)是對數(shù)據(jù)和業(yè)務(wù)分析綜合出來的結(jié)果?？偟膩碚f，原則有這幾個：

盡可能選擇查詢條件里最常出現(xiàn)的字段，這樣能夠減少方法改造的工程

需要考慮根據(jù)某個字段拆分?jǐn)?shù)據(jù)是否能夠均勻分布，是否能夠滿足單表1000W左右的要求

該字段必須是必現(xiàn)字段，不允許出現(xiàn)空值

綜合分析我們的數(shù)據(jù)以及業(yè)務(wù)需要，“交易時間”這個分表依據(jù)就呼之欲出了。

首先，這個字段作為流水最重要的字段之一一定會出現(xiàn)；

第二，如果按照交易月份進(jìn)行拆表，每張表大概也就是600W-700W的數(shù)據(jù)；

最后，有70%的查詢都附帶“交易時間”作為查詢條件。

技術(shù)難點(diǎn)

多數(shù)據(jù)源事務(wù)問題

sharding-jdbc在使用的時候是需要用自己的獨(dú)立數(shù)據(jù)源的，那么就難免出現(xiàn)多數(shù)據(jù)源事務(wù)問題。

這個我們通過自定義注解，自定義切面開啟事務(wù)，通過方法棧逐層回滾or提交的方式解決的。出于保密原則，具體代碼細(xì)節(jié)不再展開。

多表的分頁問題

拆表一定會引起分頁查詢的難度增加。由于各個表查出來的數(shù)據(jù)量不等，原始的sql語句limit不再適用，需要設(shè)計(jì)一個新方法便捷的獲取分頁信息。

在此介紹一個分頁的思路供大家參考（團(tuán)隊(duì)共同的成果，筆者不敢私自占有）：

綜合考慮業(yè)務(wù)實(shí)際與開發(fā)的復(fù)雜程度，項(xiàng)目團(tuán)隊(duì)決定在出現(xiàn)跨表查詢的情況下，每一張表采用一個線程進(jìn)行查詢，以提高查詢效率。

這個方案的難點(diǎn)在于分頁規(guī)則的轉(zhuǎn)換。例如，頁面?zhèn)魅氲膐ffset和pageSize分別為8和20。各分表中符合條件的數(shù)量分別為10,10,50。那么我們需要將總的分頁條件轉(zhuǎn)化為三個分表各自的分頁條件，如圖

通過上圖可以看到，大分頁條件(offset=8,pageSize=20)，轉(zhuǎn)換為(offset=8,pageSize=2)，(offset=0.pageSize=10)，(offset=0,pageSize=8)三個條件。

整個計(jì)算過程如下：

1) 多線程查詢各個分表中滿足條件的數(shù)據(jù)數(shù)量

2) 將各個表數(shù)量按照分表的先后順序累加，形成圖 8的數(shù)軸

3) 判斷第一條數(shù)據(jù)和最后一條數(shù)據(jù)所在的表

4) 除第一條和最后一條數(shù)據(jù)所在表外，其他表offset=0，pageSize=總數(shù)量

5) 計(jì)算第一條數(shù)據(jù)的offset，pageSize

計(jì)算最后一條數(shù)據(jù)的pageSize，同時將該表查詢條件的offset設(shè)置為0

數(shù)據(jù)遷移方案

在數(shù)據(jù)遷移前，團(tuán)隊(duì)討論過兩套遷移方案：

1)請DBA遷移數(shù)據(jù)；

2)手寫代碼遷移數(shù)據(jù)，他們各有自己的優(yōu)缺點(diǎn)：

綜合考慮時間成本和對線上數(shù)據(jù)庫的影響，團(tuán)隊(duì)決定采用兩種方案結(jié)合的方式：

交易時間為三個月前的冷數(shù)據(jù)，由于更新幾率不大，采用代碼的方式遷移，人為控制每次遷移數(shù)量，少量多次，螞蟻搬家；

交易時間為三個月內(nèi)的熱數(shù)據(jù)，由于會在上線前頻繁出現(xiàn)更新操作，則在上線前停止寫操作，而后由DBA整體遷移。這樣將時間成本平攤到平時，上線前只有約2個小時左右遷移數(shù)據(jù)時系統(tǒng)無法使用。

同時，除了最后一次DBA遷移數(shù)據(jù)外，能夠人為控制每次遷移的數(shù)據(jù)量，整體避免數(shù)據(jù)庫實(shí)例級別的高延遲。

整體上線流程

為保證新表拆分功能的穩(wěn)定性和大表下線的穩(wěn)定，團(tuán)隊(duì)將整個項(xiàng)目分為三個階段：

第一階段：建立分表，大表數(shù)據(jù)遷移分表，線上數(shù)據(jù)新表老表雙寫，所有查詢走分表（驗(yàn)證觀察）

第二階段：停止寫老數(shù)據(jù)表，其他業(yè)務(wù)直連數(shù)據(jù)庫改為資金提供對外接口（驗(yàn)證觀察）

第三階段：大表下線

# 總結(jié)

應(yīng)再進(jìn)一步調(diào)研分表相關(guān)中間件。由于項(xiàng)目分表依據(jù)的特殊性，導(dǎo)致sharding-jdbc的很多功能無法利用，其對于簡化查詢邏輯的幫助低于預(yù)期。并且sharding-jdbc獨(dú)立數(shù)據(jù)源的特性，引發(fā)了多數(shù)據(jù)源事務(wù)問題，反而增加了開發(fā)的工作量。

多線程需要仔細(xì)分析線程池核心線程的大小，同時分析多線程池同時存在的時候是否會引起核心線程數(shù)過多，避免機(jī)器線程打滿。

如果是一個已有的項(xiàng)目，在進(jìn)行分表改造時，一定要將各種場景都羅列清楚，將各個場景細(xì)化到程序中的每個類、每個方法中，將所有業(yè)務(wù)場景都覆蓋到。

在遷移歷史數(shù)據(jù)時，一定要做好遷移數(shù)據(jù)方案，以及應(yīng)對出現(xiàn)數(shù)據(jù)不一致時的處理方案。要綜合考慮時間成本、數(shù)據(jù)準(zhǔn)確性、對線上功能的影響等諸多因素。

在上線一個比較復(fù)雜的方案時，一定要提前設(shè)計(jì)好回滾方案和降級措施，能夠極大保證穩(wěn)定性。

# 說點(diǎn)兒題外話

為啥說想說點(diǎn)兒題外話呢，主要是對這次延續(xù)了5個多月的項(xiàng)目有感而發(fā)。項(xiàng)目進(jìn)行過程中，難免會與其他系統(tǒng)的維護(hù)團(tuán)隊(duì)有工作上的交集，有需要其他團(tuán)隊(duì)配合的地方。

這個時候非?？简?yàn)程序員的溝通能力，最優(yōu)秀的程序員能夠通過話術(shù)把對方拉到自己的陣線當(dāng)中，讓對方感到這項(xiàng)工作對自己也是有好處的。這樣能夠讓對方心甘情愿的配合你的工作，達(dá)到雙贏的目的。

如果程序設(shè)計(jì)和學(xué)習(xí)能力是程序員的硬實(shí)力，那溝通技巧就是程序員的軟實(shí)力，硬實(shí)力能夠保障你的下線，而決定上線的恰恰是軟實(shí)力。

因此很多程序員不注重溝通技巧的培養(yǎng)，其實(shí)是相當(dāng)于瘸腿的，畢竟現(xiàn)在憑單打獨(dú)斗是不大可能做出事情的。

另外，至少對于我們單位來說，對后端程序員的綜合素質(zhì)其實(shí)要求最高。后端程序員集業(yè)務(wù)、技術(shù)于一身。需要有比較強(qiáng)的業(yè)務(wù)把控能力，還要有過硬的技術(shù)素質(zhì)。

同時，大多數(shù)工作的主owner是后端，一般都是后端程序員把控前端、后端、QA的開發(fā)節(jié)奏，協(xié)調(diào)好各個時間點(diǎn)，做好風(fēng)險(xiǎn)反饋。

這就要求后端程序員既要懂業(yè)務(wù)，還要懂技術(shù)，還需要有一定的管理能力。這其實(shí)對人的鍛煉還是很可觀的。

審核編輯 ：李倩