數(shù)據(jù)庫(kù)中間件之分庫(kù)分表

切入層次

① 編碼層

② 框架層

③ 驅(qū)動(dòng)層

④ 代理層

⑤ 實(shí)現(xiàn)層

驅(qū)動(dòng)層和代理層對(duì)比

驅(qū)動(dòng)層特點(diǎn)

代理層特點(diǎn)

共同點(diǎn)

使用限制

產(chǎn)品

流程解決方案

信息收集

前期準(zhǔn)備

實(shí)施階段

題外話

數(shù)據(jù)庫(kù)中間件之分庫(kù)分表

恭喜你，貴公司終于成長(zhǎng)到一定規(guī)模，需要考慮高可用，甚至分庫(kù)分表了。但你是否知道分庫(kù)分表需要哪些要素？拆分過(guò)程是復(fù)雜的，提前計(jì)劃，不要等真正開(kāi)工，各種意外的工作接踵而至，以至失控。

本文意圖打開(kāi)數(shù)據(jù)庫(kù)中間件的廣度，而不考慮實(shí)現(xiàn)深度，至于庫(kù)表垂直和水平分的概念和緣由，不做過(guò)多解釋。所以此文面向的是有一定研發(fā)經(jīng)驗(yàn)，正在尋找選型和拆分流程的專(zhuān)業(yè)人士。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

切入層次

以下，范圍界定在JAVA和MySQL中。我們首先來(lái)看一下分庫(kù)分表切入的層次。

① 編碼層

在同一個(gè)項(xiàng)目中創(chuàng)建多個(gè)數(shù)據(jù)源，采用if else的方式，直接根據(jù)條件在代碼中路由。Spring中有動(dòng)態(tài)切換數(shù)據(jù)源的抽象類(lèi)，具體參見(jiàn)AbstractRoutingDataSource。

如果項(xiàng)目不是很龐大，使用這種方式能夠快速的進(jìn)行分庫(kù)。但缺點(diǎn)也是顯而易見(jiàn)的，需要編寫(xiě)大量的代碼，照顧到每個(gè)分支。當(dāng)涉及跨庫(kù)查詢(xún)、聚合，需要循環(huán)計(jì)算結(jié)果并合并的場(chǎng)景，工作量巨大。

如果項(xiàng)目裂變，此類(lèi)代碼大多不能共用，大多通過(guò)拷貝共享。長(zhǎng)此以往，碼將不碼。

② 框架層

這種情況適合公司ORM框架統(tǒng)一的情況，但在很多情況下不太現(xiàn)實(shí)。主要是修改或增強(qiáng)現(xiàn)有ORM框架的功能，在SQL中增加一些自定義原語(yǔ)或者h(yuǎn)int來(lái)實(shí)現(xiàn)。

通過(guò)實(shí)現(xiàn)一些攔截器（比如Mybatis的Interceptor接口），增加一些自定義解析來(lái)控制數(shù)據(jù)的流向，效果雖然較好，但會(huì)改變一些現(xiàn)有的編程經(jīng)驗(yàn)。

很多情況要修改框架源碼，不推薦。

③ 驅(qū)動(dòng)層

基于在編碼層和框架層切入的各種缺點(diǎn)，真正的數(shù)據(jù)庫(kù)中間件起碼要從驅(qū)動(dòng)層開(kāi)始。什么意思呢？其實(shí)就是重新編寫(xiě)了一個(gè)JDBC的驅(qū)動(dòng)，在內(nèi)存中維護(hù)一個(gè)路由列表，然后將請(qǐng)求轉(zhuǎn)發(fā)到真正的數(shù)據(jù)庫(kù)連接中。

像TDDL、ShardingJDBC等，都是在此層切入。

