文章摘要：在設(shè)計(jì)系統(tǒng)時(shí)只洒，需要根據(jù)實(shí)際的業(yè)務(wù)情況來選用合適的組件構(gòu)建系統(tǒng)。

在互聯(lián)網(wǎng)時(shí)代称诗，隨著業(yè)務(wù)數(shù)量的暴增和應(yīng)用規(guī)模的不斷擴(kuò)大，無論是oracle還是mysql這樣子的關(guān)系型數(shù)據(jù)庫春弥，都會(huì)面臨服務(wù)器CPU、磁盤IO和內(nèi)存的各種瓶頸問題叠荠∧渑妫基于此情況，各個(gè)業(yè)務(wù)團(tuán)隊(duì)迫切需要一種數(shù)據(jù)分片的方案將業(yè)務(wù)數(shù)據(jù)量存儲(chǔ)成本分?jǐn)偟匠杀究煽氐母鱾€(gè)普通數(shù)據(jù)庫服務(wù)器上榛鼎，數(shù)據(jù)庫切分的方案便應(yīng)運(yùn)而生逃呼。

由于之前發(fā)布的一篇文章《記一次使用ShardingJdbc切分?jǐn)?shù)據(jù)庫表的SpringBoot工程實(shí)踐》評(píng)論中，有部分同學(xué)覺得還沒有結(jié)合實(shí)際情況來進(jìn)行場景深度分析與介紹者娱，讓讀者還無法完全理解為何需要選用開源ShardingJdbc組件和選用其構(gòu)建業(yè)務(wù)系統(tǒng)帶來的一些優(yōu)勢抡笼。因此，寫本文意在結(jié)合實(shí)際的業(yè)務(wù)場景進(jìn)行分析黄鳍，詳細(xì)闡述選型開源組件—ShardingJdbc時(shí)候的一些思考推姻，并最終給讀者呈現(xiàn)業(yè)務(wù)系統(tǒng)集成ShardingJdbc的最終設(shè)計(jì)方案。另外框沟，本文僅為使用開源組件ShardingJdbc第一篇幅藏古，后續(xù)篇幅還將繼續(xù)介紹開源組件ShardingJdbc的一些其他進(jìn)階用法。

一忍燥、數(shù)據(jù)的切分方式

一般拧晕，線上系統(tǒng)的業(yè)務(wù)量不是很大，比如說單庫的數(shù)據(jù)量在百萬級(jí)別以下梅垄，那么MySQL的單庫即可完成任何增/刪/改/查的業(yè)務(wù)操作厂捞。隨著業(yè)務(wù)的發(fā)展，單個(gè)DB中保存的數(shù)據(jù)量（用戶队丝、訂單靡馁、計(jì)費(fèi)明細(xì)和權(quán)限規(guī)則等數(shù)據(jù)）呈現(xiàn)指數(shù)級(jí)增長，那么各種業(yè)務(wù)處理操作都會(huì)面臨單DB的IO讀寫瓶頸帶來的性能問題炭玫。

（1）垂直切分方案

這時(shí)候奈嘿，我們會(huì)考慮使用對(duì)之前的整個(gè)單DB采用垂直數(shù)據(jù)切分的方案貌虾，根據(jù)不同的業(yè)務(wù)類型劃分庫表吞加，比如訂單相關(guān)若干表放在訂單庫，用戶相關(guān)的表放在用戶庫尽狠，賬務(wù)明細(xì)相關(guān)的表放在賬務(wù)庫等衔憨。這樣就將數(shù)據(jù)分擔(dān)到了不同的庫上，達(dá)到專庫專用的效果袄膏。

使用垂直切分方案的主要優(yōu)點(diǎn)如下：

a.拆分后業(yè)務(wù)清晰践图，符合微服務(wù)的總體設(shè)計(jì)理念；

b.子系統(tǒng)之間的整合與擴(kuò)展相對(duì)容易沉馆；

