如何使用分庫分表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);

廣播表

指所有的分片數據源中都存在的表，表結構和表中的數據在每個數據庫中均完全一致。適用于數據量不大且需要與海量數據的表進行關聯查詢的場景，例如：字典表。關注公眾號：程序員白楠楠，獲取一份2020面試題pdf

數據分片

分片鍵

用于分片的數據庫字段，是將數據庫(表)水平拆分的關鍵字段。例：將訂單表中的訂單主鍵的尾數取模分片，則訂單主鍵為分片字段。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項目實戰

引入依賴

<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 {@Autowiredprivate SpringBootShardingRuleConfigurationProperties shardingRule;@Autowiredprivate 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);// 創建shardingDataSourcereturn ShardingDataSourceFactory.createDataSource(dataSourceMap, new ShardingRuleConfigurationYamlSwapper().swap(shardingRule), props.getProps());}@Beanpublic 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。

@Datapublic class SeqShardingKeyGenerator implements ShardingKeyGenerator {private Properties properties = new Properties();@Overridepublic String getType() {return "SEQ";}@Overridepublic 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項目中了，后面就可以進行數據分片相關的配置了。

數據分片實戰

如果項目初期就能預估出表的數據量級，當然可以一開始就按照這個預估值進行分庫分表處理。但是大多數情況下，我們一開始并不能準備預估出數量級。這時候通常的做法是：

1. 線上數據某張表查詢性能開始下降，排查下來是因為數據量過大導致的。

2. 根據歷史數據量預估出未來的數據量級，并結合具體業務場景確定分庫分表策略。

3. 自動分庫分表代碼實現。

下面就以一個具體事例，闡述具體數據分片實戰。比如有張表數據結構如下：

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<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);
  }}

• 范圍分片算法：QuestionRecordRangeShardingAlgorithm

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);
  }}

• 具體分片實現邏輯：ShardingUtils

@UtilityClasspublic 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) {// 這里就是根據范圍查詢條件，篩選出匹配的真實表集合}/**
    * logicTableName_{year}_q{quarter}
    * 按季度精確分片
    * @param availableTargetNames 可用的真實表集合
    * @param shardingValue 分片值
    * @return
    */public static String quarterPreciseSharding(Collection<String> availableTargetNames, PreciseShardingValue<Date> shardingValue) {// 這里就是根據等值查詢條件，計算出匹配的真實表}}

到這里，針對hc_question_reply_record表，使用reply_wheel_time作為分片鍵，按照季度分片的處理就完成了。還有一點要注意的就是，分庫分表之后，查詢的時候最好都帶上分片鍵作為查詢條件，否則就會使用全庫路由，性能很低。

還有就是Sharing-JDBC對mysql的全文索引支持的不是很好，項目有使用到的地方也要注意一下。總結來說整個過程還是比較簡單的，后續碰到其它業務場景，相信大家按照這個思路肯定都能解決的。

“如何使用分庫分表Sharding-JDBC”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！