本文內(nèi)容預(yù)覽：

   1.  庫(kù)表會(huì)在哪天到達(dá)瓶頸？

        1.1 蘇寧拼購(gòu)百萬(wàn)級(jí)庫(kù)表拆分之前

        1.2 京東配運(yùn)平臺(tái)庫(kù)表拆分之前

        1.3 大眾點(diǎn)評(píng)訂單庫(kù)拆分之前

        1.4 小結(jié)：啥情況需要考慮庫(kù)表拆分

   2.   拆分庫(kù)表的目的和方案

        2.1 業(yè)務(wù)數(shù)據(jù)解耦--垂直拆分

        2.2 解決容量和性能壓力--水平拆分

        2.3 分多少合適

        2.4 怎么分合適

    3.  拆分帶來(lái)新的問(wèn)題

        分區(qū)鍵/唯一ID/數(shù)據(jù)遷移/分布式事務(wù)等

    4.  大廠案例，知識(shí)回顧擴(kuò)展

        4.1 螞蟻金服的庫(kù)表路由規(guī)則

        4.2 大眾點(diǎn)評(píng)分庫(kù)分表的數(shù)據(jù)遷移

        4.3 淘寶萬(wàn)億級(jí)交易訂單的存儲(chǔ)引擎

 Part1庫(kù)表會(huì)在哪天到達(dá)瓶頸？

1.1蘇寧拼購(gòu)百萬(wàn)級(jí)庫(kù)表拆分之前[1]

蘇寧拼購(gòu)，蘇寧易購(gòu)旗下的電商App，18年7月累計(jì)用戶突破3000萬(wàn)。

圖片來(lái)源于QCon大會(huì)PPT

面對(duì)千萬(wàn)級(jí)日活 + 千萬(wàn)級(jí)日新增SKU + 千萬(wàn)級(jí)日均訂單，拼購(gòu)的單庫(kù)每天增長(zhǎng)數(shù)據(jù)超1億，峰值10萬(wàn)QPS并發(fā)，每個(gè)月要搞一次數(shù)據(jù)遷移。

龐大的數(shù)據(jù)量，對(duì)數(shù)據(jù)庫(kù)壓力和數(shù)據(jù)運(yùn)維成本造成了很大的困擾，并且，一旦有一條未命中緩存的SQL，對(duì)于整個(gè)應(yīng)用都是災(zāi)難級(jí)的。

所以，不得不考慮系統(tǒng)的穩(wěn)定性和長(zhǎng)遠(yuǎn)的業(yè)務(wù)支撐。

1.2京東配運(yùn)平臺(tái)庫(kù)表拆分之前[2]

圖片來(lái)源于QCon大會(huì)PPT

起初，用SQL Server存儲(chǔ)，⽀支撐每天10萬(wàn)級(jí)別業(yè)務(wù)量。

扛不住后，采購(gòu)了企業(yè)級(jí)Oracle/IBM AIX⼩型機(jī)，用 RAC + DataGuard方式，支撐配送所有業(yè)務(wù)，到百萬(wàn)級(jí)別單量。但是這種傳統(tǒng)的企業(yè)架構(gòu)，對(duì)于復(fù)雜多變的業(yè)務(wù)、昂貴的硬件成本、服務(wù)的部署和維護(hù)成本等痛點(diǎn)，變得越來(lái)越突出。

15年開(kāi)始，京東配運(yùn)平臺(tái)開(kāi)始按業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)做垂直拆分，將存儲(chǔ)容器化，實(shí)現(xiàn)了方便的水平擴(kuò)容、更精細(xì)的成本控制、更復(fù)雜的業(yè)務(wù)形態(tài)支持.

1.3大眾點(diǎn)評(píng)訂單庫(kù)拆分之前[3]

16年前，點(diǎn)評(píng)的訂單庫(kù)已經(jīng)超200G容量，面對(duì)的越來(lái)越復(fù)雜的查詢維度，為實(shí)現(xiàn)平穩(wěn)查詢，優(yōu)化了索引并增加兩個(gè)從庫(kù)來(lái)分散數(shù)據(jù)庫(kù)壓力，但仍有很多效率不理想的數(shù)據(jù)庫(kù)請(qǐng)求出現(xiàn)。

而隨后而來(lái)的價(jià)格戰(zhàn)、大量搶購(gòu)的活動(dòng)開(kāi)展，訂單數(shù)據(jù)庫(kù)很快難以支撐，只能用限流、消息隊(duì)列削峰填谷對(duì)其進(jìn)行保護(hù)，才能勉強(qiáng)維持日常數(shù)據(jù)讀寫(xiě)需求。

