談到分庫(kù)分表中間件時(shí)，我們自然而然的會(huì)想到 ShardingSphere-JDBC 。

這篇文章，我們聊聊 ShardingSphere-JDBC 相關(guān)知識(shí)點(diǎn)，并實(shí)戰(zhàn)演示一番。

【資料圖】

1 ShardingSphere 生態(tài)

Apache ShardingSphere 是一款分布式的數(shù)據(jù)庫(kù)生態(tài)系統(tǒng)，它包含兩大產(chǎn)品：

ShardingSphere-Proxy ShardingSphere-JDBC

▍一、ShardingSphere-Proxy

ShardingSphere-Proxy 被定位為透明化的數(shù)據(jù)庫(kù)代理端，提供封裝了數(shù)據(jù)庫(kù)二進(jìn)制協(xié)議的服務(wù)端版本，用于完成對(duì)異構(gòu)語(yǔ)言的支持。

代理層介于應(yīng)用程序與數(shù)據(jù)庫(kù)間，每次請(qǐng)求都需要做一次轉(zhuǎn)發(fā)，請(qǐng)求會(huì)存在額外的時(shí)延。

這種方式對(duì)于應(yīng)用非常友好，應(yīng)用基本零改動(dòng)，和語(yǔ)言無(wú)關(guān)，可以通過(guò)連接共享減少連接數(shù)消耗。

▍二、ShardingSphere-JDBC

ShardingSphere-JDBC 是 ShardingSphere 的第一個(gè)產(chǎn)品，也是 ShardingSphere 的前身， 我們經(jīng)常簡(jiǎn)稱(chēng)之為：sharding-jdbc 。

它定位為輕量級(jí) Java 框架，在 Java 的 JDBC 層提供的額外服務(wù)。它使用客戶端直連數(shù)據(jù)庫(kù)，以 jar 包形式提供服務(wù)，無(wú)需額外部署和依賴(lài)，可理解為增強(qiáng)版的 JDBC 驅(qū)動(dòng)，完全兼容 JDBC 和各種 ORM 框架。

當(dāng)我們?cè)?Proxy 和 JDBC 兩種模式選擇時(shí)，可以參考下表對(duì)照：

	JDBC	Proxy
數(shù)據(jù)庫(kù)	任意	MySQL/PostgreSQL
連接消耗數(shù)	高	低
異構(gòu)語(yǔ)言	僅Java	任意
性能	損耗低	損耗略高
無(wú)中心化	是	否
靜態(tài)入口	無(wú)	有

越來(lái)越多的公司都在生產(chǎn)環(huán)境使用了 sharding-jdbc ，最核心的原因就是：簡(jiǎn)單（原理簡(jiǎn)單，易于實(shí)現(xiàn)，方便運(yùn)維）。

2 基本原理

在后端開(kāi)發(fā)中，JDBC 編程是最基本的操作。不管 ORM 框架是 Mybatis 還是 Hibernate ，亦或是 spring-jpa ，他們的底層實(shí)現(xiàn)是 JDBC 的模型。

sharding-jdbc 的本質(zhì)上就是實(shí)現(xiàn) JDBC 的核心接口。

接口	實(shí)現(xiàn)類(lèi)
DataSource	ShardingDataSource
Connection	ShardingConnection
Statement	ShardingStatement
PreparedStatement	ShardingPreparedStatement
ResultSet	ShardingResultSet

雖然我們理解了 sharding-jdbc 的本質(zhì)，但是真正實(shí)現(xiàn)起來(lái)還有非常多的細(xì)節(jié)，下圖展示了 Prxoy 和 JDBC 兩種模式的核心流程。

1.SQL 解析

分為詞法解析和語(yǔ)法解析。 先通過(guò)詞法解析器將 SQL 拆分為一個(gè)個(gè)不可再分的單詞。再使用語(yǔ)法解析器對(duì) SQL 進(jìn)行理解，并最終提煉出解析上下文。

解析上下文包括表、選擇項(xiàng)、排序項(xiàng)、分組項(xiàng)、聚合函數(shù)、分頁(yè)信息、查詢條件以及可能需要修改的占位符的標(biāo)記。

2.執(zhí)行器優(yōu)化

合并和優(yōu)化分片條件，如 OR 等。

3.SQL 路由

根據(jù)解析上下文匹配用戶配置的分片策略，并生成路由路徑。目前支持分片路由和廣播路由。

4.SQL 改寫(xiě)