c.按照不同的業(yè)務(wù)類型码党，將不同的庫表放在不同的數(shù)據(jù)庫服務(wù)器上德崭，便于管理；

d.根據(jù)業(yè)務(wù)數(shù)據(jù)的“冷”揖盘、“熱”狀態(tài)眉厨，采用不同的緩存和數(shù)據(jù)庫模式設(shè)計(jì)方案；

垂直切分的缺點(diǎn)如下：

a.跨庫的Join查詢兽狭，需要使用不同子系統(tǒng)的API接口讀取后在內(nèi)存中完成關(guān)聯(lián)查詢憾股，提高系統(tǒng)復(fù)雜度；

b.如果某一種類型的業(yè)務(wù)呈現(xiàn)爆發(fā)式地增長箕慧，該業(yè)務(wù)對(duì)應(yīng)的庫表還是會(huì)存在單DB的IO讀寫的瓶頸問題服球，從這一點(diǎn)來說垂直切分并未從根本解決單庫單表數(shù)據(jù)量過大的問題；

c.存在跨庫事務(wù)的一致性問題颠焦，解決起來比較麻煩斩熊，當(dāng)然也可以采用分布式事務(wù)來解決；

（2）水平切分方案

由于本文主題講的是利用開源組件ShardingJdbc進(jìn)行數(shù)據(jù)水平切分的實(shí)踐伐庭，因此對(duì)于垂直切分方案的一些細(xì)節(jié)問題就不做過多的詳細(xì)介紹了座享。與垂直切分對(duì)比，這里講的水平切分不是將庫表根據(jù)業(yè)務(wù)類型進(jìn)行分類存儲(chǔ)似忧，而是將其按照數(shù)據(jù)表中某個(gè)字段或某幾個(gè)字段的某種規(guī)則切分存儲(chǔ)至多個(gè)DB中渣叛，在每個(gè)庫每個(gè)表中所包含的只是其中的一部分?jǐn)?shù)據(jù)，所有庫表加起來的才是全量的業(yè)務(wù)數(shù)據(jù)盯捌。

這種對(duì)數(shù)據(jù)的切分方式淳衙，基本可以保證經(jīng)過水平切分后的單庫單表存儲(chǔ)的容量不會(huì)太大，從而保證了對(duì)單表的增/刪/改/查的SQL執(zhí)行效率和處理能力饺著。其中箫攀，數(shù)據(jù)的分片規(guī)則也是需要重點(diǎn)考慮的，因?yàn)樗鼤?huì)使得數(shù)據(jù)分片在多個(gè)庫表中是否均勻分布存儲(chǔ)幼衰。然而靴跛，數(shù)據(jù)水平切分方案為業(yè)務(wù)系統(tǒng)帶來福音的同時(shí)也給系統(tǒng)構(gòu)建帶來了一些值得思考的問題。

使用水平切分方案的主要優(yōu)點(diǎn)如下：

a.單庫單表的數(shù)據(jù)容量可以維持在一個(gè)量級(jí)渡嚣，有助于提高業(yè)務(wù)SQL的執(zhí)行效率和系統(tǒng)性能梢睛；

b.不管是利用ShardingJdbc組件還是MyCat框架，業(yè)務(wù)系統(tǒng)的應(yīng)用層涉及改造得都較少识椰，只需要根據(jù)實(shí)際的業(yè)務(wù)情況來設(shè)計(jì)數(shù)據(jù)分片的路由規(guī)則即可绝葡；

c.可以提高業(yè)務(wù)系統(tǒng)的穩(wěn)定性和負(fù)載能力；

使用水平切分方案的主要缺點(diǎn)如下：

a.數(shù)據(jù)水平切分后腹鹉，分布在多庫多表中藏畅，跨庫Join查詢比較復(fù)雜；

b.分片數(shù)據(jù)的一致性較為難保證功咒；

c.對(duì)于歷史數(shù)據(jù)的遷移和數(shù)據(jù)庫的擴(kuò)容需要較大的維護(hù)工作量愉阎；