而隨著業(yè)務(wù)模式的增加，原訂單模型已經(jīng)不能滿足，如果經(jīng)常用DDL去建表，建索引對(duì)于如此龐大的庫(kù)表是非常吃力的，發(fā)生鎖庫(kù)鎖表會(huì)直接影響線上服務(wù)。

所以，點(diǎn)評(píng)團(tuán)隊(duì)以未來(lái)十年不再擔(dān)心訂單容量為目的，開(kāi)始進(jìn)行庫(kù)表切分。

1.4小結(jié)：啥情況需要考慮庫(kù)表拆分

實(shí)際上，是沒(méi)有一個(gè)非常量化的指標(biāo)來(lái)判定庫(kù)表瓶頸的，因?yàn)槊總€(gè)系統(tǒng)的業(yè)務(wù)場(chǎng)景，查詢復(fù)雜度都有不同。

但力有窮盡時(shí)，我們雖然可以盡量的從加從庫(kù)讀寫(xiě)分離、優(yōu)化sql、優(yōu)化索引、復(fù)用連接等等方面進(jìn)行優(yōu)化，但總會(huì)有到達(dá)極限的時(shí)候的時(shí)候，量變引發(fā)質(zhì)變。甚至，在真實(shí)生產(chǎn)環(huán)境，要更加未雨綢繆，不能等到崩了才去考慮。那么，應(yīng)該怎么去判斷已經(jīng)到了庫(kù)表拆分的時(shí)機(jī)呢：

•  硬件性能瓶頸，如果是讀操作多，其實(shí)可以加多個(gè)從庫(kù)分擔(dān)主庫(kù)讀壓力；但如果是寫(xiě)操作多，會(huì)因?yàn)橹鲙?kù)磁盤(pán)IO增大，拖慢處理速度；另外，如果單表數(shù)據(jù)量過(guò)大，導(dǎo)致索引層級(jí)增多，掃描行增多，CPU效率降低，影響sql執(zhí)行效率，拖慢處理速度。而處理速度慢最終會(huì)導(dǎo)致連接數(shù)增加直至無(wú)連接可用。
•  日常運(yùn)維投入，就如蘇寧拼購(gòu)的情況，如果一個(gè)月就要搞一次數(shù)據(jù)遷移，這個(gè)人力的投入產(chǎn)出比，應(yīng)該是完全不匹配的，那就不如一次性搞定它。
•  業(yè)務(wù)發(fā)展可支持程度、難度和風(fēng)險(xiǎn)，當(dāng)數(shù)據(jù)增長(zhǎng)到一定程度，雖然沒(méi)有達(dá)到極限，還能湊活，但是遇到活動(dòng)型流量脈沖，無(wú)法完全支持業(yè)務(wù)需求；而業(yè)務(wù)需要進(jìn)行迭代增加模式時(shí)，修改數(shù)據(jù)表帶來(lái)的風(fēng)險(xiǎn)又比較大。就可以考慮重構(gòu)數(shù)據(jù)模型，拆分庫(kù)表了。

Part2拆分庫(kù)表的目的和方案

2.1業(yè)務(wù)數(shù)據(jù)解耦--垂直拆分

把不同的業(yè)務(wù)數(shù)據(jù)拆分到各自的數(shù)據(jù)庫(kù)中獨(dú)立維護(hù)，那么最底層的原因是什么呢？

是微服務(wù)下的上層服務(wù)拆分。為了滿足快速迭代、安全發(fā)布、鏈路降級(jí)、主次業(yè)務(wù)解耦等問(wèn)題，去解決代碼大量沖突、小功能排隊(duì)等待大版本發(fā)布等等問(wèn)題，將業(yè)務(wù)按照一定邏輯進(jìn)行拆解，形成一個(gè)個(gè)功能完備，獨(dú)立運(yùn)行的服務(wù)。[4]

然而，如果數(shù)據(jù)庫(kù)層面不配合，就無(wú)法解決根本問(wèn)題。當(dāng)上層服務(wù)實(shí)例拆分后可以被大量橫向擴(kuò)展，以應(yīng)對(duì)高并發(fā)的流量沖擊，會(huì)導(dǎo)致底層數(shù)據(jù)庫(kù)的承載壓力和連接數(shù)急劇增加。