包括Mysql Connector/J的Failover協(xié)議 (具體指“l(fā)oad balancing”、“replication”、“farbic”等）， 也是直接在驅(qū)動(dòng)上進(jìn)行修改。

請(qǐng)求流向一般是這樣的：

④ 代理層

代理層的數(shù)據(jù)庫(kù)中間件，將自己偽裝成一個(gè)數(shù)據(jù)庫(kù)，接受業(yè)務(wù)端的鏈接。然后負(fù)載業(yè)務(wù)端的請(qǐng)求，解析或者轉(zhuǎn)發(fā)到真正的數(shù)據(jù)庫(kù)中。

像MySQL Router、MyCat等，都是在此層切入。

請(qǐng)求流向一般是這樣的：

⑤ 實(shí)現(xiàn)層

SQL特殊版本支持，如Mysql cluster本身就支持各種特性，mariadb galera cluster支持對(duì)等雙主，Greenplum支持分片等。

需要換存儲(chǔ)，一般是解決方案，就不在討論之列了。

技術(shù)最終都會(huì)趨于一致，選擇任何一種、都是可行的。但最終選型，受開(kāi)發(fā)人員熟悉度、社區(qū)活躍度、公司切合度、官方維護(hù)度、擴(kuò)展性，以及公司現(xiàn)有的數(shù)據(jù)庫(kù)產(chǎn)品等多方位因素影響。選擇或開(kāi)發(fā)一款合適的，小伙伴們會(huì)幸福很多。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

驅(qū)動(dòng)層和代理層對(duì)比

通過(guò)以上層次描述，很明顯，我們選擇或開(kāi)發(fā)中間件，就集中在驅(qū)動(dòng)層和代理層。在這兩層，能夠?qū)?shù)據(jù)庫(kù)連接和路由進(jìn)行更強(qiáng)的控制和更細(xì)致的管理。但它們的區(qū)別也是明顯的。

驅(qū)動(dòng)層特點(diǎn)

僅支持JAVA，支持豐富的DB

驅(qū)動(dòng)層中間件僅支持Java一種開(kāi)發(fā)語(yǔ)言，但支持所有后端關(guān)系型數(shù)據(jù)庫(kù)。如果你的開(kāi)發(fā)語(yǔ)言固定，后端數(shù)據(jù)源類(lèi)型豐富，推薦使用此方案。

占用較多的數(shù)據(jù)庫(kù)連接

驅(qū)動(dòng)層中間件要維護(hù)很多數(shù)據(jù)庫(kù)連接。比如一個(gè)分了10個(gè) 庫(kù) 的表，每個(gè)java中的Connection要維護(hù)10個(gè)數(shù)據(jù)庫(kù)連接。如果項(xiàng)目過(guò)多，則會(huì)出現(xiàn)連接爆炸（我們算一下，如果每個(gè)項(xiàng)目6個(gè)實(shí)例，連接池中minIdle等于5，3個(gè)項(xiàng)目的連接總數(shù)是 10*6*5*3 = 900 個(gè)）。像Postgres這種每個(gè)連接對(duì)應(yīng)一個(gè)進(jìn)程的數(shù)據(jù)庫(kù)，壓力會(huì)很大。

數(shù)據(jù)聚合在業(yè)務(wù)實(shí)例執(zhí)行

數(shù)據(jù)聚合，比如count sum等，是通過(guò)多次查詢(xún)，然后在業(yè)務(wù)實(shí)例的內(nèi)存中進(jìn)行聚合。

路由表存在于業(yè)務(wù)方實(shí)例內(nèi)存中，通過(guò)輪詢(xún)或者被動(dòng)通知的途徑更新路由表即可。

集中式管理

所有集群的配置管理都集中在一個(gè)地方，運(yùn)維負(fù)擔(dān)小，DBA即可完成相關(guān)操作。

典型實(shí)現(xiàn)

代理層特點(diǎn)

異構(gòu)支持，DB支持有限

代理層中間件正好相反。僅支持一種后端關(guān)系型數(shù)據(jù)庫(kù)，但支持多種開(kāi)發(fā)語(yǔ)言。如果你的系統(tǒng)是異構(gòu)的，并且都有同樣的SLA要求，則推薦使用此方案。

運(yùn)維負(fù)擔(dān)大

代理層需要維護(hù)數(shù)據(jù)庫(kù)連接數(shù)量有限（MySQL Router那種粘性連接除外）。但作為一個(gè)獨(dú)立的服務(wù)，既要考慮單獨(dú)部署，又要考慮高可用，會(huì)增加很多額外節(jié)點(diǎn)，更別提用了影子節(jié)點(diǎn)的公司了。另外，代理層是請(qǐng)求唯一的入口，穩(wěn)定性要求極高，一旦有高耗內(nèi)存的聚合查詢(xún)把節(jié)點(diǎn)搞崩潰了，都是災(zāi)難性的事故。

典型實(shí)現(xiàn)

共同點(diǎn)

篇幅有限，不做過(guò)多討論。訪問(wèn)各中間件宣傳頁(yè)面，能夠看到長(zhǎng)長(zhǎng)的Feature列表，也就是白名單；也能看到長(zhǎng)長(zhǎng)的限制列表，也就是黑名單。限定了你怎么玩，在增強(qiáng)了分布式能力后，分庫(kù)分表本身就是一個(gè)閹割的數(shù)據(jù)庫(kù)。

