資料量大了一定要分表，分庫分表Sharding-JDBC入門與專案實戰
最近專案中不少表的資料量越來越大，並且導致了一些資料庫的效能問題。因此想借助一些分庫分表的中介軟體，實現自動化分庫分表實現。調研下來，發現Sharding-JDBC目前成熟度最高並且應用最廣的Java分庫分表的客戶端元件。
本文主要介紹一些Sharding-JDBC核心概念以及生產環境下的實戰指南，旨在幫助組內成員快速瞭解Sharding-JDBC並且能夠快速將其使用起來。
核心概念
在使用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種分片演算法。由於分片演算法和業務實現緊密相關，因此並未提供內建分片演算法，而是透過分片策略將各種場景提煉出來，提供更高層級的抽象，並提供介面讓應用開發者自行實現分片演算法。
精確分片演算法
對應 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還必須趨勢遞增，避免造成頻繁的資料頁面分裂。
讀寫分離
提供一主多從的讀寫分離配置，可獨立使用，也可配合分庫分表使用。
同一執行緒且同一資料庫連線內，如有寫入操作，以後的讀操作均從主庫讀取，用於保證資料一致性
基於Hint的強制主庫路由。
主從模型中，事務中讀寫均用主庫。
執行流程
Sharding-JDBC 的原理總結起來很簡單： 核心由 SQL解析 => 執行器最佳化 => SQL路由 => SQL改寫 => SQL執行 => 結果歸併的流程組成。
專案實戰
spring-boot專案實戰
引入依賴
資料來源配置
如果使用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
Map
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（）；
}
}
分散式id生成器配置
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
分片演算法實現
精確分片演算法：QuestionRecordPreciseShardingAlgorithm
public class QuestionRecordPreciseShardingAlgorithm implements PreciseShardingAlgorithm
/**
* 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
return ShardingUtils。quarterPreciseSharding（availableTargetNames， shardingValue）；
}
}
範圍分片演算法：QuestionRecordRangeShardingAlgorithm
public class QuestionRecordRangeShardingAlgorithm implements RangeShardingAlgorithm
/**
* 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
return ShardingUtils。quarterRangeSharding（availableTargetNames， shardingValue）；
}
}
具體分片實現邏輯：ShardingUtils
@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
// 這裡就是根據範圍查詢條件，篩選出匹配的真實表集合
}
/**
* logicTableName_{year}_q{quarter}
* 按季度精確分片
* @param availableTargetNames 可用的真實表集合
* @param shardingValue 分片值
* @return
*/
public static String quarterPreciseSharding（Collection
// 這裡就是根據等值查詢條件，計算出匹配的真實表
}
}
到這裡，針對hc_question_reply_record表，使用reply_wheel_time作為分片鍵，按照季度分片的處理就完成了。還有一點要注意的就是，分庫分表之後，查詢的時候最好都帶上分片鍵作為查詢條件，否則就會使用全庫路由，效能很低。
還有就是Sharing-JDBC對mysql的全文索引支援的不是很好，專案有使用到的地方也要注意一下。總結來說整個過程還是比較簡單的，後續碰到其它業務場景，相信大家按照這個思路肯定都能解決的。
原文：
https：//
juejin。im/post/68449041
82365814797