所以，通過(guò)垂直拆分將業(yè)務(wù)數(shù)據(jù)解耦，各管一事，以滿足微服務(wù)的效能最大化。

2.2解決容量和性能壓力--水平拆分

對(duì)某一業(yè)務(wù)庫(kù)，當(dāng)數(shù)據(jù)增量達(dá)到了庫(kù)瓶頸，或者表瓶頸，就要進(jìn)行庫(kù)表的水平拆分了。

我之前遇到的很多情況，總是先分表，解決單表的容量和讀寫(xiě)性能問(wèn)題，隨著業(yè)務(wù)發(fā)展，單庫(kù)也遇到瓶頸了再考慮分庫(kù)。

為啥不一步到位？

就像之前在阿里，新應(yīng)用上來(lái)搞個(gè)百庫(kù)百表？一來(lái)是因?yàn)橐恍┯脩粢?guī)模和一些路由規(guī)則的問(wèn)題；更重要的，不是所有公司其實(shí)不是所有的公司都和阿里一樣有錢，有限的資源要用在更重要的生存問(wèn)題上。

如果你作為一個(gè)初創(chuàng)公司的架構(gòu)，給出了一套可能撐10年的存儲(chǔ)方案，感覺(jué)會(huì)被同事在心里懟，公司能活3年么就這么浪費(fèi)？

但肯定沒(méi)有人說(shuō)這話，因?yàn)槲覀冞€是希望所有公司都能蓬勃發(fā)展，蒸蒸日上的☺。

所以，拆分方法就很有講究了，怎么分能讓后續(xù)迭代發(fā)展的代價(jià)最小呢？

2.3分多少合適

表主要看容量，很多經(jīng)驗(yàn)表明 上千萬(wàn)后性能會(huì)有顯著下降，因此，我們可以把表容量定在一半多一點(diǎn)，600w。

庫(kù)主要看的是連接數(shù)，我們以阿里對(duì)外售賣的云存儲(chǔ)來(lái)大致估計(jì)，單庫(kù)的連接數(shù)定在4000左右。

抽象一個(gè)實(shí)際的評(píng)估案例來(lái)看：假如目前平臺(tái)每天產(chǎn)生10w訂單，峰值并發(fā)數(shù)8000QPS，然后考慮業(yè)務(wù)擴(kuò)展和增長(zhǎng)的速率：

比如，業(yè)務(wù)是和銀行合作擴(kuò)展業(yè)務(wù)，將大小銀行量級(jí)平均一下，估計(jì)每合作一家可以帶來(lái)多大的增長(zhǎng)量，這里假設(shè)是5000單/天/家，如果業(yè)務(wù)計(jì)劃是每年度合作10家，那就是5w，5年以后每天的單量，理論上可能會(huì)到25w/天。加上現(xiàn)有的10w, 峰值35w。

如果我們計(jì)劃系統(tǒng)的容量需要支撐3年，或者說(shuō)，3年之后的該業(yè)務(wù)擴(kuò)展會(huì)趨于平緩，那么我們可以大致的估計(jì)為： 

表：（3年 * 365天 * 335w=3.8億 ）/600w = 63 約 64張表.  
庫(kù)：10000并發(fā) / 4000 = 2.5 ,可按4個(gè)庫(kù)來(lái)處理 

當(dāng)然，如果是BAT這種，不缺用戶，不缺錢，又有一些既定路由規(guī)則的情況，還是可以一步到位的。比如，我之前做過(guò)的項(xiàng)目就是按百庫(kù)百表來(lái)做。關(guān)于阿里的玩法后面再詳細(xì)介紹一下。

發(fā)現(xiàn)上述評(píng)估有問(wèn)題的話，歡迎留言討論~

2.4怎么分合適

Hash取模

優(yōu)點(diǎn)：經(jīng)過(guò)hash取模之后，分到庫(kù)和分到表中的數(shù)據(jù)，都是均衡的，所以，不會(huì)出現(xiàn)資源傾斜的問(wèn)題。

缺點(diǎn)：如果后續(xù)遇到業(yè)務(wù)暴增，沒(méi)有在我們預(yù)估范圍內(nèi)，則要涉及到數(shù)據(jù)遷移，那就需要重新hash , 遷移數(shù)據(jù)，修改路由等等。

range劃分

簡(jiǎn)單說(shuō)，就是把數(shù)據(jù)劃分范圍，挨個(gè)存儲(chǔ)，存滿一個(gè)再存另一個(gè)。