二绞蹦、選型ShardingJdbc組件的分析與思考

對(duì)于，“流水”/“明細(xì)”一類的業(yè)務(wù)數(shù)據(jù)榜旦，通常的業(yè)務(wù)需求是準(zhǔn)實(shí)時(shí)或者說相對(duì)滯后坦辟，這些數(shù)據(jù)是按小時(shí)、按日和按月匯總加工處理后生成最終業(yè)務(wù)需求的數(shù)據(jù)（比如用戶賬單章办、報(bào)表和話單）锉走。此外，由于這一類型的業(yè)務(wù)數(shù)據(jù)量普遍較大藕届，比如清算系統(tǒng)的清分明細(xì)挪蹭、云管平臺(tái)的資源計(jì)量明細(xì)、訂單系統(tǒng)的訂單流水和云計(jì)算主機(jī)資源上報(bào)的性能數(shù)據(jù)等休偶，如果只是使用單庫單表存儲(chǔ)的普通方案梁厉，那么在單表數(shù)據(jù)量達(dá)到千萬級(jí)別以上的時(shí)候，單庫的IO讀寫能力將持續(xù)降低踏兜，會(huì)成為業(yè)務(wù)系統(tǒng)整體吞吐量和性能的瓶頸词顾。

對(duì)于上述的問題，有一些對(duì)DB較為熟悉的同學(xué)第一時(shí)間想到的解決方案碱妆，可能會(huì)是MySQL的分區(qū)表肉盹。MySQL的分區(qū)表比較適合用于解決業(yè)務(wù)數(shù)據(jù)具有較強(qiáng)時(shí)間序列特點(diǎn)，且數(shù)據(jù)量偏大的場景疹尾。但是上忍，如果SQL的查詢條件并非基于時(shí)間維度的，那么執(zhí)行起來的效率并不會(huì)有所改觀纳本，同時(shí)對(duì)于處理單表千萬級(jí)別以上數(shù)據(jù)量時(shí)窍蓝，MySQL的分區(qū)表方案還是會(huì)顯得有些“力不從心”。

對(duì)于以上這種“流水”/“明細(xì)”類的業(yè)務(wù)數(shù)據(jù)繁成，作者還是推薦使用水平切分的方案從根本上來解決業(yè)務(wù)上遇到的單表數(shù)據(jù)過大的問題吓笙。由于該類型的業(yè)務(wù)數(shù)據(jù)基本不會(huì)涉及跨庫的Join連表SQL查詢、只需保證分庫的本地事務(wù)巾腕，且并不會(huì)遇到上面水平切分方案中的幾個(gè)需要考慮的問題面睛，對(duì)于這樣子的業(yè)務(wù)場景可以考慮使用水平切分的方案。那么祠墅，我們應(yīng)該選擇哪一款開源的分庫分表組件侮穿，又或者是根據(jù)業(yè)務(wù)情況來自己定制化研發(fā)呢歌径？

（1）選型分庫分表中間件的分析

如果業(yè)務(wù)系統(tǒng)設(shè)計(jì)之初打算采用水平切分方案的話毁嗦，那么有必要好好思考下如何來選型分庫分表的中間件。在當(dāng)前的開源組件中比較流行的兩款分別為ShardingJdbc和MyCat回铛。

ShardingJdbc這款分庫分表組件代表了客戶端類的分庫分表技術(shù)框架狗准，其定位為輕量級(jí)數(shù)據(jù)庫驅(qū)動(dòng)克锣，可以由Spring Boot這樣的業(yè)務(wù)工程直接快速集成，以jar包形式提供服務(wù)腔长，無需額外部署和其他依賴袭祟。對(duì)于業(yè)務(wù)系統(tǒng)的開發(fā)人員與數(shù)據(jù)庫運(yùn)維人員無需改變?cè)械拈_發(fā)與運(yùn)維方式。在2.X版本中捞附，采用"半理解"理念的SQL解析引擎巾乳，以達(dá)到性能與兼容性的最大平衡。因此鸟召，ShardingJdbc即為增強(qiáng)版的JDBC驅(qū)動(dòng)胆绊，其優(yōu)勢在于無需對(duì)原有的業(yè)務(wù)工程進(jìn)行任何改造的基礎(chǔ)上，即可使其擁有分庫分表的能力欧募，成本較低压状，易于上手。但是跟继，也有缺點(diǎn)种冬，中間件與業(yè)務(wù)應(yīng)用工程綁定在一起，對(duì)應(yīng)用本身有侵入舔糖。并且目前只支持Java語言娱两，問題難以追蹤。

