動態數據源怎么與Sharding JDBC整合

這篇文章主要介紹“動態數據源怎么與Sharding JDBC整合”，在日常操作中，相信很多人在動態數據源怎么與Sharding JDBC整合問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”動態數據源怎么與Sharding JDBC整合”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

原本定時任務就已經使用了動態數據源，而且一個數據源是mysql，另兩個是亞馬遜的db，而Sharding-JDBC并不支持亞馬遜的那兩個db，顯然是不能去掉動態數據源的，只能想辦法讓兩者并存。

我的想法是，將mysql數據源配置給Sharding-JDBC數據源，讓Sharding-JDBC管理，而動態數據源則管理Sharding-JDBC數據源。配置并不需要改動什么。事務管理者依然是使用動態數據源配置。

動態數據源的配置如果還不了解，可以看下我之前寫的這篇：Spring Boot項目多數據源配置

只需要將原本動態數據源的配置修改為如下，將原本mysql數據源的位置替換為Sharding-JDBC數據源即可。事務的配置不需要改。

/**     * 動態數據源: 通過AOP在不同數據源之間動態切換     *     * @return     */    @Primary    @Bean(name = "dynamicDataSource")    public DataSource dynamicDataSource(@Qualifier("shardingDataSource") DataSource shardingDataSource,                                        @Qualifier("athena-database") DataSource athenaDatabase) {        DynamicDataSource dynamicDataSource = new DynamicDataSource();        // 默認數據源,當沒有使用@DataSource注解時使用，        // 而使用了@DataSource注解如果沒有設置beanName也要Aop自己配置使用默認的bean        dynamicDataSource.setDefaultTargetDataSource(shardingDataSource);        // 配置多數據源        // key -> bean        Map<Object, Object> dsMap = new HashMap();        dsMap.put(DataSourceContextHolder.getDefaultDataSource(), shardingDataSource);        dsMap.put("athenaDatabase", athenaDatabase);        dynamicDataSource.setTargetDataSources(dsMap);        return dynamicDataSource;    }
    /**     * 配置@Transactional事物注解     * 使用動態數據源     *     * @return     */    @Bean("dynamicDataSourceTransactionManager")    public PlatformTransactionManager transactionManager(@Qualifier("dynamicDataSource") DataSource dynamicDataSource) {        return new DataSourceTransactionManager(dynamicDataSource);    }

將mysql數據源配置給Sharding-JDBC數據源。

 @Bean(name = "shardingDataSource") public DataSource dataSource(@Qualifier("mysql-database") DataSource mysqlDatabase) throws SQLException {        Map<String, DataSource> dataSourceMap = new HashMap<>();        dataSourceMap.put("ds01", mysqlDatabase);        return ShardingDataSourceConfig.getShardingDataSource(dataSourceMap, "ds01");}

Sharding-JDBC數據源配置看上篇：優化優化再優化之后，還是要分表，今日主角Sharding-JDBC

如果不是配置多個數據源且多個數據源之間沒有統一的管理者，那么才需要為每個數據源配置一個事務管理者。

看下DataSourceTransactionManager的源碼你就明白了。DataSourceTransactionManager是通過數據源獲取連接Connection的，事務的提交與回滾調用的是Connection的commit與rollback方法。所以，使用動態數據源，事務管理者獲取到的就是目標數據源返回的連接Connection。

現在只是將Sharding-JDBC數據源配置給動態數據源，而mysql數據源則配置給Sharding-JDBC數據源。Sharding-JDBC數據源跟動態數據源一樣，在getConnection被調用時動態選擇目標數據源，然后調用所選數據源的getConnection方法。這是一種設計模式，外界并不需要關心具體是如何獲取到正確的數據源的Connection的。

我在配置中指定了自增主鍵使用雪花算法生成的id。因為分表后不能再使用數據庫的自增主鍵，否則根據id查找數據不知道查哪個表的，而且關聯的表還需要使用這個id進行分表。

在配置表的路由規則的時候，除了配置表的分片策略，如果需要修改主鍵的生成，還需要給表的路由配置添加主鍵生成器，如下配置。官方提供uuid和雪花算法兩種分布式主鍵生成方法。

 // 配置分布式id生成算法，必須使用雪花算法，否則report_click_info表無法與之關聯Properties properties = new Properties();properties.setProperty("worker.id", "10");result.setKeyGeneratorConfig(new KeyGeneratorConfiguration("SNOWFLAKE", "id", properties));

為何使用雪花算法：

1.雪花算法生成的id是增長的，也就是有序的。在插入時不需要調整索引B+樹。

2.原本數據庫中的id是整型，BIGINT(20)，所以使用雪花算法不需要修改表的結構，也不需要添加額外的列。

3.使用雪花算法可以推算出日期，對于關聯表可以使用這個特點實現分表。

驗證結果如下圖，不出意料，確實在插入數據的使用Sharding-JDBC改寫了sql，加入id字段，并使用雪花算法生成一個id。

圖中billid是我在完成數據的插入之后，查詢出來的id。

我把官方文檔從頭到尾看了一個遍，但是卻沒有找到關于自動創建表的介紹，所以說Sharding-JDBC并沒有智能到會幫我們創建表。當按分表算法計算出來的物理表不存在時，便會出現一堆的異常信息。

Table 'cayman.report_click_info_201906' doesn't exist

我目前的做法是提前創建好未來的幾個月的表。缺點就是，如果有時候忘記了，整個服務都會因此而奔潰。

目前我所能想到的就是在計算表名的時候（ShardingAlgorithm的doSharding方法中），判斷一下這個表是否存在，不存在則創建，但是每次都判斷一次很耗性能。單庫還好，多庫（分庫）情況下更糟糕。

插入新記錄時，必須保證分片字段的值不能為空，否則直接報錯。因為分片字段沒有值，就沒有辦法路由到物理表，算不出來要插入哪個表，只能放棄拋出異常了。

正常情況下不允許使用可以為null的字段進行分片。如果是使用日期類型的字段，如記錄的創建時間create_datetime，作為分片（分表）字段，就不能在創建表的時候聲明默認使用系統的當前時間，應該由插入數據的時候指定值，并且設置為不能為空。避免墨菲定律。

到此，關于“動態數據源怎么與Sharding JDBC整合”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！