摘要：Apache ShardingSphere 是一款分布式的資料庫生態系統，它包含兩大產品：ShardingSphere-Proxy和ShardingSphere-JDBC，
本文分享自華為云社區《看完這一篇，ShardingSphere-jdbc 實戰再也不怕了》，作者：勇哥java實戰分享 ，
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 兩種模式選擇時，可以參考下表對照：
越來越多的公司都在生產環境使用了 sharding-jdbc ，最核心的原因就是：簡單（原理簡單，易于實作，方便運維），
2 基本原理
在后端開發中，JDBC 編程是最基本的操作，不管 ORM 框架是 Mybatis 還是 Hibernate ，亦或是 spring-jpa ，他們的底層實作是 JDBC 的模型，
sharding-jdbc 的本質上就是實作 JDBC 的核心介面，
雖然我們理解了 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 架構
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/545543.html
標籤：其他