談到分庫分表中介軟體時，我們自然而然的會想到 ShardingSphere-JDBC 。

這篇文章，我們聊聊 ShardingSphere-JDBC 相關知識點，並實戰演示一番。

1 ShardingSphere 生態

Apache ShardingSphere 是一款分散式的資料庫生態系統，它包含兩大產品：

ShardingSphere-Proxy
ShardingSphere-JDBC

▍一、ShardingSphere-Proxy

ShardingSphere-Proxy 被定位為透明化的資料庫代理端，提供封裝了資料庫二進位制協定的伺服器端版本，用於完成對異構語言的支援。

代理層介於應用程式與資料庫間，每次請求都需要做一次轉發，請求會存在額外的時延。

這種方式對於應用非常友好，應用基本零改動，和語言無關，可以通過連線共用減少連線數消耗。

▍二、ShardingSphere-JDBC

ShardingSphere-JDBC 是 ShardingSphere 的第一個產品，也是 ShardingSphere 的前身，我們經常簡稱之為：sharding-jdbc 。

它定位為輕量級 Java 框架，在 Java 的 JDBC 層提供的額外服務。它使用使用者端直連資料庫，以 jar 包形式提供服務，無需額外部署和依賴，可理解為增強版的 JDBC 驅動，完全相容 JDBC 和各種 ORM 框架。

當我們在 Proxy 和 JDBC 兩種模式選擇時，可以參考下表對照：

	JDBC	Proxy
資料庫	`任意`	MySQL/PostgreSQL
連線消耗數	`高`	低
異構語言	`僅Java`	任意
效能	`損耗低`	損耗略高
無中心化	`是`	否
靜態入口	`無`	有

越來越多的公司都在生產環境使用了 sharding-jdbc ，最核心的原因就是：簡單（原理簡單，易於實現，方便運維）。

2 基本原理

在後端開發中，JDBC 程式設計是最基本的操作。不管 ORM 框架是 Mybatis 還是 Hibernate ，亦或是 spring-jpa ，他們的底層實現是 JDBC 的模型。

sharding-jdbc 的本質上就是實現 JDBC 的核心介面。

介面	實現類
DataSource	ShardingDataSource
Connection	ShardingConnection
Statement	ShardingStatement
PreparedStatement	ShardingPreparedStatement
ResultSet	ShardingResultSet

雖然我們理解了 sharding-jdbc 的本質，但是真正實現起來還有非常多的細節，下圖展示了 Prxoy 和 JDBC 兩種模式的核心流程。

1.SQL 解析

分為詞法解析和語法解析。先通過詞法解析器將 SQL 拆分為一個個不可再分的單詞。再使用語法解析器對 SQL 進行理解，並最終提煉出解析上下文。

解析上下文包括表、選擇項、排序項、分組項、聚合函數、分頁資訊、查詢條件以及可能需要修改的預留位置的標記。

2.執行器優化

合併和優化分片條件，如 OR 等。

3.SQL 路由

根據解析上下文匹配使用者設定的分片策略，並生成路由路徑。目前支援分片路由和廣播路由。

4.SQL 改寫

將 SQL 改寫為在真實資料庫中可以正確執行的語句。SQL 改寫分為正確性改寫和優化改寫。

5.SQL 執行

通過多執行緒執行器非同步執行。

6.結果歸併

將多個執行結果集歸併以便於通過統一的 JDBC 介面輸出。結果歸併包括流式歸併、記憶體歸併和使用裝飾者模式的追加歸併這幾種方式。

本文的重點在於實戰層面， sharding-jdbc 的實現原理細節我們會在後續的文章一一給大家呈現。

3 實戰案例

筆者曾經為武漢一家 O2O 公司訂單服務做過分庫分表架構設計，當企業使用者建立一條採購訂單，會生成如下記錄：

訂單基礎表t_ent_order ：單條記錄
訂單詳情表t_ent_order_detail ：單條記錄
訂單明細表t_ent_order_item：N 條記錄

訂單資料採用瞭如下的分庫分表策略：

訂單基礎表按照 ent_id (企業使用者編號) 分庫，訂單詳情表保持一致；
訂單明細表按照 ent_id (企業使用者編號) 分庫，同時也要按照 ent_id (企業編號) 分表。

首先建立 4 個庫，分別是：ds_0、ds_1、ds_2、ds_3 。

這四個分庫，每個分庫都包含訂單基礎表，訂單詳情表，訂單明細表。但是因為明細表需要分表，所以包含多張表。

然後 springboot 專案中設定依賴：

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
    <version>4.1.1</version>
</dependency>

組態檔中設定如下：

設定資料來源，上面設定資料來源是： ds0、ds1、ds2、ds3 ；
設定列印紀錄檔，也就是：sql.show ，在測試環境建議開啟，便於偵錯；
設定哪些表需要分庫分表，在 shardingsphere.datasource.sharding.tables 節點下面設定：

上圖中我們看到設定分片規則包含如下兩點：

1.真實節點

對於我們的應用來講，我們查詢的邏輯表是：t_ent_order_item 。

它們在資料庫中的真實形態是：t_ent_order_item_0 到 t_ent_order_item_7。

真實資料節點是指資料分片的最小單元，由資料來源名稱和資料表組成。

訂單明細表的真實節點是：ds$->{0..3}.t_ent_order_item_$->{0..7} 。

2.分庫分表演演算法

設定分庫策略和分表策略 , 每種策略都需要設定分片欄位（ sharding-columns ）和分片演演算法。