優(yōu)點(diǎn)：不需要數(shù)據(jù)遷移，后續(xù)數(shù)據(jù)即時(shí)增長(zhǎng)很多也沒(méi)問(wèn)題。

缺點(diǎn)：數(shù)據(jù)傾斜嚴(yán)重，比如上圖，很長(zhǎng)一段時(shí)間，都會(huì)只用到1個(gè)庫(kù)，幾個(gè)表。

一致性hash

一致性hash環(huán)的節(jié)點(diǎn)一般按2^32-1來(lái)算，但是一般如果業(yè)務(wù)ID足夠均衡，則可以降一些節(jié)點(diǎn)，如4096等等，4個(gè)庫(kù)的話，則均衡的分布在圖上的位置，而數(shù)據(jù)通過(guò)hash計(jì)算，對(duì)應(yīng)到外環(huán)的虛擬節(jié)點(diǎn)，然后歸屬于真實(shí)的庫(kù)，對(duì)于表也可以同樣處理?；蛘?，直接把表節(jié)點(diǎn)部署在外環(huán)上，直接將數(shù)據(jù)歸屬于表。

優(yōu)點(diǎn)：更加均勻，并且在需要擴(kuò)容時(shí)，數(shù)據(jù)遷移的量級(jí)更小，只需要遷移1/N的數(shù)據(jù)即可。

缺點(diǎn)：路由算法要復(fù)雜，但是對(duì)于能得到的好處，這點(diǎn)復(fù)雜度就可以忽略了

小結(jié)

那么,看起來(lái)，一致性hash的方法，是比較靠譜的了。但是只是這樣就會(huì)對(duì)程序員很友好么？

我不知道其他公司，呆過(guò)的某一家公司，的數(shù)據(jù)查詢后臺(tái)是純天然的，不帶任何修飾的，想要check下數(shù)據(jù)，得拿業(yè)務(wù)ID手動(dòng)計(jì)算庫(kù)表的位置。沒(méi)經(jīng)歷過(guò)的不知道，真的是要煩死了。

在技術(shù)設(shè)施方面，還是不得不佩服大公司的投入，阿里給工程師提供的數(shù)據(jù)查詢后臺(tái)，其實(shí)是一個(gè)邏輯庫(kù)，你可以用查詢單表的方式去查詢分庫(kù)分表，后臺(tái)會(huì)調(diào)用數(shù)據(jù)庫(kù)配置平臺(tái)的配置，自動(dòng)計(jì)算庫(kù)表路由，人性化的很。就算不去計(jì)算路由，直接打包查詢多個(gè)庫(kù)也是很好的，畢竟界面查詢，能有多大并發(fā)呢。

還是那句話，沒(méi)有銀彈，其實(shí)除了這幾種方式，還見(jiàn)過(guò)不少變種，但都是結(jié)合本公司，本業(yè)務(wù)的特性進(jìn)行的改良。

Part3拆分帶來(lái)新的問(wèn)題

分區(qū)鍵選取

分區(qū)鍵要足夠的均勻，比如，用戶表用UID，訂單表可以用UID，也可以用訂單ID，商戶表用商戶ID，問(wèn)題表用會(huì)話ID 等等，總之，一定可以找到業(yè)務(wù)上的唯一ID。當(dāng)然還有一些特殊的分區(qū)，比如，日表，月表，則要按時(shí)間來(lái)分，等等。

全局唯一主鍵ID

實(shí)際我理解這個(gè)就是分布式ID的生成問(wèn)題，之前寫(xiě)的一篇分布式ID生成算法，有興趣可以瀏覽下。

數(shù)據(jù)平滑遷移

停機(jī)發(fā)布：好處是簡(jiǎn)單，風(fēng)險(xiǎn)?。蝗秉c(diǎn)是業(yè)務(wù)有損。那就看這個(gè)損能不能接受了

平滑遷移：平滑遷移就像是高速上換輪胎，要非常小心謹(jǐn)慎，也更復(fù)雜。思路可以類比快手kafka集群的擴(kuò)容：

雖然場(chǎng)景不一樣，但是思路使一致的。從某一點(diǎn)開(kāi)始設(shè)置checkpoint , 然后執(zhí)行數(shù)據(jù)雙寫(xiě)，最后修改路由，刪除舊數(shù)據(jù)，完成擴(kuò)容。

事務(wù)問(wèn)題

之前由于數(shù)據(jù)都在一個(gè)庫(kù)中，所以，只要保證一個(gè)本地事務(wù)就可以辦到?，F(xiàn)在數(shù)據(jù)被分到了多個(gè)庫(kù)，那么事務(wù)怎么保證：