使用限制

確保數(shù)據(jù)均衡

拆分?jǐn)?shù)據(jù)庫(kù)的數(shù)據(jù)盡量均勻，比如按省份分user庫(kù)不均勻，按userid取模會(huì)比較均勻

不用深分頁(yè)

不帶切分鍵的深分頁(yè)，會(huì)取出所有庫(kù)所取頁(yè)數(shù)之前的所有數(shù)據(jù)在內(nèi)存排序計(jì)算。容易造成內(nèi)存溢出。

減少子查詢(xún)

子查詢(xún)會(huì)造成SQL解析紊亂，解析錯(cuò)誤的情況，盡量減少SQL的子查詢(xún)。

事務(wù)最小原則

盡量縮小單機(jī)事務(wù)涉及的庫(kù)范圍，即盡可能減少夸庫(kù)操作，將同類(lèi)操作的庫(kù)/表分在一起

數(shù)據(jù)均衡原則

拆分?jǐn)?shù)據(jù)庫(kù)的數(shù)據(jù)盡量均勻，比如按省份分user庫(kù)不均勻，按userid取模會(huì)比較均勻

特殊函數(shù)

distinct、having、union、in、or等，一般不被支持?；蛘弑恢С?，使用之后會(huì)增加風(fēng)險(xiǎn)，需要改造。

產(chǎn)品

建議聚焦在MyCat和ShardingJDBC上。另外，還有大量其他的中間件，不熟悉建議不要妄動(dòng)。數(shù)據(jù)庫(kù)中間件不好維護(hù)，你會(huì)發(fā)現(xiàn)大量半死不活的項(xiàng)目。

以下列表，排名不分先后，有幾個(gè)是只有HA功能，沒(méi)有拆分功能的：

Atlas、Kingshard、DBProxy、mysql router、MaxScale、58 Oceanus、ArkProxy、Ctrip DAL、Tsharding、Youtube vitess、網(wǎng)易DDB、Heisenberg、proxysql、Mango、DDAL、Datahekr、MTAtlas、MTDDL、Zebra、Cobar、Cobar

汗、幾乎每個(gè)大廠都有自己的數(shù)據(jù)庫(kù)中間件（還發(fā)現(xiàn)了幾個(gè)喜歡拿開(kāi)源組件加公司前綴作為產(chǎn)品的），只不過(guò)不給咱用罷了。

流程解決方案

無(wú)論是采用哪個(gè)層面切入進(jìn)行分庫(kù)分表，都面臨以下工作過(guò)程。

信息收集

統(tǒng)計(jì)影響的業(yè)務(wù)和項(xiàng)目

項(xiàng)目范圍越大，分庫(kù)難度越高。有時(shí)候，一句復(fù)雜的SQL能夠涉及四五個(gè)業(yè)務(wù)方，這種SQL都是需要重點(diǎn)關(guān)注的。

確定分庫(kù)分表的規(guī)模，是只分其中的幾張表，還是全部涉及。分的越多，工作量越大，幾乎是線性的。

還有一些項(xiàng)目是牽一發(fā)動(dòng)全身的。舉個(gè)例子，下面這個(gè)過(guò)程，影響的鏈路就不僅是分庫(kù)這么簡(jiǎn)單了。

確定參與人員

除了分庫(kù)分表組件的技術(shù)支持人員，最應(yīng)該參與的是對(duì)系統(tǒng)、對(duì)現(xiàn)有代碼最熟悉的幾個(gè)人。只有他們能夠確定哪些SQL該廢棄掉、SQL的影響面等。

確定分庫(kù)分表策略

確定分庫(kù)分表的維度和切分鍵。切分鍵（就是路由數(shù)據(jù)的column）一旦確定，是不允許修改的，所以在前期架構(gòu)設(shè)計(jì)上，應(yīng)該首先將其確立下來(lái)，才能進(jìn)行后續(xù)的工作；數(shù)據(jù)維度多意味著有不同的切分鍵，達(dá)到不同條件查詢(xún)的效果。這涉及到數(shù)據(jù)的冗余（多寫(xiě)、數(shù)據(jù)同步），會(huì)更加復(fù)雜。

前期準(zhǔn)備

數(shù)據(jù)規(guī)整