將 SQL 改寫(xiě)為在真實(shí)數(shù)據(jù)庫(kù)中可以正確執(zhí)行的語(yǔ)句。SQL 改寫(xiě)分為正確性改寫(xiě)和優(yōu)化改寫(xiě)。

5.SQL 執(zhí)行

通過(guò)多線程執(zhí)行器異步執(zhí)行。

6.結(jié)果歸并

將多個(gè)執(zhí)行結(jié)果集歸并以便于通過(guò)統(tǒng)一的 JDBC 接口輸出。結(jié)果歸并包括流式歸并、內(nèi)存歸并和使用裝飾者模式的追加歸并這幾種方式。

本文的重點(diǎn)在于實(shí)戰(zhàn)層面， sharding-jdbc 的實(shí)現(xiàn)原理細(xì)節(jié)我們會(huì)在后續(xù)的文章一一給大家呈現(xiàn) 。

3 實(shí)戰(zhàn)案例

筆者曾經(jīng)為武漢一家 O2O 公司訂單服務(wù)做過(guò)分庫(kù)分表架構(gòu)設(shè)計(jì) ，當(dāng)企業(yè)用戶創(chuàng)建一條采購(gòu)訂單 ， 會(huì)生成如下記錄：

訂單基礎(chǔ)表t_ent_order：?jiǎn)螚l記錄 訂單詳情表t_ent_order_detail：?jiǎn)螚l記錄訂單明細(xì)表t_ent_order_item：N條記錄

訂單數(shù)據(jù)采用了如下的分庫(kù)分表策略：

訂單基礎(chǔ)表按照 ent_id (企業(yè)用戶編號(hào)) 分庫(kù) ，訂單詳情表保持一致；訂單明細(xì)表按照 ent_id (企業(yè)用戶編號(hào)) 分庫(kù)，同時(shí)也要按照 ent_id (企業(yè)編號(hào)) 分表。

首先創(chuàng)建 4 個(gè)庫(kù)，分別是：ds_0、ds_1、ds_2、ds_3 。

這四個(gè)分庫(kù)，每個(gè)分庫(kù)都包含 訂單基礎(chǔ)表 ， 訂單詳情表 ，訂單明細(xì)表 。但是因?yàn)槊骷?xì)表需要分表，所以包含多張表。

然后 springboot 項(xiàng)目中配置依賴(lài) ：

    org.apache.shardingsphere    sharding-jdbc-spring-boot-starter    4.1.1

復(fù)制

配置文件中配置如下：

配置數(shù)據(jù)源，上面配置數(shù)據(jù)源是： ds0、ds1、ds2、ds3 ；配置打印日志，也就是：sql.show ，在測(cè)試環(huán)境建議打開(kāi) ，便于調(diào)試；配置哪些表需要分庫(kù)分表 ，在 shardingsphere.datasource.sharding.tables 節(jié)點(diǎn)下面配置：

上圖中我們看到配置分片規(guī)則包含如下兩點(diǎn)：

1.真實(shí)節(jié)點(diǎn)

對(duì)于我們的應(yīng)用來(lái)講，我們查詢的**邏輯表**是：t_ent_order_item 。

復(fù)制

它們?cè)跀?shù)據(jù)庫(kù)中的真實(shí)形態(tài)是：`t_ent_order_item_0` 到  `t_ent_order_item_7`。 

復(fù)制

真實(shí)數(shù)據(jù)節(jié)點(diǎn)是指數(shù)據(jù)分片的最小單元，由數(shù)據(jù)源名稱(chēng)和數(shù)據(jù)表組成。

復(fù)制

訂單明細(xì)表的真實(shí)節(jié)點(diǎn)是：`ds$->{0..3}.t_ent_order_item_$->{0..7}` 。

復(fù)制

2.分庫(kù)分表算法

配置分庫(kù)策略和分表策略 , 每種策略都需要配置分片字段（ sharding-columns ）和分片算法。

4 基因法 & 自定義復(fù)合分片算法

分片算法和阿里開(kāi)源的數(shù)據(jù)庫(kù)中間件 cobar 路由算法非常類(lèi)似的。

假設(shè)現(xiàn)在需要將訂單表平均拆分到4個(gè)分庫(kù) shard0 ，shard1 ，shard2 ，shard3 。

首先將 0-1023 平均分為4個(gè)區(qū)段：0-255，256-511，512-767，768-1023，然后對(duì)字符串（或子串，由用戶自定義）做 hash， hash 結(jié)果對(duì) 1024 取模，最終得出的結(jié)果 slot落入哪個(gè)區(qū)段，便路由到哪個(gè)分庫(kù)。