（1）分布式事務(wù)。分布式事務(wù)的方式很多，TCC、本地事務(wù)表+事務(wù)消息、最大努力通知，saga等等，之前有篇寫(xiě)我們自研的saga長(zhǎng)事務(wù)引擎的文章，有興趣的可以看下。

（2）程序+業(yè)務(wù)邏輯。用業(yè)務(wù)邏輯+程序控制的方式，比如，之前文章中提到的微信紅包的系統(tǒng)設(shè)計(jì)，用set化將一個(gè)紅包的所有操作都落到同一個(gè)庫(kù)上，避免了數(shù)據(jù)庫(kù)鎖競(jìng)爭(zhēng)和分布式事務(wù)。而螞蟻的支付業(yè)務(wù)涉及了業(yè)務(wù)訂單庫(kù)、計(jì)收費(fèi)庫(kù)、支付庫(kù)、積分庫(kù)等等，沒(méi)有辦法從業(yè)務(wù)邏輯層面進(jìn)行完全串聯(lián)，并且由于金融屬性的強(qiáng)一致要求，采用了非常重的侵入式TCC來(lái)保證全局支付事務(wù)的一致。

查詢問(wèn)題

之前一個(gè)庫(kù)就能搞定的join，count等各種聯(lián)合查詢，將不復(fù)存在，老老實(shí)實(shí)調(diào)接口在代碼層面實(shí)現(xiàn)吧。

Part4大廠案例，知識(shí)回顧擴(kuò)展

4.1螞蟻金服的庫(kù)表路由規(guī)則

上文也提到過(guò)，螞蟻的分庫(kù)分表其實(shí)是獨(dú)樹(shù)一幟的。因?yàn)?，在螞蟻體系下，需要遵守LDC單元化部署，單元化的路由有用戶ID的倒數(shù)2，3位來(lái)決定。加上螞蟻的用戶規(guī)模，基本上大部分的應(yīng)用都采用了百庫(kù)百表類的方式進(jìn)行(遇到定時(shí)任務(wù)的超大規(guī)模數(shù)據(jù)，還會(huì)千庫(kù)千表的存在)。用戶請(qǐng)求發(fā)起后的路由規(guī)則和數(shù)據(jù)庫(kù)的路由執(zhí)行鏈路簡(jiǎn)化如下：

而一條訂單的入庫(kù)路由規(guī)則可以參考下面的示意圖：[5]

螞蟻中間件產(chǎn)品介紹

這樣的機(jī)制保證生成的 ID 支持 10 萬(wàn)億次獲取不重復(fù)。

有人可能會(huì)問(wèn)，這個(gè)大的訂單量，一個(gè)庫(kù)也撐不了多久??？

是的，比如之前搞的一個(gè)應(yīng)用，其實(shí)是百庫(kù)百表+定時(shí)數(shù)據(jù)遷移來(lái)實(shí)現(xiàn)的。業(yè)務(wù)數(shù)據(jù)每固定時(shí)間進(jìn)行歷史表遷移。而查詢的時(shí)候的庫(kù)表路由，都由中間件ZDAL從配置平臺(tái)拉取配置來(lái)決定，是走歷史庫(kù)還是走當(dāng)前庫(kù)。

4.2大眾點(diǎn)評(píng)分庫(kù)分表的數(shù)據(jù)遷移

•  階段一：數(shù)據(jù)雙寫(xiě)，以老數(shù)據(jù)為準(zhǔn)。通過(guò)對(duì)賬補(bǔ)平差異
•  階段二：導(dǎo)入歷史數(shù)據(jù)，繼續(xù)雙寫(xiě)，讀切到新數(shù)據(jù)。
•  階段三：停掉雙寫(xiě)，刪除老數(shù)據(jù)完成遷移

4.3淘寶萬(wàn)億級(jí)交易訂單的存儲(chǔ)引擎[6]

淘寶超級(jí)量級(jí)下的交易單是怎么解決存儲(chǔ)性能等問(wèn)題的：

可以看到，該方式和上面說(shuō)過(guò)的歷史訂單遷移的方式是如初一轍的。

Part5總結(jié)

一篇文章不可能窮盡所有知識(shí)點(diǎn)，如有遺漏和錯(cuò)誤，歡迎補(bǔ)充和指正，原創(chuàng)不易，歡迎轉(zhuǎn)發(fā)。