而MyCat是一個(gè)開源的分布式數(shù)據(jù)庫系統(tǒng)（屬于代理類框架）金吗，相當(dāng)于一個(gè)實(shí)現(xiàn)了MySQL協(xié)議的數(shù)據(jù)庫代理服務(wù)器谷婆。用戶可以使用MySQL客戶端工具和命令行訪問，而其后端使用MySQL原生協(xié)議與多個(gè)MySQL數(shù)據(jù)庫服務(wù)器通信辽聊，也可以用JDBC協(xié)議與大多數(shù)主流數(shù)據(jù)庫服務(wù)器通信纪挎。其分庫分表的方案優(yōu)點(diǎn)在于，能夠處理非常復(fù)雜的需求跟匆，不受數(shù)據(jù)庫訪問層原來實(shí)現(xiàn)的限制异袄，擴(kuò)展性強(qiáng)且對(duì)于應(yīng)用服務(wù)透明且沒有增加任何額外負(fù)載。其缺點(diǎn)是上線部署需要額外的中間件玛臂，增加運(yùn)維成本烤蜕；應(yīng)用服務(wù)需經(jīng)過代理來連接數(shù)據(jù)庫，網(wǎng)絡(luò)上多了一層鏈接的開銷迹冤，性能有損失且有額外風(fēng)險(xiǎn)讽营。

（2）使用ShardingJdbc解決的基本業(yè)務(wù)場景

選擇ShardingJdbc組件后，就需要使用該組件來解決實(shí)際的問題泡徙。這一節(jié)主要根據(jù)之前提到的“流水”/“明細(xì)”一類的業(yè)務(wù)數(shù)據(jù)橱鹏，同時(shí)結(jié)合ShardingJdbc組件的特點(diǎn)來進(jìn)行一定的分析，使得讀者對(duì)正確使用ShardingJdbc組件進(jìn)行業(yè)務(wù)系統(tǒng)水平切分有一定的了解。

前面已經(jīng)提到了“流水”/“明細(xì)”類的業(yè)務(wù)數(shù)據(jù)莉兰，一般是準(zhǔn)實(shí)時(shí)或者說相對(duì)滯后挑围，需要按小時(shí)、按日和按月匯總處理后生成最終的業(yè)務(wù)數(shù)據(jù)（如賬單糖荒、報(bào)表和話單等）杉辙。我們對(duì)“流水”/“明細(xì)型”業(yè)務(wù)數(shù)據(jù)處理過程中，一般都會(huì)涉及數(shù)據(jù)落庫（Insert?SQL）捶朵、數(shù)據(jù)分組匯總和分組查詢（Select+sum(xxx)+Group By SQL）以及刪除數(shù)據(jù)表（Delete?SQL）等業(yè)務(wù)處理操作蜘矢。這里有必要對(duì)這幾種類型的SQL進(jìn)行一定的說明：