看起來(lái)分片算法很簡(jiǎn)單，但我們需要按照訂單 ID 查詢訂單信息時(shí)依然需要路由四個(gè)分片，效率不高，那么如何優(yōu)化呢 ？

答案是：基因法& 自定義復(fù)合分片算法。

基因法是指在訂單 ID 中攜帶企業(yè)用戶編號(hào)信息，我們可以在創(chuàng)建訂單 order_id時(shí)使用雪花算法，然后將 slot的值保存在 10位工作機(jī)器 ID里。

通過(guò)訂單 order_id 可以反查出 slot, 就可以定位該用戶的訂單數(shù)據(jù)存儲(chǔ)在哪個(gè)分片里。

Integer getWorkerId(Long orderId) { Long workerId = (orderId >> 12) & 0x03ff; return workerId.intValue();}

復(fù)制

下圖展示了訂單 ID 使用雪花算法的生成過(guò)程，生成的編號(hào)會(huì)攜帶企業(yè)用戶 ID 信息。

解決了分布式 ID 問(wèn)題，接下來(lái)的一個(gè)問(wèn)題：sharding-jdbc 可否支持按照訂單 ID ，企業(yè)用戶 ID 兩個(gè)字段來(lái)決定分片路由嗎？

答案是：自定義復(fù)合分片算法。我們只需要實(shí)現(xiàn) ComplexKeysShardingAlgorithm類(lèi)即可。

復(fù)合分片的算法流程非常簡(jiǎn)單：

1.分片鍵中有主鍵值，則直接通過(guò)主鍵解析出路由分片；

2.分片鍵中不存在主鍵值 ，則按照其他分片字段值解析出路由分片。

5 擴(kuò)容方案

既然做了分庫(kù)分表，如何實(shí)現(xiàn)平滑擴(kuò)容也是一個(gè)非常有趣的話題。

在數(shù)據(jù)同步之前，需要梳理遷移范圍。

1.業(yè)務(wù)唯一主鍵；

在進(jìn)行數(shù)據(jù)同步前，需要先梳理所有表的唯一業(yè)務(wù) ID，只有確定了唯一業(yè)務(wù) ID 才能實(shí)現(xiàn)數(shù)據(jù)的同步操作。

復(fù)制

需要注意的是：業(yè)務(wù)中是否有使用數(shù)據(jù)庫(kù)自增 ID 做為業(yè)務(wù) ID 使用的，如果有需要業(yè)務(wù)先進(jìn)行改造 。另外確保每個(gè)表是否都有唯一索引，一旦表中沒(méi)有唯一索引，就會(huì)在數(shù)據(jù)同步過(guò)程中造成數(shù)據(jù)重復(fù)的風(fēng)險(xiǎn)，所以我們先將沒(méi)有唯一索引的表根據(jù)業(yè)務(wù)場(chǎng)景增加唯一索引（有可能是聯(lián)合唯一索引）。

復(fù)制

2.遷移哪些表，遷移后的分庫(kù)分表規(guī)則；

分表規(guī)則不同決定著 rehash 和數(shù)據(jù)校驗(yàn)的不同。需逐個(gè)表梳理是用戶ID緯度分表還是非用戶ID緯度分表、是否只分庫(kù)不分表、是否不分庫(kù)不分表等等。

復(fù)制

接下來(lái)，進(jìn)入數(shù)據(jù)同步環(huán)節(jié)。

整體方案見(jiàn)下圖，數(shù)據(jù)同步基于 binlog ，獨(dú)立的中間服務(wù)做同步，對(duì)業(yè)務(wù)代碼無(wú)侵入。

首先需要做歷史數(shù)據(jù)全量同步：也就是將舊庫(kù)遷移到新庫(kù)。

單獨(dú)一個(gè)服務(wù)，使用游標(biāo)的方式從舊庫(kù)分片 select 語(yǔ)句，經(jīng)過(guò) rehash 后批量插入 （batch insert）到新庫(kù)，需要配置jdbc 連接串參數(shù) rewriteBatchedStatements=true 才能使批處理操作生效。

因?yàn)闅v史數(shù)據(jù)也會(huì)存在不斷的更新，如果先開(kāi)啟歷史數(shù)據(jù)全量同步，則剛同步完成的數(shù)據(jù)有可能不是最新的。

