動(dòng)態(tài)數(shù)據(jù)源怎么與Sharding JDBC整合

這篇文章主要介紹“動(dòng)態(tài)數(shù)據(jù)源怎么與Sharding JDBC整合”，在日常操作中，相信很多人在動(dòng)態(tài)數(shù)據(jù)源怎么與Sharding JDBC整合問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”動(dòng)態(tài)數(shù)據(jù)源怎么與Sharding JDBC整合”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

原本定時(shí)任務(wù)就已經(jīng)使用了動(dòng)態(tài)數(shù)據(jù)源，而且一個(gè)數(shù)據(jù)源是mysql，另兩個(gè)是亞馬遜的db，而Sharding-JDBC并不支持亞馬遜的那兩個(gè)db，顯然是不能去掉動(dòng)態(tài)數(shù)據(jù)源的，只能想辦法讓兩者并存。

我的想法是，將mysql數(shù)據(jù)源配置給Sharding-JDBC數(shù)據(jù)源，讓Sharding-JDBC管理，而動(dòng)態(tài)數(shù)據(jù)源則管理Sharding-JDBC數(shù)據(jù)源。配置并不需要改動(dòng)什么。事務(wù)管理者依然是使用動(dòng)態(tài)數(shù)據(jù)源配置。

動(dòng)態(tài)數(shù)據(jù)源的配置如果還不了解，可以看下我之前寫(xiě)的這篇：Spring Boot項(xiàng)目多數(shù)據(jù)源配置

只需要將原本動(dòng)態(tài)數(shù)據(jù)源的配置修改為如下，將原本mysql數(shù)據(jù)源的位置替換為Sharding-JDBC數(shù)據(jù)源即可。事務(wù)的配置不需要改。

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

將mysql數(shù)據(jù)源配置給Sharding-JDBC數(shù)據(jù)源。

 @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數(shù)據(jù)源配置看上篇：優(yōu)化優(yōu)化再優(yōu)化之后，還是要分表，今日主角Sharding-JDBC

如果不是配置多個(gè)數(shù)據(jù)源且多個(gè)數(shù)據(jù)源之間沒(méi)有統(tǒng)一的管理者，那么才需要為每個(gè)數(shù)據(jù)源配置一個(gè)事務(wù)管理者。

看下DataSourceTransactionManager的源碼你就明白了。DataSourceTransactionManager是通過(guò)數(shù)據(jù)源獲取連接Connection的，事務(wù)的提交與回滾調(diào)用的是Connection的commit與rollback方法。所以，使用動(dòng)態(tài)數(shù)據(jù)源，事務(wù)管理者獲取到的就是目標(biāo)數(shù)據(jù)源返回的連接Connection。

現(xiàn)在只是將Sharding-JDBC數(shù)據(jù)源配置給動(dòng)態(tài)數(shù)據(jù)源，而mysql數(shù)據(jù)源則配置給Sharding-JDBC數(shù)據(jù)源。Sharding-JDBC數(shù)據(jù)源跟動(dòng)態(tài)數(shù)據(jù)源一樣，在getConnection被調(diào)用時(shí)動(dòng)態(tài)選擇目標(biāo)數(shù)據(jù)源，然后調(diào)用所選數(shù)據(jù)源的getConnection方法。這是一種設(shè)計(jì)模式，外界并不需要關(guān)心具體是如何獲取到正確的數(shù)據(jù)源的Connection的。

我在配置中指定了自增主鍵使用雪花算法生成的id。因?yàn)榉直砗蟛荒茉偈褂脭?shù)據(jù)庫(kù)的自增主鍵，否則根據(jù)id查找數(shù)據(jù)不知道查哪個(gè)表的，而且關(guān)聯(lián)的表還需要使用這個(gè)id進(jìn)行分表。

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

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

為何使用雪花算法：

1.雪花算法生成的id是增長(zhǎng)的，也就是有序的。在插入時(shí)不需要調(diào)整索引B+樹(shù)。

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

3.使用雪花算法可以推算出日期，對(duì)于關(guān)聯(lián)表可以使用這個(gè)特點(diǎn)實(shí)現(xiàn)分表。

驗(yàn)證結(jié)果如下圖，不出意料，確實(shí)在插入數(shù)據(jù)的使用Sharding-JDBC改寫(xiě)了sql，加入id字段，并使用雪花算法生成一個(gè)id。

圖中billid是我在完成數(shù)據(jù)的插入之后，查詢出來(lái)的id。

我把官方文檔從頭到尾看了一個(gè)遍，但是卻沒(méi)有找到關(guān)于自動(dòng)創(chuàng)建表的介紹，所以說(shuō)Sharding-JDBC并沒(méi)有智能到會(huì)幫我們創(chuàng)建表。當(dāng)按分表算法計(jì)算出來(lái)的物理表不存在時(shí)，便會(huì)出現(xiàn)一堆的異常信息。

Table 'cayman.report_click_info_201906' doesn't exist

我目前的做法是提前創(chuàng)建好未來(lái)的幾個(gè)月的表。缺點(diǎn)就是，如果有時(shí)候忘記了，整個(gè)服務(wù)都會(huì)因此而奔潰。

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

插入新記錄時(shí)，必須保證分片字段的值不能為空，否則直接報(bào)錯(cuò)。因?yàn)榉制侄螞](méi)有值，就沒(méi)有辦法路由到物理表，算不出來(lái)要插入哪個(gè)表，只能放棄拋出異常了。

正常情況下不允許使用可以為null的字段進(jìn)行分片。如果是使用日期類(lèi)型的字段，如記錄的創(chuàng)建時(shí)間create_datetime，作為分片（分表）字段，就不能在創(chuàng)建表的時(shí)候聲明默認(rèn)使用系統(tǒng)的當(dāng)前時(shí)間，應(yīng)該由插入數(shù)據(jù)的時(shí)候指定值，并且設(shè)置為不能為空。避免墨菲定律。

到此，關(guān)于“動(dòng)態(tài)數(shù)據(jù)源怎么與Sharding JDBC整合”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！