a. 數(shù)據(jù)落庫（Insert SQL）:流水/明細(xì)類的數(shù)據(jù)一般都需要先DB持久化處理；以云計(jì)算平臺(tái)中10W臺(tái)虛擬機(jī)同時(shí)產(chǎn)生性能明細(xì)數(shù)據(jù)上報(bào)综看，如果是單庫單表硼端，則這個(gè)數(shù)據(jù)庫會(huì)進(jìn)行每小時(shí)會(huì)有10W次的寫請(qǐng)求；如果使用100個(gè)分表（分10個(gè)庫寓搬，每庫10個(gè)表）則每個(gè)表平均承受1000次寫請(qǐng)求珍昨，每個(gè)庫平均分擔(dān)1W次的請(qǐng)求壓力，這樣子就可以將原來單庫單表的寫請(qǐng)求壓力成倍的減少句喷；一般業(yè)務(wù)研發(fā)人員使用ShardingJdbc組件镣典，設(shè)置合理的數(shù)據(jù)分片路由規(guī)則，即可使得流水/明細(xì)類的數(shù)據(jù)基本均勻落在我們預(yù)先設(shè)置的分庫分表中唾琼。

b. 數(shù)據(jù)分組匯總查詢（Select+sum(xxx)+Group?By SQL）：由于（a）中持久化至分庫分表的業(yè)務(wù)數(shù)據(jù)為若干段時(shí)間的業(yè)務(wù)數(shù)據(jù)兄春，根據(jù)業(yè)務(wù)需求還需要按日，按周或者按月進(jìn)行累加匯總锡溯，因此有必要對(duì)各個(gè)分表中的數(shù)據(jù)執(zhí)行Select+sum(xxx)+Group?By的分組匯總SQL赶舆；ShardingJdbc組件可以完成SQL的解析、改寫祭饭、路由和結(jié)果歸并芜茵，對(duì)于“Select+sum(xxx)+Group By SQL”的語句，可以遍歷設(shè)置的多個(gè)分庫分表倡蝙，對(duì)每個(gè)分庫分表執(zhí)行SQL后進(jìn)行一個(gè)結(jié)果歸并再返回給業(yè)務(wù)調(diào)用方九串。

c. 刪除數(shù)據(jù)表（Delete SQL）：一般業(yè)務(wù)系統(tǒng)對(duì)會(huì)通過定時(shí)任務(wù)來生成明細(xì)數(shù)據(jù)加工處理后的業(yè)務(wù)數(shù)據(jù)（比如用戶賬單、清償明細(xì)寺鸥、云資源按日按月的話單）猪钮。一旦生成這些有效業(yè)務(wù)數(shù)據(jù)后，原來落庫的明細(xì)也就沒有什么業(yè)務(wù)價(jià)值胆建，可以通過任務(wù)定期刪除或者遷移至歷史庫的方式來使得分庫分表的數(shù)據(jù)水位量級(jí)維持在一定量烤低，因此就需要涉及對(duì)原來存儲(chǔ)在分庫分表的明細(xì)數(shù)據(jù)進(jìn)行刪除；ShardingJdbc組件可以根據(jù)“Delete?SQL”語句中的篩選條件進(jìn)行規(guī)則路由來定位某個(gè)分庫和分表笆载，否則會(huì)刪除所有分庫中的分表數(shù)據(jù)扑馁。

三涯呻、業(yè)務(wù)系統(tǒng)集成ShardingJdbc的架構(gòu)設(shè)計(jì)

根據(jù)上面對(duì)“流水”/“明細(xì)”型業(yè)務(wù)數(shù)據(jù)的場景分析，基本可以畫出SpringBoot業(yè)務(wù)工程集成分庫分表組件ShardingJdbc的架構(gòu)設(shè)計(jì)圖：