所以我們會(huì)先開(kāi)啟增量數(shù)據(jù)單向同步（從舊庫(kù)到新庫(kù)），此時(shí)只是開(kāi)啟積壓 kafka 消息并不會(huì)真正消費(fèi)；然后在開(kāi)始?xì)v史數(shù)據(jù)全量同步，當(dāng)歷史全量數(shù)據(jù)同步完成后，在開(kāi)啟消費(fèi) kafka 消息進(jìn)行增量數(shù)據(jù)同步（提高全量同步效率減少積壓也是關(guān)鍵的一環(huán)），這樣來(lái)保證遷移數(shù)據(jù)過(guò)程中的數(shù)據(jù)一致。

增量數(shù)據(jù)同步考慮到灰度切流穩(wěn)定性、容災(zāi) 和可回滾能力 ，采用實(shí)時(shí)雙向同步方案，切流過(guò)程中一旦新庫(kù)出現(xiàn)穩(wěn)定性問(wèn)題或者新庫(kù)出現(xiàn)數(shù)據(jù)一致問(wèn)題，可快速回滾切回舊庫(kù)，保證數(shù)據(jù)庫(kù)的穩(wěn)定和數(shù)據(jù)可靠。

增量數(shù)據(jù)實(shí)時(shí)同步的大體思路 ：

1.過(guò)濾循環(huán)消息

需要過(guò)濾掉循環(huán)同步的 binlog 消息 ;

2.數(shù)據(jù)合并

同一條記錄的多條操作只保留最后一條。為了提高性能，數(shù)據(jù)同步組件接到 kafka 消息后不會(huì)立刻進(jìn)行數(shù)據(jù)流轉(zhuǎn)，而是先存到本地阻塞隊(duì)列，然后由本地定時(shí)任務(wù)每X秒將本地隊(duì)列中的N條數(shù)據(jù)進(jìn)行數(shù)據(jù)流轉(zhuǎn)操作。此時(shí)N條數(shù)據(jù)有可能是對(duì)同一張表同一條記錄的操作，所以此處只需要保留最后一條（類(lèi)似于 redis aof 重寫(xiě)）;

3.update 轉(zhuǎn) insert

數(shù)據(jù)合并時(shí)，如果數(shù)據(jù)中有 insert + update 只保留最后一條 update ，會(huì)執(zhí)行失敗，所以此處需要將 update 轉(zhuǎn)為 insert 語(yǔ)句 ;

復(fù)制

4.按新表合并

將最終要提交的 N 條數(shù)據(jù)，按照新表進(jìn)行拆分合并，這樣可以直接按照新表緯度進(jìn)行數(shù)據(jù)庫(kù)批量操作，提高插入效率。

復(fù)制

擴(kuò)容方案文字來(lái)自 《256變4096：分庫(kù)分表擴(kuò)容如何實(shí)現(xiàn)平滑數(shù)據(jù)遷移》，筆者做了些許調(diào)整。

6 總結(jié)

sharding-jdbc 的本質(zhì)是實(shí)現(xiàn) JDBC 的核心接口，架構(gòu)相對(duì)簡(jiǎn)單。

實(shí)戰(zhàn)過(guò)程中，需要配置數(shù)據(jù)源信息，邏輯表對(duì)應(yīng)的真實(shí)節(jié)點(diǎn)和分庫(kù)分表策略（分片字段和分片算法）

實(shí)現(xiàn)分布式主鍵直接路由到對(duì)應(yīng)分片，則需要使用基因法 & 自定義復(fù)合分片算法。

平滑擴(kuò)容的核心是全量同步和實(shí)時(shí)雙向同步，工程上有不少細(xì)節(jié)。

實(shí)戰(zhàn)代碼地址：

https://github.com/makemyownlife/shardingsphere-jdbc-demo

參考資料：

256變4096：分庫(kù)分表擴(kuò)容如何實(shí)現(xiàn)平滑數(shù)據(jù)遷移？黃東旭：分布式數(shù)據(jù)庫(kù)歷史、發(fā)展趨勢(shì)與 TiDB 架構(gòu)

如果我的文章對(duì)你有所幫助，還請(qǐng)幫忙點(diǎn)贊、在看、轉(zhuǎn)發(fā)一下，你的支持會(huì)激勵(lì)我輸出更高質(zhì)量的文章，非常感謝！

關(guān)鍵詞： 數(shù)據(jù)遷移 編程算法 數(shù)據(jù)遷移解決方案 JDBC