首頁>技術>

前言

最近專案中不少表的資料量越來越大,並且導致了一些資料庫的效能問題。因此想借助一些分庫分表的中介軟體,實現自動化分庫分表實現。調研下來,發現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種分片演算法。由於分片演算法和業務實現緊密相關,因此並未提供內建分片演算法,而是透過分片策略將各種場景提煉出來,提供更高層級的抽象,並提供介面讓應用開發者自行實現分片演算法。

精確分片演算法

對應 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,ds1spring.shardingsphere.datasource.ds0.type=org.apache.commons.dbcp.BasicDataSourcespring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds0.url=jdbc:mysql://localhost:3306/ds0spring.shardingsphere.datasource.ds0.username=rootspring.shardingsphere.datasource.ds0.password=spring.shardingsphere.datasource.ds1.type=org.apache.commons.dbcp.BasicDataSourcespring.shardingsphere.datasource.ds1.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds1.url=jdbc:mysql://localhost:3306/ds1spring.shardingsphere.datasource.ds1.username=rootspring.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();    }}
分散式id生成器配置

Sharding-JDBC提供了UUID、SNOWFLAKE生成器,還支援使用者實現自定義id生成器。比如可以實現了type為SEQ的分散式id生成器,呼叫統一的分散式id服務獲取id。

@Datapublic 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_recordGROUP 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的全文索引支援的不是很好,專案有使用到的地方也要注意一下。總結來說整個過程還是比較簡單的,後續碰到其它業務場景,相信大家按照這個思路肯定都能解決的。

6
最新評論
  • BSA-TRITC(10mg/ml) TRITC-BSA 牛血清白蛋白改性標記羅丹明
  • 從log4j2的角度看golang的zap