從上面業(yè)務(wù)系統(tǒng)架構(gòu)設(shè)計(jì)圖中可以看出檐蚜，明細(xì)型業(yè)務(wù)數(shù)據(jù)（比如之前提的魄懂，清算系統(tǒng)的清分明細(xì)沿侈、云管平臺(tái)的資源計(jì)量明細(xì)闯第、訂單系統(tǒng)的訂單流水和云計(jì)算主機(jī)資源上報(bào)的性能數(shù)據(jù)明細(xì)）根據(jù)設(shè)置的數(shù)據(jù)分片路由規(guī)則先落庫至sharding_db00~sharding_db04五個(gè)分庫的對(duì)應(yīng)分表中。然后缀拭，利用ShardingJdbc組件對(duì)分組匯總查詢SQL的解析咳短、改寫、路由和歸并結(jié)果的能力蛛淋，分別對(duì)五個(gè)庫中對(duì)應(yīng)業(yè)務(wù)分表中的數(shù)據(jù)匯總累加求出每天/每月同一個(gè)用戶下的資源計(jì)費(fèi)累加值咙好。最后，將這些“加工”后的業(yè)務(wù)數(shù)據(jù)批量插入至共享庫share_db中褐荷，其他定時(shí)任務(wù)再從共享庫中讀取并生成最終形式的業(yè)務(wù)數(shù)據(jù)（比如勾效，按月的賬單、話單或者性能計(jì)量值）叛甫。其中层宫，對(duì)于異常情況（明細(xì)流水異常、匯總異常和系統(tǒng)異常等）其监，需要將其保存至共享庫中的異常信息表中萌腿。另外，在明細(xì)落庫之前還需要考慮冪等前置校驗(yàn)的問題抖苦。對(duì)于ShardingJdbc組件的分庫分表路由規(guī)則可以參照下圖：

從上面的分庫分表路由規(guī)則圖上可以看出毁菱，預(yù)先設(shè)置了通過客戶id來路由定位至分庫，通過用戶id來路由定位至分表锌历。這里贮庞，由原來的單庫單表分成五個(gè)庫的多分表（每個(gè)庫中均有test_msg_queue_bill_record0～test_msg_queue_bill_record4五個(gè)分表，這里只是示例究西，在真實(shí)的業(yè)務(wù)場景下需要根據(jù)業(yè)務(wù)數(shù)據(jù)的總體容量來設(shè)定分庫分表的規(guī)模贸伐，究竟是分5個(gè)庫每個(gè)庫5表，還是分10個(gè)庫每個(gè)庫10表來滿足業(yè)務(wù)要求）怔揩。在一般情況下捉邢，如果執(zhí)行的SQL為“select * from?test_msg_queue_bill_record”就能借助ShardingJdbc組件來遍歷查完5個(gè)分庫中的test_msg_queue_bill_record0~4五個(gè)分表，無需我們自己來做分庫分表的遍歷查詢了商膊。

四伏伐、總結(jié)

本文先介紹了目前兩種數(shù)據(jù)切分的主要方案（垂直切分和水平切分）及其優(yōu)缺點(diǎn)。根據(jù)“流水”/“明細(xì)”類別的數(shù)據(jù)切分業(yè)務(wù)場景晕拆，闡述了業(yè)務(wù)系統(tǒng)設(shè)計(jì)之初選型分庫分表組件的分析藐翎，并介紹了如何利用ShardingJdbc來解決“數(shù)據(jù)落庫（Insert?SQL）”材蹬、“數(shù)據(jù)分組匯總查詢（Select+sum(xxx)+Group By SQL）”和“刪除數(shù)據(jù)表（Delete?SQL）”的幾種基本業(yè)務(wù)場景。最后吝镣，給出業(yè)務(wù)系統(tǒng)集成ShardingJdbc組件后的架構(gòu)設(shè)計(jì)方案堤器。本文僅僅使用了Sharding-Jdbc組件的核心功能來解決了一部分基本的業(yè)務(wù)場景問題。ShardingJdbc組件還有其他很多高級(jí)的功能（比如讀寫分離末贾、最大努力送達(dá)型的柔性事務(wù)闸溃、分片路由規(guī)則動(dòng)態(tài)配置和數(shù)據(jù)庫治理和ShardingProxy等，ps:聽@亮哥說拱撵，ShardingJdbc?3.0起可以完美支持Batch?Insert SQL辉川，很是期待），限于篇幅將在后續(xù)的文章中結(jié)合對(duì)應(yīng)的場景進(jìn)行介紹拴测。限于筆者的才疏學(xué)淺乓旗，對(duì)本文內(nèi)容可能還有理解不到位的地方，如有闡述不合理之處還望留言一起探討集索。