庫(kù)表結(jié)構(gòu)不滿足需求，需要提前規(guī)整。比如，切分鍵的字段名稱(chēng)不同或者類(lèi)型各異。在實(shí)施分庫(kù)分表策略時(shí)，這些個(gè)性會(huì)造成策略過(guò)大不好維護(hù)。

掃描所有SQL

將項(xiàng)目中所有的SQL掃描出來(lái)，逐個(gè)判斷是否能夠按照切分鍵正常運(yùn)行。在判斷過(guò)程中肯定會(huì)有大量不合規(guī)的SQL，則都需要給出改造方案，這是主要的工作量之一。

驗(yàn)證工具支持

直接在原有項(xiàng)目上進(jìn)行改動(dòng)和驗(yàn)證是可行的，但會(huì)遇到諸多問(wèn)題，主要是效率太低。我傾向于首先設(shè)計(jì)一些驗(yàn)證工具，輸入要驗(yàn)證的SQL或者列表，然后打印路由信息和結(jié)果進(jìn)行判斷。

技術(shù)準(zhǔn)備

建議以下提到的各個(gè)點(diǎn)，都找一個(gè)例子體驗(yàn)一下，然后根據(jù)自己的團(tuán)隊(duì)預(yù)估難度。

以下：中間件所有不支持的SQL類(lèi)型 整理容易造成崩潰的注意事項(xiàng) 不支持的SQL給出處理方式 考慮一個(gè)通用的主鍵生成器 考慮沒(méi)有切分鍵的SQL如何處理 考慮定時(shí)任務(wù)等掃全庫(kù)的如何進(jìn)行遍歷 考慮跨庫(kù)跨表查詢(xún)?nèi)绾胃脑?準(zhǔn)備一些工具集

實(shí)施階段

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

分庫(kù)分表會(huì)重新影響數(shù)據(jù)的分布，無(wú)論是全量還是增量，都會(huì)涉及到數(shù)據(jù)遷移，所以Databus是必要的。

一種理想的狀態(tài)是所有的增刪改都是消息，可以通過(guò)訂閱MQ進(jìn)行雙寫(xiě)。

但一般情況下，仍然需要去模擬這個(gè)狀態(tài)，比如使用Canal組件。

怎么保證數(shù)據(jù)安全的切換，我們分其他章節(jié)進(jìn)行討論。

充足的測(cè)試

分庫(kù)分表必須經(jīng)過(guò)充足的測(cè)試，每一句SQL都要經(jīng)過(guò)嚴(yán)格的驗(yàn)證。如果有單元測(cè)試或者自動(dòng)化測(cè)試工具，完全的覆蓋是必要的。一旦有數(shù)據(jù)進(jìn)行了錯(cuò)誤的路由，尤其是增刪改，將會(huì)創(chuàng)造大量的麻煩。

在測(cè)試階段，將驗(yàn)證過(guò)程輸出到單獨(dú)的日志文件，充足測(cè)試后review日志文件是否有錯(cuò)誤的數(shù)據(jù)流向。

SQL復(fù)驗(yàn)

強(qiáng)烈建議統(tǒng)一進(jìn)行一次SQL復(fù)驗(yàn)。主要是根據(jù)功能描述，確定SQL的正確性，也就是通常說(shuō)的review。

演練

在非線上環(huán)境多次對(duì)方案進(jìn)行演練，確保萬(wàn)無(wú)一失。

制定新的SQL規(guī)范

分庫(kù)分表以后，項(xiàng)目中的SQL就加了枷鎖，不能夠隨意書(shū)寫(xiě)了。很多平常支持的操作，在拆分環(huán)境下就可能運(yùn)行不了了。所以在上線前，涉及的SQL都應(yīng)該有一個(gè)確認(rèn)過(guò)程，即使已經(jīng)經(jīng)過(guò)了充足的測(cè)試。

題外話

沒(méi)有支持的活別接，干不成。

分庫(kù)分表是戰(zhàn)略性的技術(shù)方案，很多情況無(wú)法回退或者回退方案復(fù)雜。如果要拆分的庫(kù)表涉及多個(gè)業(yè)務(wù)方，公司技術(shù)人員復(fù)雜，CTO要親自掛帥進(jìn)行協(xié)調(diào)，并有專(zhuān)業(yè)仔細(xì)的架構(gòu)師進(jìn)行監(jiān)督。沒(méi)有授權(quán)的協(xié)調(diào)人員會(huì)陷入尷尬的境地，導(dǎo)致流程失控項(xiàng)目難產(chǎn)。

審核編輯：劉清