4 基因法 & 自定義複合分片演演算法

分片演演算法和阿里開源的資料庫中介軟體 cobar 路由演演算法非常類似的。

假設現在需要將訂單表平均拆分到4個分庫 shard0 ，shard1 ，shard2 ，shard3 。

首先將 [0-1023] 平均分為4個區段：[0-255]，[256-511]，[512-767]，[768-1023]，然後對字串（或子串，由使用者自定義）做 hash， hash 結果對 1024 取模，最終得出的結果 slot 落入哪個區段，便路由到哪個分庫。

看起來分片演演算法很簡單，但我們需要按照訂單 ID 查詢訂單資訊時依然需要路由四個分片，效率不高，那麼如何優化呢？

答案是：基因法 & 自定義複合分片演演算法。

基因法是指在訂單 ID 中攜帶企業使用者編號資訊，我們可以在建立訂單 order_id 時使用雪花演演算法，然後將 slot 的值儲存在 10位工作機器 ID 裡。

通過訂單 order_id 可以反查出 slot , 就可以定位該使用者的訂單資料儲存在哪個分片裡。

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

下圖展示了訂單 ID 使用雪花演演算法的生成過程，生成的編號會攜帶企業使用者 ID 資訊。

解決了分散式 ID 問題，接下來的一個問題：sharding-jdbc 可否支援按照訂單 ID ，企業使用者 ID 兩個欄位來決定分片路由嗎？

答案是：自定義複合分片演演算法。我們只需要實現 ComplexKeysShardingAlgorithm 類即可。

複合分片的演演算法流程非常簡單：

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

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

5 擴容方案

既然做了分庫分表，如何實現平滑擴容也是一個非常有趣的話題。

在資料同步之前，需要梳理遷移範圍。

1.業務唯一主鍵；

在進行資料同步前，需要先梳理所有表的唯一業務 ID，只有確定了唯一業務 ID 才能實現資料的同步操作。

需要注意的是：業務中是否有使用資料庫自增 ID 做為業務 ID 使用的，如果有需要業務先進行改造。另外確保每個表是否都有唯一索引，一旦表中沒有唯一索引，就會在資料同步過程中造成資料重複的風險，所以我們先將沒有唯一索引的表根據業務場景增加唯一索引（有可能是聯合唯一索引）。

2.遷移哪些表，遷移後的分庫分表規則；

分表規則不同決定著 rehash 和資料校驗的不同。需逐個表梳理是使用者ID緯度分表還是非使用者ID緯度分表、是否只分庫不分表、是否不分庫不分表等等。

接下來，進入資料同步環節。

整體方案見下圖，資料同步基於 binlog ，獨立的中間服務做同步，對業務程式碼無侵入。

首先需要做歷史資料全量同步：也就是將舊庫遷移到新庫。

單獨一個服務，使用遊標的方式從舊庫分片 select 語句，經過 rehash 後批次插入（batch insert）到新庫，需要設定jdbc 連線串引數 rewriteBatchedStatements=true 才能使批次處理操作生效。

因為歷史資料也會存在不斷的更新，如果先開啟歷史資料全量同步，則剛同步完成的資料有可能不是最新的。

所以我們會先開啟增量資料單向同步（從舊庫到新庫），此時只是開啟積壓 kafka 訊息並不會真正消費；然後在開始歷史資料全量同步，當歷史全量資料同步完成後，在開啟消費 kafka 訊息進行增量資料同步（提高全量同步效率減少積壓也是關鍵的一環），這樣來保證遷移資料過程中的資料一致。

增量資料同步考慮到灰度切流穩定性、容災和可回滾能力，採用實時雙向同步方案，切流過程中一旦新庫出現穩定性問題或者新庫出現資料一致問題，可快速回滾切回舊庫，保證資料庫的穩定和資料可靠。

增量資料實時同步的大體思路：

1.過濾迴圈訊息

需要過濾掉迴圈同步的 binlog 訊息 ;

2.資料合併

同一條記錄的多條操作只保留最後一條。為了提高效能，資料同步元件接到 kafka 訊息後不會立刻進行資料流轉，而是先存到本地阻塞佇列，然後由本地定時任務每X秒將本地佇列中的N條資料進行資料流轉操作。此時N條資料有可能是對同一張表同一條記錄的操作，所以此處只需要保留最後一條（類似於 redis aof 重寫）;

3.update 轉 insert

資料合併時，如果資料中有 insert + update 只保留最後一條 update ，會執行失敗，所以此處需要將 update 轉為 insert 語句 ;

4.按新表合併

將最終要提交的 N 條資料，按照新表進行拆分合並，這樣可以直接按照新表緯度進行資料庫批次操作，提高插入效率。

擴容方案文字來自《256變4096：分庫分表擴容如何實現平滑資料遷移》，筆者做了些許調整。

6 總結

sharding-jdbc 的本質是實現 JDBC 的核心介面，架構相對簡單。

實戰過程中，需要設定資料來源資訊，邏輯表對應的真實節點和分庫分表策略（分片欄位和分片演演算法）

實現分散式主鍵直接路由到對應分片，則需要使用基因法 & 自定義複合分片演演算法 。

平滑擴容的核心是全量同步和實時雙向同步，工程上有不少細節。

實戰程式碼地址：

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

參考資料：

256變4096：分庫分表擴容如何實現平滑資料遷移？
黃東旭：分散式資料庫歷史、發展趨勢與 TiDB 架構