Sharding-JDBC，這麼主流的分庫分表框架，你還不懂？來了解一下，然後入門吧！
作者：六點半起床
https://juejin.im/post/5edc9f3ff265da76bc760726
最近項目中不少表的數據量越來越大，並且導致了一些資料庫的性能問題。因此想藉助一些分庫分表的中間件，實現自動化分庫分表實現。調研下來，發現Sharding-JDBC目前成熟度最高並且應用最廣的Java分庫分表的客戶端組件。本文主要介紹一些 Sharding-JDBC 核心概念以及生產環境下的實戰指南，旨在幫助組內成員快速了解 Sharding-JDBC 並且能夠快速將其使用起來。Sharding-JDBC 官方文檔：https://shardingsphere.apache.org/document/current/cn/overview/
核心概念在使用Sharding-JDBC之前，一定是先理解清楚下面幾個核心概念。
邏輯表水平拆分的資料庫（表）的相同邏輯和數據結構表的總稱。例：訂單數據根據主鍵尾數拆分為 10 張表，分別是t_order_0到t_order_9，他們的邏輯表名為t_order。
真實表在分片的資料庫中真實存在的物理表。即上個示例中的t_order_0到t_order_9。
數據節點數據分片的最小單元。由數據源名稱和數據表組成，例：ds_0.t_order_0。
綁定表指分片規則一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，則此兩張表互為綁定表關係。綁定表之間的多表關聯查詢不會出現笛卡爾積關聯，關聯查詢效率將大大提升。舉例說明, 如果 SQL 為：
SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
假設t_order和t_order_item對應的真實表各有 2 個，那麼真實表就有t_order_0、t_order_1、t_order_item_0、t_order_item_1。在不配置綁定表關係時，假設分片鍵order_id將數值 10 路由至第 0 片，將數值 11 路由至第 1 片，那麼路由後的 SQL 應該為 4 條，它們呈現為笛卡爾積：
SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
在配置綁定表關係後，路由的 SQL 應該為 2 條：
SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
指所有的分片數據源中都存在的表，表結構和表中的數據在每個資料庫中均完全一致。適用於數據量不大且需要與海量數據的表進行關聯查詢的場景，例如：字典表。
數據分片分片鍵用於分片的資料庫欄位，是將資料庫 (表) 水平拆分的關鍵欄位。例：將訂單表中的訂單主鍵的尾數取模分片，則訂單主鍵為分片欄位。SQL 中如果無分片欄位，將執行全路由，性能較差。除了對單分片欄位的支持，Sharding-JDBC 也支持根據多個欄位進行分片。
分片算法通過分片算法將數據分片，支持通過=、>=、<=、>、<、BETWEEN和IN分片。分片算法需要應用方開發者自行實現，可實現的靈活度非常高。
目前提供 4 種分片算法。由於分片算法和業務實現緊密相關，因此並未提供內置分片算法，而是通過分片策略將各種場景提煉出來，提供更高層級的抽象，並提供接口讓應用開發者自行實現分片算法。
搜索公縱號：MarkerHub，關注回復[ vue ]獲取前後端入門教程！
精確分片算法對應 PreciseShardingAlgorithm，用於處理使用單一鍵作為分片鍵的 = 與 IN 進行分片的場景。需要配合 StandardShardingStrategy 使用。
範圍分片算法對應 RangeShardingAlgorithm，用於處理使用單一鍵作為分片鍵的 BETWEEN AND、>、<、>=、<= 進行分片的場景。需要配合 StandardShardingStrategy 使用。
複合分片算法對應 ComplexKeysShardingAlgorithm，用於處理使用多鍵作為分片鍵進行分片的場景，包含多個分片鍵的邏輯較複雜，需要應用開發者自行處理其中的複雜度。需要配合 ComplexShardingStrategy 使用。
Hint 分片算法對應 HintShardingAlgorithm，用於處理通過 Hint 指定分片值而非從 SQL 中提取分片值的場景。需要配合 HintShardingStrategy 使用。
分片策略包含分片鍵和分片算法，由於分片算法的獨立性，將其獨立抽離。真正可用於分片操作的是分片鍵 + 分片算法，也就是分片策略。目前提供 5 種分片策略。
標準分片策略對應 StandardShardingStrategy。提供對 SQ L 語句中的 =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。 StandardShardingStrategy 只支持單分片鍵，提供 PreciseShardingAlgorithm 和 RangeShardingAlgorithm 兩個分片算法。 PreciseShardingAlgorithm 是必選的，用於處理 = 和 IN 的分片。 RangeShardingAlgorithm 是可選的，用於處理 BETWEEN AND, >, <, >=, <=分片，如果不配置 RangeShardingAlgorithm，SQL 中的 BETWEEN AND 將按照全庫路由處理。
複合分片策略對應 ComplexShardingStrategy。複合分片策略。提供對 SQL 語句中的 =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。 ComplexShardingStrategy 支持多分片鍵，由於多分片鍵之間的關係複雜，因此並未進行過多的封裝，而是直接將分片鍵值組合以及分片操作符透傳至分片算法，完全由應用開發者實現，提供最大的靈活度。
行表達式分片策略對應 InlineShardingStrategy。使用 Groovy 的表達式，提供對 SQL 語句中的 = 和 IN的分片操作支持，只支持單分片鍵。對於簡單的分片算法，可以通過簡單的配置使用，從而避免繁瑣的 Java 代碼開發，如: t_user_$->{u_id % 8} 表示 t_user 表根據 u_id 模 8，而分成 8 張表，表名稱為 t_user_0 到 t_user_7。 可以認為是精確分片算法的簡易實現
Hint 分片策略對應 HintShardingStrategy。通過 Hint 指定分片值而非從 SQL 中提取分片值的方式進行分片的策略。
分布式主鍵用於在分布式環境下，生成全局唯一的 id。Sharding-JDBC 提供了內置的分布式主鍵生成器，例如 UUID、SNOWFLAKE。還抽離出分布式主鍵生成器的接口，方便用戶自行實現自定義的自增主鍵生成器。為了保證資料庫性能，主鍵 id 還必須趨勢遞增，避免造成頻繁的數據頁面分裂。
讀寫分離提供一主多從的讀寫分離配置，可獨立使用，也可配合分庫分表使用。
執行流程Sharding-JDBC 的原理總結起來很簡單: 核心由 SQL解析 => 執行器優化 => SQL路由 => SQL改寫 => SQL執行 => 結果歸併的流程組成。
項目實戰spring-boot 項目實戰
引入依賴<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-jdbc-spring-boot-starter</artifactId>
<version>4.0.1</version>
</dependency>
如果使用sharding-jdbc-spring-boot-starter, 並且數據源以及數據分片都使用 shardingsphere 進行配置，對應的數據源會自動創建並注入到 spring 容器中。
spring.shardingsphere.datasource.names=ds0,ds1
spring.shardingsphere.datasource.ds0.type=org.apache.commons.dbcp.BasicDataSource
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds0.url=jdbc:mysql://localhost:3306/ds0
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=
spring.shardingsphere.datasource.ds1.type=org.apache.commons.dbcp.BasicDataSource
spring.shardingsphere.datasource.ds1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds1.url=jdbc:mysql://localhost:3306/ds1
spring.shardingsphere.datasource.ds1.username=root
spring.shardingsphere.datasource.ds1.password=
# 其它分片配置
但是在我們已有的項目中，數據源配置是單獨的。因此要禁用sharding-jdbc-spring-boot-starter裡面的自動裝配，而是參考源碼自己重寫數據源配置。需要在啟動類上加上@SpringBootApplication(exclude = {org.apache.shardingsphere.shardingjdbc.spring.boot.SpringBootConfiguration.class})來排除。然後自定義配置類來裝配DataSource。
@Configuration
@Slf4j
@EnableConfigurationProperties({
SpringBootShardingRuleConfigurationProperties.class,
SpringBootMasterSlaveRuleConfigurationProperties.class, SpringBootEncryptRuleConfigurationProperties.class, SpringBootPropertiesConfigurationProperties.class})
@AutoConfigureBefore(DataSourceConfiguration.class)
public class DataSourceConfig implements ApplicationContextAware {
@Autowired
private SpringBootShardingRuleConfigurationProperties shardingRule;
@Autowired
private SpringBootPropertiesConfigurationProperties props;
private ApplicationContext applicationContext;
@Bean("shardingDataSource")
@Conditional(ShardingRuleCondition.class)
public DataSource shardingDataSource() throws SQLException {
// 獲取其它方式配置的數據源
Map<String, DruidDataSourceWrapper> beans = applicationContext.getBeansOfType(DruidDataSourceWrapper.class);
Map<String, DataSource> dataSourceMap = new HashMap<>(4);
beans.forEach(dataSourceMap::put);
// 創建shardingDataSource
return ShardingDataSourceFactory.createDataSource(dataSourceMap, new ShardingRuleConfigurationYamlSwapper().swap(shardingRule), props.getProps());
}
@Bean
public SqlSessionFactory sqlSessionFactory() throws SQLException {
SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
// 將shardingDataSource設置到SqlSessionFactory中
sqlSessionFactoryBean.setDataSource(shardingDataSource());
// 其它設置
return sqlSessionFactoryBean.getObject();
}
}
Sharding-JDBC 提供了UUID、SNOWFLAKE生成器，還支持用戶實現自定義 id 生成器。比如可以實現了 type 為SEQ的分布式 id 生成器，調用統一的分布式id服務獲取 id。
@Data
public class SeqShardingKeyGenerator implements ShardingKeyGenerator {
private Properties properties = new Properties();
@Override
public String getType() {
return "SEQ";
}
@Override
public synchronized Comparable<?> generateKey() {
// 獲取分布式id邏輯
}
}
由於擴展ShardingKeyGenerator是通過 JDK 的serviceloader的 SPI 機制實現的，因此還需要在resources/META-INF/services目錄下配置org.apache.shardingsphere.spi.keygen.ShardingKeyGenerator文件。 文件內容就是SeqShardingKeyGenerator類的全路徑名。這樣使用的時候，指定分布式主鍵生成器的 type 為SEQ就好了。
至此，Sharding-JDBC 就整合進 spring-boot 項目中了，後面就可以進行數據分片相關的配置了。
數據分片實戰如果項目初期就能預估出表的數據量級，當然可以一開始就按照這個預估值進行分庫分表處理。但是大多數情況下，我們一開始並不能準備預估出數量級。這時候通常的做法是：
線上數據某張表查詢性能開始下降，排查下來是因為數據量過大導致的。
根據歷史數據量預估出未來的數據量級，並結合具體業務場景確定分庫分表策略。
自動分庫分表代碼實現。
下面就以一個具體事例，闡述具體數據分片實戰。比如有張表數據結構如下：
CREATE TABLE `hc_question_reply_record` (
`id` bigint NOT NULL AUTO_INCREMENT COMMENT '自增ID',
`reply_text` varchar(500) NOT NULL DEFAULT '' COMMENT '回復內容',
`reply_wheel_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '回復時間',
`ctime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創建時間',
`mtime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新時間',
PRIMARY KEY (`id`),
INDEX `idx_reply_wheel_time` (`reply_wheel_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
COMMENT='回復明細記錄';
先查詢目前目標表月新增趨勢：
SELECT count(*), date_format(ctime, '%Y-%m') AS `日期`
FROM hc_question_reply_record
GROUP BY date_format(ctime, '%Y-%m');
目前月新增在 180w 左右，預估未來達到 300w(基本以 2 倍計算) 以上。期望單表數據量不超過 1000w，可使用
reply_wheel_time
作為分片鍵按季度歸檔。
分片配置spring:
# sharing-jdbc配置
shardingsphere:
# 數據源名稱
datasource:
names: defaultDataSource,slaveDataSource
sharding:
# 主從節點配置
master-slave-rules:
defaultDataSource:
# maser數據源
master-data-source-name: defaultDataSource
# slave數據源
slave-data-source-names: slaveDataSource
tables:
# hc_question_reply_record 分庫分表配置
hc_question_reply_record:
# 真實數據節點 hc_question_reply_record_2020_q1
actual-data-nodes: defaultDataSource.hc_question_reply_record_$->{2020..2025}_q$->{1..4}
# 表分片策略
table-strategy:
standard:
# 分片鍵
sharding-column: reply_wheel_time
# 精確分片算法 全路徑名
preciseAlgorithmClassName: com.xx.QuestionRecordPreciseShardingAlgorithm
# 範圍分片算法，用於BETWEEN，可選。。該類需實現RangeShardingAlgorithm接口並提供無參數的構造器
rangeAlgorithmClassName: com.xx.QuestionRecordRangeShardingAlgorithm
# 默認分布式id生成器
default-key-generator:
type: SEQ
column: id
public class QuestionRecordPreciseShardingAlgorithm implements PreciseShardingAlgorithm<Date> {
/**
* Sharding.
*
* @param availableTargetNames available data sources or tables's names
* @param shardingValue sharding value
* @return sharding result for data source or table's name
*/
@Override
public String doSharding(Collection<String> availableTargetNames, PreciseShardingValue<Date> shardingValue) {
return ShardingUtils.quarterPreciseSharding(availableTargetNames, shardingValue);
}
}
public class QuestionRecordRangeShardingAlgorithm implements RangeShardingAlgorithm<Date> {
/**
* Sharding.
*
* @param availableTargetNames available data sources or tables's names
* @param shardingValue sharding value
* @return sharding results for data sources or tables's names
*/
@Override
public Collection<String> doSharding(Collection<String> availableTargetNames, RangeShardingValue<Date> shardingValue) {
return ShardingUtils.quarterRangeSharding(availableTargetNames, shardingValue);
}
}
@UtilityClass
public class ShardingUtils {
public static final String QUARTER_SHARDING_PATTERN = "%s_%d_q%d";
/**
* logicTableName_{year}_q{quarter}
* 按季度範圍分片
* @param availableTargetNames 可用的真實表集合
* @param shardingValue 分片值
* @return
*/
public Collection<String> quarterRangeSharding(Collection<String> availableTargetNames, RangeShardingValue<Date> shardingValue) {
Range<Date> valueRange = shardingValue.getValueRange();
Date lower = valueRange.lowerEndpoint();
Date upper = valueRange.upperEndpoint();
LocalDate lowerLocalDate =
lower.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
LocalDate upperLocalDate =
upper.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
int lowerYear = lowerLocalDate.getYear();
int lowerMonth = lowerLocalDate.getMonthValue();
int lowerQuarter = getQuarter(lowerMonth);
int upperYear = upperLocalDate.getYear();
int upperMonth = upperLocalDate.getMonthValue();
int upperQuarter = getQuarter(upperMonth);
String logicTableName = shardingValue.getLogicTableName();
List<String> actualTableNames = new ArrayList<>();
if (lowerYear == upperYear) {
// 不跨年
for (int quarter = lowerQuarter; quarter <= upperQuarter; quarter++) {
String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, lowerYear, quarter);
actualTableNames.add(actualTableName);
}
} else {
// 跨年
for (int quarter = lowerQuarter; quarter <= Constant.INT_4; quarter++) {
String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, lowerYear, quarter);
actualTableNames.add(actualTableName);
}
for (int year = lowerYear + 1; year < upperYear; year++) {
for (int quarter = 1; quarter <= Constant.INT_4; quarter++) {
String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, year, quarter);
actualTableNames.add(actualTableName);
}
}
for (int quarter = 1; quarter <= upperQuarter; quarter++) {
String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, upperYear, quarter);
actualTableNames.add(actualTableName);
}
}
if (!availableTargetNames.containsAll(actualTableNames)) {
throw new IllegalArgumentException("分片異常！shardingValue=" + shardingValue + "; availableTargetNames=" + availableTargetNames);
}
return actualTableNames;
}
/**
* logicTableName_{year}_q{quarter}
* 按季度精確分片
* @param availableTargetNames 可用的真實表集合
* @param shardingValue 分片值
* @return
*/
public static String quarterPreciseSharding(Collection<String> availableTargetNames, PreciseShardingValue<Date> shardingValue) {
String logicTableName = shardingValue.getLogicTableName();
Date value = shardingValue.getValue();
LocalDate localDate =
value.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();
int year = localDate.getYear();
int month = localDate.getMonthValue();
int quarter = getQuarter(month);
String actualTableName = String.format(QUARTER_SHARDING_PATTERN, logicTableName, year, quarter);
if (availableTargetNames.contains(actualTableName)) {
return actualTableName;
}
throw new IllegalArgumentException("分片異常！shardingValue=" + shardingValue + "; availableTargetNames=" + availableTargetNames);
}
private static int getQuarter(int month) {
if (month >= Constant.INT_1 && month <= Constant.INT_3) {
return Constant.INT_1;
} else if (month >= Constant.INT_4 && month <= Constant.INT_6) {
return Constant.INT_2;
} else if (month >= Constant.INT_7 && month <= Constant.INT_9) {
return Constant.INT_3;
} else if (month >= Constant.INT_10 && month <= Constant.INT_12) {
return Constant.INT_4;
} else {
throw new IllegalArgumentException("month非法！month=" + month);
}
}
}
到這裡，針對hc_question_reply_record表，使用reply_wheel_time作為分片鍵，按照季度分片的處理就完成了。還有一點要注意的就是，分庫分表之後，查詢的時候最好都帶上分片鍵作為查詢條件，否則就會使用全庫路由，性能很低。還有就是 Sharing-JDBC 對 mysql 的全文索引支持的不是很好，項目有使用到的地方也要注意一下。總結來說整個過程還是比較簡單的，後續碰到其它業務場景，相信大家按照這個思路肯定都能解決的。
（完）
MarkerHub文章索引：（點擊閱讀原文直達）
https://github.com/MarkerHub/JavaIndex
【推薦閱讀】
有啥不同？來看看Spring Boot 基於 JUnit 5 實現單元測試
記一次Spring boot 和Vue前後端分離的入門培訓
實踐：SpringBoot實現定時任務的動態增刪啟停
微服務統一登陸認證怎麼做？JWT ？
Spring容器IOC初始化過程--今天終於進行總結了
好用到爆的 Java 技巧