據(jù)源動態(tài)切換實(shí)戰(zhàn)：MySQL與SqlServer)
1. 項目背景與多數(shù)據(jù)源需求拆解1.1 為什么一個項目會同時連上 MySQL 和 SqlServer在實(shí)際業(yè)務(wù)里一套服務(wù)對接多個數(shù)據(jù)庫的需求比想象中要普遍。我這次遇到的項目就是一個典型的傳統(tǒng)行業(yè)改造場景老系統(tǒng)跑在 SqlServer 上沉淀了十多年的歷史數(shù)據(jù)包括訂單流水、人員檔案、流程審批記錄這些數(shù)據(jù)不能說丟就丟也不可能短期內(nèi)做完整遷移。而新開發(fā)的業(yè)務(wù)模塊比如用戶畫像、消息推送、數(shù)據(jù)分析報表則更適合放到 MySQL 里畢竟這套技術(shù)棧更輕量生態(tài)也更活躍團(tuán)隊維護(hù)起來成本更低。項目要求很直白同一個 SpringBoot 服務(wù)里既要能查 SqlServer 里的歷史數(shù)據(jù)又要能讀寫 MySQL 里的新業(yè)務(wù)數(shù)據(jù)還得保證切換過程對業(yè)務(wù)代碼盡可能透明。翻譯成技術(shù)語言就是要在 MyBatisPlus 這套 ORM 框架下實(shí)現(xiàn)多數(shù)據(jù)源接入和動態(tài)切換。這里先說明一個容易混淆的概念。多數(shù)據(jù)源和讀寫分離是兩回事。讀寫分離是同一個數(shù)據(jù)庫的主從副本結(jié)構(gòu)完全一致只是分擔(dān)讀寫的壓力。多數(shù)據(jù)源則是多個獨(dú)立的數(shù)據(jù)庫實(shí)例結(jié)構(gòu)可能完全不同甚至數(shù)據(jù)庫類型都不一樣——MySQL 和 SqlServer 在 SQL 語法、分頁方式、數(shù)據(jù)類型上都有差異。本次項目屬于后者難點(diǎn)在于不是簡單配兩個連接池就完事而是要讓上層業(yè)務(wù)代碼在幾乎無感知的情況下完成數(shù)據(jù)源的切換。1.2 方案選型對比分包、AOP切面還是動態(tài)路由多數(shù)據(jù)源的實(shí)現(xiàn)方案業(yè)界主流有幾種我簡單梳理一下方便大家對照自己的場景選型。第一種叫分包方式也是最古老的做法。按照包名區(qū)分 dao 層接口比如com.example.mapper.mysql下的走 MySQL 數(shù)據(jù)源com.example.mapper.sqlserver下的走 SqlServer 數(shù)據(jù)源。每個數(shù)據(jù)源配置獨(dú)立的SqlSessionFactory各管各的包互不干擾。優(yōu)點(diǎn)是實(shí)現(xiàn)簡單、邏輯清晰問題是有多少數(shù)據(jù)源就要配置多少套 MyBatis 環(huán)境代碼一多維護(hù)成本就上來了而且一旦出現(xiàn)跨庫業(yè)務(wù)就得寫多套 Mapper 去拼裝數(shù)據(jù)。第二種是 AOP 自定義注解的方式。核心思路是定義一個DataSource注解標(biāo)注在 Service 或 Mapper 方法上通過切面在方法執(zhí)行前動態(tài)切換數(shù)據(jù)源執(zhí)行完再切回來。這種方式靈活度高可以做到按方法粒度控制數(shù)據(jù)源而且改造量相對小只要在需要切換的方法上加個注解就行。第三種是動態(tài)路由方式基于 Spring 提供的AbstractRoutingDataSource抽象類。它內(nèi)部維護(hù)一個目標(biāo)數(shù)據(jù)源的 Map通過determineCurrentLookupKey()方法動態(tài)決定當(dāng)前線程使用哪個數(shù)據(jù)源。配合 ThreadLocal 存儲數(shù)據(jù)源標(biāo)識就能實(shí)現(xiàn)運(yùn)行時的自由切換。我最終選的是方案二和方案三的結(jié)合基于AbstractRoutingDataSource做底層路由再封裝自定義注解和 AOP 切面做上層控制。這樣既能享受動態(tài)切換的靈活性又能通過注解讓業(yè)務(wù)代碼保持整潔。這也是目前大多數(shù)互聯(lián)網(wǎng)項目的通行做法如果你看過一些開源的多數(shù)據(jù)源框架比如dynamic-datasource-spring-boot-starter底層思路其實(shí)是一樣的。1.3 項目環(huán)境與版本信息做之前先把版本定下來避免后面掉進(jìn)版本兼容的坑里。我這次用的環(huán)境是組件版本JDK1.8SpringBoot2.3.7.RELEASEMyBatisPlus3.4.3.4MySQL5.7SqlServer2012Maven3.6.3這里提醒一句SpringBoot 版本別追太高。我見過有同事直接用 SpringBoot 3.x結(jié)果發(fā)現(xiàn)javax變成了jakarta很多老依賴都跑不起來。如果項目里還有歷史代碼建議先用 2.x 的穩(wěn)定版本把功能跑通。2. 靜態(tài)雙數(shù)據(jù)源配置從零開始接入 MySQL 和 SqlServer2.1 Maven 依賴引入的正確姿勢先把基礎(chǔ)依賴配好。除了 SpringBoot 和 MyBatisPlus 的常規(guī)依賴之外還需要把兩個數(shù)據(jù)庫的驅(qū)動都引進(jìn)來。這里有個容易踩的坑MySQL 驅(qū)動的 groupId 和 artifactId 在不同版本之間有變化mysql:mysql-connector-java是老坐標(biāo)com.mysql:mysql-connector-j是新坐標(biāo)別搞混了。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.4.3.4/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.49/version /dependency dependency groupIdcom.microsoft.sqlserver/groupId artifactIdmssql-jdbc/artifactId version9.4.1.jre8/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependencySqlServer 驅(qū)動的版本選擇有個細(xì)節(jié)。mssql-jdbc的版本號后綴jre8表示支持 Java 8如果你用的 JDK 是 1.8選帶這個后綴的版本最穩(wěn)妥。如果項目用 JDK 11 以上可以選不帶后綴或帶jre11的版本。2.2 application.yml 配置兩個數(shù)據(jù)源的參數(shù)化配置依賴配好后就是寫配置。我習(xí)慣把數(shù)據(jù)源信息放在application.yml里動態(tài)配置這樣不同環(huán)境之間切換只需要改配置文件不用動代碼。spring: datasource: mysql: driver-class-name: com.mysql.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/business_db?useUnicodetruecharacterEncodingutf-8useSSLfalse username: root password: root123 sqlserver: driver-class-name: com.microsoft.sqlserver.jdbc.SQLServerDriver jdbc-url: jdbc:sqlserver://192.168.1.100:1433;DatabaseNamehistory_db username: sa password: Sa123456注意這里的 key 是jdbc-url不是url。如果用urlSpringBoot 的自動配置會嘗試把它當(dāng)作默認(rèn)數(shù)據(jù)源來處理導(dǎo)致多數(shù)據(jù)源場景下的配置錯亂。這是我見過很多人踩過的坑寫的時候一定要看清。另外有個小細(xì)節(jié)每套數(shù)據(jù)源的driver-class-name必須明確指定不要依賴 SpringBoot 自動推斷。MySQL 8.0 以上版本驅(qū)動類名變成了com.mysql.cj.jdbc.Driver如果你用的是 8.x 驅(qū)動卻配了舊類名啟動時必報錯。2.3 數(shù)據(jù)源配置類手動裝配 SqlSessionFactory多數(shù)據(jù)源場景下需要手動創(chuàng)建數(shù)據(jù)源和SqlSessionFactory繞開 SpringBoot 的自動配置。這里以 MySQL 數(shù)據(jù)源為例Configuration public class DataSourceConfig { Bean(name mysqlDataSource) ConfigurationProperties(prefix spring.datasource.mysql) public DataSource mysqlDataSource() { return DataSourceBuilder.create().build(); } Bean(name sqlServerDataSource) ConfigurationProperties(prefix spring.datasource.sqlserver) public DataSource sqlServerDataSource() { return DataSourceBuilder.create().build(); } Bean(name dynamicDataSource) public DataSource dynamicDataSource() { DynamicDataSource dynamicDataSource new DynamicDataSource(); MapObject, Object dataSourceMap new HashMap(4); dataSourceMap.put(mysql, mysqlDataSource()); dataSourceMap.put(sqlserver, sqlServerDataSource()); dynamicDataSource.setTargetDataSources(dataSourceMap); dynamicDataSource.setDefaultTargetDataSource(mysqlDataSource()); return dynamicDataSource; } Bean(name sqlSessionFactory) public SqlSessionFactory sqlSessionFactory(Qualifier(dynamicDataSource) DataSource dynamicDataSource) throws Exception { MybatisSqlSessionFactoryBean sessionFactory new MybatisSqlSessionFactoryBean(); sessionFactory.setDataSource(dynamicDataSource); sessionFactory.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources(classpath*:mapper/**/*.xml)); return sessionFactory.getObject(); } }這里有幾個關(guān)鍵點(diǎn)。第一MybatisSqlSessionFactoryBean用的是 MyBatisPlus 自帶的類不是 mybatis 原生的SqlSessionFactoryBean這樣才能讓 MyBatisPlus 的分頁插件、邏輯刪除等功能生效。第二mapperLocations用classpath*通配符這樣多個數(shù)據(jù)源的 Mapper XML 文件可以放在不同子目錄下避免路徑?jīng)_突。第三dynamicDataSource作為唯一的數(shù)據(jù)源注入到 MyBatis 里所以最終所有 Mapper 操作的入口都是動態(tài)數(shù)據(jù)源由它在內(nèi)部做轉(zhuǎn)發(fā)。3. 動態(tài)數(shù)據(jù)源實(shí)現(xiàn)核心類與 AOP 自動切換3.1 AbstractRoutingDataSourceSpring 預(yù)留的擴(kuò)展點(diǎn)AbstractRoutingDataSource是 Spring 提供的一個抽象類它的核心作用就是做一個路由分發(fā)。你可以把它理解成一個中轉(zhuǎn)站它自己不是一個真正意義上的數(shù)據(jù)庫連接池而是維護(hù)著一組目標(biāo)數(shù)據(jù)源每次獲取連接的時候通過抽象方法determineCurrentLookupKey()來決定應(yīng)該返回哪個真實(shí)數(shù)據(jù)源的連接。實(shí)現(xiàn)起來很簡單public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { return DataSourceContextHolder.getDataSourceKey(); } }關(guān)鍵是DataSourceContextHolder通常用 ThreadLocal 實(shí)現(xiàn)public class DataSourceContextHolder { private static final ThreadLocalString CONTEXT new ThreadLocal(); public static void setDataSourceKey(String dataSourceKey) { CONTEXT.set(dataSourceKey); } public static String getDataSourceKey() { return CONTEXT.get(); } public static void clear() { CONTEXT.remove(); } }為什么必須用 ThreadLocal因為 Spring 的DataSourceUtils在獲取連接的時候會先看當(dāng)前事務(wù)上下文里是否已有連接如果有就直接復(fù)用。ThreadLocal 能保證同一線程內(nèi)數(shù)據(jù)源切換在當(dāng)前線程內(nèi)是隔離的不會影響其他線程。但這也引出一個隱患——線程池復(fù)用問題后面我會在踩坑部分詳細(xì)說。3.2 自定義注解 DataSource光有路由還不夠得讓業(yè)務(wù)代碼能方便地指定數(shù)據(jù)源。我定義了一個注解Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) Documented public interface DataSource { String value() default mysql; }這個注解可以標(biāo)注在 Service 方法上也可以標(biāo)注在類上。標(biāo)注在類上表示整個類的所有方法默認(rèn)走某個數(shù)據(jù)源標(biāo)注在方法上則覆蓋類級別的配置。一個是粗粒度一個是細(xì)粒度兩者結(jié)合使用起來非常靈活。3.3 AOP 切面方法執(zhí)行前自動切換核心切面邏輯如下Aspect Component Order(1) public class DataSourceAspect { Pointcut(annotation(com.example.annotation.DataSource) || within(com.example.annotation.DataSource)) public void dataSourcePointCut() {} Before(dataSourcePointCut()) public void doBefore(JoinPoint joinPoint) { MethodSignature signature (MethodSignature) joinPoint.getSignature(); Method method signature.getMethod(); DataSource dataSource method.getAnnotation(DataSource.class); if (dataSource null) { dataSource joinPoint.getTarget().getClass().getAnnotation(DataSource.class); } if (dataSource ! null) { DataSourceContextHolder.setDataSourceKey(dataSource.value()); } } After(dataSourcePointCut()) public void doAfter(JoinPoint joinPoint) { DataSourceContextHolder.clear(); } }切面的Order(1)很重要。如果項目里同時有事務(wù)切面必須保證數(shù)據(jù)源切面的優(yōu)先級高于事務(wù)切面。原因在于Spring 的事務(wù)管理在開啟事務(wù)時就要確定使用哪個數(shù)據(jù)源如果事務(wù)切面先執(zhí)行它拿到的還是默認(rèn)數(shù)據(jù)源后面的切換就白做了。切面邏輯里有個細(xì)節(jié)within是用來匹配類級別注解的。我的切點(diǎn)同時寫了annotation和within這樣能兼顧方法級和類級的注解配置避免在使用類級注解時切面不生效的問題。4. 實(shí)操踩坑實(shí)錄MyBatisPlus 配合多數(shù)據(jù)源的高頻問題4.1 分頁插件配置問題單頁 500 條限制的真相先說說 MyBatisPlus 分頁的事。很多人在網(wǎng)上搜到MyBatisPlus 單頁 500 條限制其實(shí)這并不是框架硬編碼的限制而是分頁插件配置不到位導(dǎo)致的。老版本的 MyBatisPlus 分頁插件默認(rèn)有l(wèi)imit保護(hù)不配置的話某些版本會限制單頁查詢條數(shù)。正確配置方式是在 MyBatisPlus 的配置類里添加分頁插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor paginationInnerInterceptor new PaginationInnerInterceptor(); paginationInnerInterceptor.setMaxLimit(500L); paginationInnerInterceptor.setOverflow(false); interceptor.addInnerInterceptor(paginationInnerInterceptor); return interceptor; } }這里setMaxLimit(500L)就是網(wǎng)上說的單頁 500 限制的源頭。如果不希望限制單頁大小可以把這個值設(shè)大或者不設(shè)置。但我要提醒一句這個限制其實(shí)是好心防止有人寫LIMIT 1000000這種查詢把數(shù)據(jù)庫打掛。生產(chǎn)環(huán)境建議保留只是結(jié)合實(shí)際業(yè)務(wù)把閾值調(diào)到一個合理的值。另外一個更隱蔽的問題是在多數(shù)據(jù)源場景下MySQL 和 SqlServer 的分頁語法不一樣。MySQL 用LIMIT ? OFFSETSqlServer 2012 以上用OFFSET ? ROWS FETCH NEXT ? ROWS ONLY。如果只給 MyBatisPlus 配置了 MySQL 方言的分頁插件切到 SqlServer 后分頁邏輯就會出錯。好在 MyBatisPlus 的PaginationInnerInterceptor是支持多方言的它會根據(jù)當(dāng)前數(shù)據(jù)源的類型自動選擇合適的方言。但這要求你的多個數(shù)據(jù)源必須都注冊到同一個 MyBatis 環(huán)境里而不能拆成多個SqlSessionFactory否則多方言識別就失效了。4.2 關(guān)鍵字沖突表名和字段名的那些坑SqlServer 有一些保留關(guān)鍵字是 MySQL 里可以隨便用的比如order、user、group、index等。我在項目里就碰到過一張 SqlServer 的歷史表字段名叫index在 MySQL 里這個字段名完全合法在 SqlServer 里必須加方括號才能查。MyBatisPlus 提供了全局的關(guān)鍵字自動轉(zhuǎn)義開關(guān)mybatis-plus: global-config: db-config: column-format: %s但這個配置只對 MySQL 的反引號有效。如果同時操作 SqlServer反引號就不認(rèn)了。更穩(wěn)妥的做法是在實(shí)體類的TableField注解上手動指定別名TableField(index) private Integer index;如果是 SqlServer需要寫成TableField([index]) private Integer index;這種問題防不勝防尤其是接手老數(shù)據(jù)庫的時候。我的建議是先用工具連上 SqlServer把涉及的表結(jié)構(gòu)和字段整體瀏覽一遍建一個關(guān)鍵字清單寫 Mapper 的時候?qū)φ罩幚韯e等到運(yùn)行時報錯了再回頭一個個查。4.3 事務(wù)與數(shù)據(jù)源切換的沖突這個坑非常典型。場景是這樣的有一個方法需要先查 SqlServer 的數(shù)據(jù)再做業(yè)務(wù)處理最后寫 MySQL。一開始我直接在方法上加了Transactional然后通過 AOP 切數(shù)據(jù)源結(jié)果發(fā)現(xiàn)第二個操作還是走的老數(shù)據(jù)源。原因一句話說清楚事務(wù)開啟時數(shù)據(jù)源就已經(jīng)固定了。Transactional是在方法進(jìn)入前就通過事務(wù)管理器獲取了連接后續(xù)的數(shù)據(jù)源切換只是在DataSourceContextHolder里改了 ThreadLocal 的值但事務(wù)上下文里持有的連接還是老數(shù)據(jù)源的那個切不過去。解決辦法有這么幾種第一種業(yè)務(wù)允許的情況下把跨數(shù)據(jù)源的操作拆成兩個方法分別加事務(wù)通過調(diào)用另一個 Service 的方法來完成。這是最省事的辦法。第二種使用分布式事務(wù)方案比如 Seata、Atomikos但引入成本較高小項目沒必要。第三種也是最常用的用編程式事務(wù)替代聲明式事務(wù)Autowired private TransactionTemplate transactionTemplate; public void crossDataSourceOperation() { DataSourceContextHolder.setDataSourceKey(sqlserver); Object result queryFromSqlServer(); DataSourceContextHolder.clear(); transactionTemplate.execute(status - { DataSourceContextHolder.setDataSourceKey(mysql); try { insertToMysql(result); return true; } catch (Exception e) { status.setRollbackOnly(); throw e; } finally { DataSourceContextHolder.clear(); } }); }這樣每個數(shù)據(jù)源的操作在自己的事務(wù)模板里管理互不干擾。但跨數(shù)據(jù)源的數(shù)據(jù)一致性就只能靠業(yè)務(wù)補(bǔ)償來保證了這也是多數(shù)據(jù)源方案天然的限制。4.4 連接池配置多個數(shù)據(jù)源各自為戰(zhàn)連接池這塊也容易出問題。默認(rèn)情況下SpringBoot 2.x 會使用 HikariCP 作為連接池。多數(shù)據(jù)源時每個數(shù)據(jù)源應(yīng)該有自己的連接池配置避免共用一個連接池導(dǎo)致連接耗盡。spring: datasource: mysql: hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 sqlserver: hikari: minimum-idle: 3 maximum-pool-size: 10 connection-timeout: 15000SqlServer 的連接池大小不用配得跟 MySQL 一樣大。因為 SqlServer 在老系統(tǒng)里主要用于查詢歷史數(shù)據(jù)并發(fā)量相對較低配小一點(diǎn)可以節(jié)省資源。同理超時時間也可以設(shè)置短一些避免 SqlServer 響應(yīng)慢的時候拖垮應(yīng)用線程。4.5 SqlServer 排序規(guī)則沖突問題網(wǎng)上有個熱詞是sqlserver cannot resolve the collation conflict翻譯過來就是排序規(guī)則沖突。這個問題出現(xiàn)在 SqlServer 的臨時表關(guān)聯(lián)查詢時如果兩個表的排序規(guī)則比如Chinese_PRC_CI_AS和SQL_Latin1_General_CP1_CI_AS不一致關(guān)聯(lián)查詢會報錯。在多數(shù)據(jù)源場景下如果我們從 MySQL 同步數(shù)據(jù)到 SqlServer再臨時建表去關(guān)聯(lián)歷史表很容易觸發(fā)這個問題。解決辦法是建臨時表時顯式指定排序規(guī)則CREATE TABLE #temp_table ( user_name NVARCHAR(50) COLLATE Chinese_PRC_CI_AS )或者在關(guān)聯(lián)時用COLLATE強(qiáng)制指定SELECT * FROM table_a a INNER JOIN table_b b ON a.name b.name COLLATE Chinese_PRC_CI_AS這個坑可能隱藏得比較深我遇到過因為排序規(guī)則不一致導(dǎo)致的慢查詢排查了很久才發(fā)現(xiàn)是隱式轉(zhuǎn)換導(dǎo)致索引失效。4.6 SqlServer 字符串轉(zhuǎn)數(shù)字多數(shù)據(jù)源下的數(shù)據(jù)類型兼容SqlServer 里把字符串轉(zhuǎn)數(shù)字常用CAST或CONVERTSELECT CAST(123 AS INT) SELECT CONVERT(INT, 123)MySQL 則用CAST(123 AS SIGNED)或者直接123 0。如果項目里有共用 Mapper XML不同數(shù)據(jù)庫的轉(zhuǎn)換語法就得分別寫不能混用。我的做法是把這類數(shù)據(jù)庫相關(guān)的 SQL 拆到各自的 Mapper 里通過數(shù)據(jù)源切換來保證執(zhí)行正確。另外要注意 SqlServer 的CAST轉(zhuǎn)換失敗會直接報錯不像 MySQL 在某些模式下會有寬松處理。生產(chǎn)環(huán)境如果遇到臟數(shù)據(jù)字符串里有空格或特殊字符轉(zhuǎn)換就會炸。建議先用ISNUMERIC判斷一下SELECT CASE WHEN ISNUMERIC(column_name) 1 THEN CAST(column_name AS INT) ELSE 0 END FROM table_name5. 多數(shù)據(jù)源方案驗證與優(yōu)化建議5.1 單元測試怎么寫才靠譜數(shù)據(jù)源切換這種邏輯一定要寫測試驗證不能等上線了再看效果。我用 SpringBootTest 寫了幾組測試用例覆蓋不同場景的切換邏輯。SpringBootTest RunWith(SpringRunner.class) public class DataSourceSwitchTest { Autowired private UserService userService; Test public void testQueryMysqlUser() { User user userService.getUserFromMysql(1L); Assert.assertNotNull(user); } Test public void testQuerySqlServerUser() { User user userService.getUserFromSqlServer(100L); Assert.assertNotNull(user); } Test public void testSwitchBetweenDataSources() { User mysqlUser userService.getUserFromMysql(1L); User sqlServerUser userService.getUserFromSqlServer(100L); Assert.assertNotNull(mysqlUser); Assert.assertNotNull(sqlServerUser); } }注意測試方法的執(zhí)行順序。JUnit 默認(rèn)的方法執(zhí)行順序是不固定的如果測試類里多個方法都在切換數(shù)據(jù)源ThreadLocal 里的值可能在方法結(jié)束后由After清理一般不會互相影響。但如果某些測試并發(fā)執(zhí)行異常可能會出現(xiàn)數(shù)據(jù)源串了的情況。穩(wěn)妥起見每個測試方法都從默認(rèn)狀態(tài)開始不依賴前一個方法的執(zhí)行結(jié)果。5.2 多數(shù)據(jù)源下的性能優(yōu)化多數(shù)據(jù)源不只是配置問題性能同樣要關(guān)注。幾個實(shí)測經(jīng)驗第一連接池參數(shù)要分別調(diào)優(yōu)。MySQL 作為主庫讀寫頻繁最大連接數(shù)可以設(shè)置得高一些SqlServer 作為輔助庫查詢量大但并發(fā)不高連接數(shù)可以少一些。第二跨數(shù)據(jù)源的循環(huán)查詢要避免。比如先查 SqlServer 拿到 1000 條記錄然后再循環(huán)查 MySQL 補(bǔ)充信息這種寫法性能極差。正確做法是把 SqlServer 查出來的 ID 集合一次性傳給 MySQL用IN查詢批量處理。第三如果查詢的數(shù)據(jù)量比較大利用好索引。SqlServer 老表的索引往往不夠優(yōu)化必要時可以創(chuàng)建覆蓋索引來加速常用查詢。但 DDL 操作要謹(jǐn)慎避免高峰期執(zhí)行。5.3 從 MyBatis 到 MyBatisPlus 的兼容保障項目里既有 MyBatis 的 XML 寫法也有 MyBatisPlus 的 Wrapper 寫法。多數(shù)據(jù)源下這兩種寫法都需要保證切換正常。我踩過的一個坑是在某個自定義 SQL 里用了${ew.customSqlSegment}結(jié)果 MyBatisPlus 的多表查詢沒有自動帶上數(shù)據(jù)源切換邏輯導(dǎo)致部分?jǐn)?shù)據(jù)查不到。這個問題的根源在于MyBatisPlus 的 Wrapper 條件構(gòu)造器在生成 SQL 時對IN類型的條件會有數(shù)量限制的優(yōu)化邏輯。對于超過 1000 條的IN查詢MyBatisPlus 會做拆分處理但這個拆分后的 SQL 執(zhí)行順序可能與數(shù)據(jù)源切換順序不一致。解決方案是手動把IN查詢拆分為多個小批次避免單條 SQL 過大。另外如果要在 MyBatisPlus 中使用自定義 SQL 并拼接 Wrapper建議用${ew.customSqlSegment}時注意轉(zhuǎn)義問題尤其是字段名包含關(guān)鍵字時要在注解或 XML 里確認(rèn)最終 SQL 的正確性。6. 常見問題速查表與排查技巧6.1 問題匯總癥狀可能原因解決辦法啟動報DataSource循環(huán)依賴多個數(shù)據(jù)源的 Bean 互相引用用Primary指定主數(shù)據(jù)源或在配置類中通過Qualifier明確注入切換數(shù)據(jù)源不生效AOP 切面沒有攔截到方法確認(rèn)自定義注解是否標(biāo)在 Service 方法上Order(1)是否配置事務(wù)方法內(nèi)切換數(shù)據(jù)源失敗事務(wù)開啟時連接已鎖定拆分方法或使用編程式事務(wù)SqlServer 查詢報錯字段名是保留字用方括號括起來MyBatisPlus 分頁在 SqlServer 下失效方言識別失敗PaginationInnerInterceptor注冊后確認(rèn)多數(shù)據(jù)源共享同一個SqlSessionFactory連接池報Connection is not available連接泄露或配置過小檢查連接池配置用SELECT * FROM sys.dm_exec_connections之類的語句排查6.2 排查思路與調(diào)試技巧多數(shù)據(jù)源問題排查第一步永遠(yuǎn)是確認(rèn)當(dāng)前線程的數(shù)據(jù)源是什么。我一般在DataSourceAspect里加一行日志log.info(switch datasource to{}, dataSource.value());然后觀察日志輸出是否與預(yù)期一致。如果日志顯示已切換但查詢還是走的老庫那問題大概率出在事務(wù)上如果日志都沒打印那就是 AOP 切面沒起作用需要檢查注解位置和 Spring 掃描路徑。第二個技巧是打開 HikariCP 的連接獲取日志通過監(jiān)控連接池的活動情況來判斷數(shù)據(jù)源是否正確。在application.yml里配置logging: level: com.zaxxer.hikari: DEBUG這樣可以看到每次獲取連接來自哪個數(shù)據(jù)源、連接池的活躍數(shù)是多少對定位連接泄露和切換異常都很有幫助。第三個技巧是查看 MyBatis 的執(zhí)行日志。MyBatisPlus 提供了 SQL 輸出日志可以配置輸出 SQL 內(nèi)容確認(rèn)執(zhí)行的 SQL 語句是否符合當(dāng)前數(shù)據(jù)源的方言。如果 SQL 語法是 MySQL 的但執(zhí)行到了 SqlServer 上基本可以斷定是數(shù)據(jù)源切換出了問題。6.3 后續(xù)擴(kuò)展動態(tài)加數(shù)據(jù)源、分布式事務(wù)如果項目后續(xù)要接入更多數(shù)據(jù)源比如再加一個 PostgreSQL只需要在DataSourceConfig中添加一個新的數(shù)據(jù)源 Bean然后在dynamicDataSource中把它put進(jìn)targetDataSources即可。但要注意如果數(shù)據(jù)源是運(yùn)行時動態(tài)增加的比如多租戶場景需要調(diào)用AbstractRoutingDataSource的afterPropertiesSet()方法來刷新配置。分布式事務(wù)是個更深的話題。如果業(yè)務(wù)上真的需要跨庫的強(qiáng)一致性比如一個操作既要寫 MySQL 又要寫 SqlServer多數(shù)據(jù)源方案已經(jīng)解決不了問題了得引入分布式事務(wù)中間件。我的建議是盡早評估業(yè)務(wù)場景如果只是簡單的查詢和異步補(bǔ)償多數(shù)據(jù)源方案完全夠用如果要做強(qiáng)一致的跨庫寫操作提前設(shè)計好技術(shù)選型不要等寫完了再返工。我在實(shí)際項目中的體會是多數(shù)據(jù)源本身并不復(fù)雜復(fù)雜的永遠(yuǎn)是業(yè)務(wù)邊界和異常處理。動手之前先想清楚哪個庫是主、哪個庫是輔在代碼層面規(guī)定好數(shù)據(jù)源的使用規(guī)范比什么花哨的框架都重要。最后再分享一個平時容易忽略的小細(xì)節(jié)如果你的項目在部署時切換了環(huán)境記得檢查數(shù)據(jù)庫連接串和賬號權(quán)限我遇到過多次因為新環(huán)境 SqlServer 登錄賬號缺少VIEW SERVER STATE權(quán)限導(dǎo)致連接池初始化異常的案例這類問題一般不報錯清楚排查起來比較費(fèi)勁提前做好環(huán)境檢查能省不少事。 SpringBoot+MyBatisPlus多數(shù)據(jù)源動態(tài)切換實(shí)戰(zhàn)：MySQL與SqlServer
1. 項目背景與多數(shù)據(jù)源需求拆解1.1 為什么一個項目會同時連上 MySQL 和 SqlServer在實(shí)際業(yè)務(wù)里一套服務(wù)對接多個數(shù)據(jù)庫的需求比想象中要普遍。我這次遇到的項目就是一個典型的傳統(tǒng)行業(yè)改造場景老系統(tǒng)跑在 SqlServer 上沉淀了十多年的歷史數(shù)據(jù)包括訂單流水、人員檔案、流程審批記錄這些數(shù)據(jù)不能說丟就丟也不可能短期內(nèi)做完整遷移。而新開發(fā)的業(yè)務(wù)模塊比如用戶畫像、消息推送、數(shù)據(jù)分析報表則更適合放到 MySQL 里畢竟這套技術(shù)棧更輕量生態(tài)也更活躍團(tuán)隊維護(hù)起來成本更低。項目要求很直白同一個 SpringBoot 服務(wù)里既要能查 SqlServer 里的歷史數(shù)據(jù)又要能讀寫 MySQL 里的新業(yè)務(wù)數(shù)據(jù)還得保證切換過程對業(yè)務(wù)代碼盡可能透明。翻譯成技術(shù)語言就是要在 MyBatisPlus 這套 ORM 框架下實(shí)現(xiàn)多數(shù)據(jù)源接入和動態(tài)切換。這里先說明一個容易混淆的概念。多數(shù)據(jù)源和讀寫分離是兩回事。讀寫分離是同一個數(shù)據(jù)庫的主從副本結(jié)構(gòu)完全一致只是分擔(dān)讀寫的壓力。多數(shù)據(jù)源則是多個獨(dú)立的數(shù)據(jù)庫實(shí)例結(jié)構(gòu)可能完全不同甚至數(shù)據(jù)庫類型都不一樣——MySQL 和 SqlServer 在 SQL 語法、分頁方式、數(shù)據(jù)類型上都有差異。本次項目屬于后者難點(diǎn)在于不是簡單配兩個連接池就完事而是要讓上層業(yè)務(wù)代碼在幾乎無感知的情況下完成數(shù)據(jù)源的切換。1.2 方案選型對比分包、AOP切面還是動態(tài)路由多數(shù)據(jù)源的實(shí)現(xiàn)方案業(yè)界主流有幾種我簡單梳理一下方便大家對照自己的場景選型。第一種叫分包方式也是最古老的做法。按照包名區(qū)分 dao 層接口比如com.example.mapper.mysql下的走 MySQL 數(shù)據(jù)源com.example.mapper.sqlserver下的走 SqlServer 數(shù)據(jù)源。每個數(shù)據(jù)源配置獨(dú)立的SqlSessionFactory各管各的包互不干擾。優(yōu)點(diǎn)是實(shí)現(xiàn)簡單、邏輯清晰問題是有多少數(shù)據(jù)源就要配置多少套 MyBatis 環(huán)境代碼一多維護(hù)成本就上來了而且一旦出現(xiàn)跨庫業(yè)務(wù)就得寫多套 Mapper 去拼裝數(shù)據(jù)。第二種是 AOP 自定義注解的方式。核心思路是定義一個DataSource注解標(biāo)注在 Service 或 Mapper 方法上通過切面在方法執(zhí)行前動態(tài)切換數(shù)據(jù)源執(zhí)行完再切回來。這種方式靈活度高可以做到按方法粒度控制數(shù)據(jù)源而且改造量相對小只要在需要切換的方法上加個注解就行。第三種是動態(tài)路由方式基于 Spring 提供的AbstractRoutingDataSource抽象類。它內(nèi)部維護(hù)一個目標(biāo)數(shù)據(jù)源的 Map通過determineCurrentLookupKey()方法動態(tài)決定當(dāng)前線程使用哪個數(shù)據(jù)源。配合 ThreadLocal 存儲數(shù)據(jù)源標(biāo)識就能實(shí)現(xiàn)運(yùn)行時的自由切換。我最終選的是方案二和方案三的結(jié)合基于AbstractRoutingDataSource做底層路由再封裝自定義注解和 AOP 切面做上層控制。這樣既能享受動態(tài)切換的靈活性又能通過注解讓業(yè)務(wù)代碼保持整潔。這也是目前大多數(shù)互聯(lián)網(wǎng)項目的通行做法如果你看過一些開源的多數(shù)據(jù)源框架比如dynamic-datasource-spring-boot-starter底層思路其實(shí)是一樣的。1.3 項目環(huán)境與版本信息做之前先把版本定下來避免后面掉進(jìn)版本兼容的坑里。我這次用的環(huán)境是組件版本JDK1.8SpringBoot2.3.7.RELEASEMyBatisPlus3.4.3.4MySQL5.7SqlServer2012Maven3.6.3這里提醒一句SpringBoot 版本別追太高。我見過有同事直接用 SpringBoot 3.x結(jié)果發(fā)現(xiàn)javax變成了jakarta很多老依賴都跑不起來。如果項目里還有歷史代碼建議先用 2.x 的穩(wěn)定版本把功能跑通。2. 靜態(tài)雙數(shù)據(jù)源配置從零開始接入 MySQL 和 SqlServer2.1 Maven 依賴引入的正確姿勢先把基礎(chǔ)依賴配好。除了 SpringBoot 和 MyBatisPlus 的常規(guī)依賴之外還需要把兩個數(shù)據(jù)庫的驅(qū)動都引進(jìn)來。這里有個容易踩的坑MySQL 驅(qū)動的 groupId 和 artifactId 在不同版本之間有變化mysql:mysql-connector-java是老坐標(biāo)com.mysql:mysql-connector-j是新坐標(biāo)別搞混了。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.4.3.4/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version5.1.49/version /dependency dependency groupIdcom.microsoft.sqlserver/groupId artifactIdmssql-jdbc/artifactId version9.4.1.jre8/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependencySqlServer 驅(qū)動的版本選擇有個細(xì)節(jié)。mssql-jdbc的版本號后綴jre8表示支持 Java 8如果你用的 JDK 是 1.8選帶這個后綴的版本最穩(wěn)妥。如果項目用 JDK 11 以上可以選不帶后綴或帶jre11的版本。2.2 application.yml 配置兩個數(shù)據(jù)源的參數(shù)化配置依賴配好后就是寫配置。我習(xí)慣把數(shù)據(jù)源信息放在application.yml里動態(tài)配置這樣不同環(huán)境之間切換只需要改配置文件不用動代碼。spring: datasource: mysql: driver-class-name: com.mysql.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/business_db?useUnicodetruecharacterEncodingutf-8useSSLfalse username: root password: root123 sqlserver: driver-class-name: com.microsoft.sqlserver.jdbc.SQLServerDriver jdbc-url: jdbc:sqlserver://192.168.1.100:1433;DatabaseNamehistory_db username: sa password: Sa123456注意這里的 key 是jdbc-url不是url。如果用urlSpringBoot 的自動配置會嘗試把它當(dāng)作默認(rèn)數(shù)據(jù)源來處理導(dǎo)致多數(shù)據(jù)源場景下的配置錯亂。這是我見過很多人踩過的坑寫的時候一定要看清。另外有個小細(xì)節(jié)每套數(shù)據(jù)源的driver-class-name必須明確指定不要依賴 SpringBoot 自動推斷。MySQL 8.0 以上版本驅(qū)動類名變成了com.mysql.cj.jdbc.Driver如果你用的是 8.x 驅(qū)動卻配了舊類名啟動時必報錯。2.3 數(shù)據(jù)源配置類手動裝配 SqlSessionFactory多數(shù)據(jù)源場景下需要手動創(chuàng)建數(shù)據(jù)源和SqlSessionFactory繞開 SpringBoot 的自動配置。這里以 MySQL 數(shù)據(jù)源為例Configuration public class DataSourceConfig { Bean(name mysqlDataSource) ConfigurationProperties(prefix spring.datasource.mysql) public DataSource mysqlDataSource() { return DataSourceBuilder.create().build(); } Bean(name sqlServerDataSource) ConfigurationProperties(prefix spring.datasource.sqlserver) public DataSource sqlServerDataSource() { return DataSourceBuilder.create().build(); } Bean(name dynamicDataSource) public DataSource dynamicDataSource() { DynamicDataSource dynamicDataSource new DynamicDataSource(); MapObject, Object dataSourceMap new HashMap(4); dataSourceMap.put(mysql, mysqlDataSource()); dataSourceMap.put(sqlserver, sqlServerDataSource()); dynamicDataSource.setTargetDataSources(dataSourceMap); dynamicDataSource.setDefaultTargetDataSource(mysqlDataSource()); return dynamicDataSource; } Bean(name sqlSessionFactory) public SqlSessionFactory sqlSessionFactory(Qualifier(dynamicDataSource) DataSource dynamicDataSource) throws Exception { MybatisSqlSessionFactoryBean sessionFactory new MybatisSqlSessionFactoryBean(); sessionFactory.setDataSource(dynamicDataSource); sessionFactory.setMapperLocations(new PathMatchingResourcePatternResolver() .getResources(classpath*:mapper/**/*.xml)); return sessionFactory.getObject(); } }這里有幾個關(guān)鍵點(diǎn)。第一MybatisSqlSessionFactoryBean用的是 MyBatisPlus 自帶的類不是 mybatis 原生的SqlSessionFactoryBean這樣才能讓 MyBatisPlus 的分頁插件、邏輯刪除等功能生效。第二mapperLocations用classpath*通配符這樣多個數(shù)據(jù)源的 Mapper XML 文件可以放在不同子目錄下避免路徑?jīng)_突。第三dynamicDataSource作為唯一的數(shù)據(jù)源注入到 MyBatis 里所以最終所有 Mapper 操作的入口都是動態(tài)數(shù)據(jù)源由它在內(nèi)部做轉(zhuǎn)發(fā)。3. 動態(tài)數(shù)據(jù)源實(shí)現(xiàn)核心類與 AOP 自動切換3.1 AbstractRoutingDataSourceSpring 預(yù)留的擴(kuò)展點(diǎn)AbstractRoutingDataSource是 Spring 提供的一個抽象類它的核心作用就是做一個路由分發(fā)。你可以把它理解成一個中轉(zhuǎn)站它自己不是一個真正意義上的數(shù)據(jù)庫連接池而是維護(hù)著一組目標(biāo)數(shù)據(jù)源每次獲取連接的時候通過抽象方法determineCurrentLookupKey()來決定應(yīng)該返回哪個真實(shí)數(shù)據(jù)源的連接。實(shí)現(xiàn)起來很簡單public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { return DataSourceContextHolder.getDataSourceKey(); } }關(guān)鍵是DataSourceContextHolder通常用 ThreadLocal 實(shí)現(xiàn)public class DataSourceContextHolder { private static final ThreadLocalString CONTEXT new ThreadLocal(); public static void setDataSourceKey(String dataSourceKey) { CONTEXT.set(dataSourceKey); } public static String getDataSourceKey() { return CONTEXT.get(); } public static void clear() { CONTEXT.remove(); } }為什么必須用 ThreadLocal因為 Spring 的DataSourceUtils在獲取連接的時候會先看當(dāng)前事務(wù)上下文里是否已有連接如果有就直接復(fù)用。ThreadLocal 能保證同一線程內(nèi)數(shù)據(jù)源切換在當(dāng)前線程內(nèi)是隔離的不會影響其他線程。但這也引出一個隱患——線程池復(fù)用問題后面我會在踩坑部分詳細(xì)說。3.2 自定義注解 DataSource光有路由還不夠得讓業(yè)務(wù)代碼能方便地指定數(shù)據(jù)源。我定義了一個注解Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) Documented public interface DataSource { String value() default mysql; }這個注解可以標(biāo)注在 Service 方法上也可以標(biāo)注在類上。標(biāo)注在類上表示整個類的所有方法默認(rèn)走某個數(shù)據(jù)源標(biāo)注在方法上則覆蓋類級別的配置。一個是粗粒度一個是細(xì)粒度兩者結(jié)合使用起來非常靈活。3.3 AOP 切面方法執(zhí)行前自動切換核心切面邏輯如下Aspect Component Order(1) public class DataSourceAspect { Pointcut(annotation(com.example.annotation.DataSource) || within(com.example.annotation.DataSource)) public void dataSourcePointCut() {} Before(dataSourcePointCut()) public void doBefore(JoinPoint joinPoint) { MethodSignature signature (MethodSignature) joinPoint.getSignature(); Method method signature.getMethod(); DataSource dataSource method.getAnnotation(DataSource.class); if (dataSource null) { dataSource joinPoint.getTarget().getClass().getAnnotation(DataSource.class); } if (dataSource ! null) { DataSourceContextHolder.setDataSourceKey(dataSource.value()); } } After(dataSourcePointCut()) public void doAfter(JoinPoint joinPoint) { DataSourceContextHolder.clear(); } }切面的Order(1)很重要。如果項目里同時有事務(wù)切面必須保證數(shù)據(jù)源切面的優(yōu)先級高于事務(wù)切面。原因在于Spring 的事務(wù)管理在開啟事務(wù)時就要確定使用哪個數(shù)據(jù)源如果事務(wù)切面先執(zhí)行它拿到的還是默認(rèn)數(shù)據(jù)源后面的切換就白做了。切面邏輯里有個細(xì)節(jié)within是用來匹配類級別注解的。我的切點(diǎn)同時寫了annotation和within這樣能兼顧方法級和類級的注解配置避免在使用類級注解時切面不生效的問題。4. 實(shí)操踩坑實(shí)錄MyBatisPlus 配合多數(shù)據(jù)源的高頻問題4.1 分頁插件配置問題單頁 500 條限制的真相先說說 MyBatisPlus 分頁的事。很多人在網(wǎng)上搜到MyBatisPlus 單頁 500 條限制其實(shí)這并不是框架硬編碼的限制而是分頁插件配置不到位導(dǎo)致的。老版本的 MyBatisPlus 分頁插件默認(rèn)有l(wèi)imit保護(hù)不配置的話某些版本會限制單頁查詢條數(shù)。正確配置方式是在 MyBatisPlus 的配置類里添加分頁插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor paginationInnerInterceptor new PaginationInnerInterceptor(); paginationInnerInterceptor.setMaxLimit(500L); paginationInnerInterceptor.setOverflow(false); interceptor.addInnerInterceptor(paginationInnerInterceptor); return interceptor; } }這里setMaxLimit(500L)就是網(wǎng)上說的單頁 500 限制的源頭。如果不希望限制單頁大小可以把這個值設(shè)大或者不設(shè)置。但我要提醒一句這個限制其實(shí)是好心防止有人寫LIMIT 1000000這種查詢把數(shù)據(jù)庫打掛。生產(chǎn)環(huán)境建議保留只是結(jié)合實(shí)際業(yè)務(wù)把閾值調(diào)到一個合理的值。另外一個更隱蔽的問題是在多數(shù)據(jù)源場景下MySQL 和 SqlServer 的分頁語法不一樣。MySQL 用LIMIT ? OFFSETSqlServer 2012 以上用OFFSET ? ROWS FETCH NEXT ? ROWS ONLY。如果只給 MyBatisPlus 配置了 MySQL 方言的分頁插件切到 SqlServer 后分頁邏輯就會出錯。好在 MyBatisPlus 的PaginationInnerInterceptor是支持多方言的它會根據(jù)當(dāng)前數(shù)據(jù)源的類型自動選擇合適的方言。但這要求你的多個數(shù)據(jù)源必須都注冊到同一個 MyBatis 環(huán)境里而不能拆成多個SqlSessionFactory否則多方言識別就失效了。4.2 關(guān)鍵字沖突表名和字段名的那些坑SqlServer 有一些保留關(guān)鍵字是 MySQL 里可以隨便用的比如order、user、group、index等。我在項目里就碰到過一張 SqlServer 的歷史表字段名叫index在 MySQL 里這個字段名完全合法在 SqlServer 里必須加方括號才能查。MyBatisPlus 提供了全局的關(guān)鍵字自動轉(zhuǎn)義開關(guān)mybatis-plus: global-config: db-config: column-format: %s但這個配置只對 MySQL 的反引號有效。如果同時操作 SqlServer反引號就不認(rèn)了。更穩(wěn)妥的做法是在實(shí)體類的TableField注解上手動指定別名TableField(index) private Integer index;如果是 SqlServer需要寫成TableField([index]) private Integer index;這種問題防不勝防尤其是接手老數(shù)據(jù)庫的時候。我的建議是先用工具連上 SqlServer把涉及的表結(jié)構(gòu)和字段整體瀏覽一遍建一個關(guān)鍵字清單寫 Mapper 的時候?qū)φ罩幚韯e等到運(yùn)行時報錯了再回頭一個個查。4.3 事務(wù)與數(shù)據(jù)源切換的沖突這個坑非常典型。場景是這樣的有一個方法需要先查 SqlServer 的數(shù)據(jù)再做業(yè)務(wù)處理最后寫 MySQL。一開始我直接在方法上加了Transactional然后通過 AOP 切數(shù)據(jù)源結(jié)果發(fā)現(xiàn)第二個操作還是走的老數(shù)據(jù)源。原因一句話說清楚事務(wù)開啟時數(shù)據(jù)源就已經(jīng)固定了。Transactional是在方法進(jìn)入前就通過事務(wù)管理器獲取了連接后續(xù)的數(shù)據(jù)源切換只是在DataSourceContextHolder里改了 ThreadLocal 的值但事務(wù)上下文里持有的連接還是老數(shù)據(jù)源的那個切不過去。解決辦法有這么幾種第一種業(yè)務(wù)允許的情況下把跨數(shù)據(jù)源的操作拆成兩個方法分別加事務(wù)通過調(diào)用另一個 Service 的方法來完成。這是最省事的辦法。第二種使用分布式事務(wù)方案比如 Seata、Atomikos但引入成本較高小項目沒必要。第三種也是最常用的用編程式事務(wù)替代聲明式事務(wù)Autowired private TransactionTemplate transactionTemplate; public void crossDataSourceOperation() { DataSourceContextHolder.setDataSourceKey(sqlserver); Object result queryFromSqlServer(); DataSourceContextHolder.clear(); transactionTemplate.execute(status - { DataSourceContextHolder.setDataSourceKey(mysql); try { insertToMysql(result); return true; } catch (Exception e) { status.setRollbackOnly(); throw e; } finally { DataSourceContextHolder.clear(); } }); }這樣每個數(shù)據(jù)源的操作在自己的事務(wù)模板里管理互不干擾。但跨數(shù)據(jù)源的數(shù)據(jù)一致性就只能靠業(yè)務(wù)補(bǔ)償來保證了這也是多數(shù)據(jù)源方案天然的限制。4.4 連接池配置多個數(shù)據(jù)源各自為戰(zhàn)連接池這塊也容易出問題。默認(rèn)情況下SpringBoot 2.x 會使用 HikariCP 作為連接池。多數(shù)據(jù)源時每個數(shù)據(jù)源應(yīng)該有自己的連接池配置避免共用一個連接池導(dǎo)致連接耗盡。spring: datasource: mysql: hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000 sqlserver: hikari: minimum-idle: 3 maximum-pool-size: 10 connection-timeout: 15000SqlServer 的連接池大小不用配得跟 MySQL 一樣大。因為 SqlServer 在老系統(tǒng)里主要用于查詢歷史數(shù)據(jù)并發(fā)量相對較低配小一點(diǎn)可以節(jié)省資源。同理超時時間也可以設(shè)置短一些避免 SqlServer 響應(yīng)慢的時候拖垮應(yīng)用線程。4.5 SqlServer 排序規(guī)則沖突問題網(wǎng)上有個熱詞是sqlserver cannot resolve the collation conflict翻譯過來就是排序規(guī)則沖突。這個問題出現(xiàn)在 SqlServer 的臨時表關(guān)聯(lián)查詢時如果兩個表的排序規(guī)則比如Chinese_PRC_CI_AS和SQL_Latin1_General_CP1_CI_AS不一致關(guān)聯(lián)查詢會報錯。在多數(shù)據(jù)源場景下如果我們從 MySQL 同步數(shù)據(jù)到 SqlServer再臨時建表去關(guān)聯(lián)歷史表很容易觸發(fā)這個問題。解決辦法是建臨時表時顯式指定排序規(guī)則CREATE TABLE #temp_table ( user_name NVARCHAR(50) COLLATE Chinese_PRC_CI_AS )或者在關(guān)聯(lián)時用COLLATE強(qiáng)制指定SELECT * FROM table_a a INNER JOIN table_b b ON a.name b.name COLLATE Chinese_PRC_CI_AS這個坑可能隱藏得比較深我遇到過因為排序規(guī)則不一致導(dǎo)致的慢查詢排查了很久才發(fā)現(xiàn)是隱式轉(zhuǎn)換導(dǎo)致索引失效。4.6 SqlServer 字符串轉(zhuǎn)數(shù)字多數(shù)據(jù)源下的數(shù)據(jù)類型兼容SqlServer 里把字符串轉(zhuǎn)數(shù)字常用CAST或CONVERTSELECT CAST(123 AS INT) SELECT CONVERT(INT, 123)MySQL 則用CAST(123 AS SIGNED)或者直接123 0。如果項目里有共用 Mapper XML不同數(shù)據(jù)庫的轉(zhuǎn)換語法就得分別寫不能混用。我的做法是把這類數(shù)據(jù)庫相關(guān)的 SQL 拆到各自的 Mapper 里通過數(shù)據(jù)源切換來保證執(zhí)行正確。另外要注意 SqlServer 的CAST轉(zhuǎn)換失敗會直接報錯不像 MySQL 在某些模式下會有寬松處理。生產(chǎn)環(huán)境如果遇到臟數(shù)據(jù)字符串里有空格或特殊字符轉(zhuǎn)換就會炸。建議先用ISNUMERIC判斷一下SELECT CASE WHEN ISNUMERIC(column_name) 1 THEN CAST(column_name AS INT) ELSE 0 END FROM table_name5. 多數(shù)據(jù)源方案驗證與優(yōu)化建議5.1 單元測試怎么寫才靠譜數(shù)據(jù)源切換這種邏輯一定要寫測試驗證不能等上線了再看效果。我用 SpringBootTest 寫了幾組測試用例覆蓋不同場景的切換邏輯。SpringBootTest RunWith(SpringRunner.class) public class DataSourceSwitchTest { Autowired private UserService userService; Test public void testQueryMysqlUser() { User user userService.getUserFromMysql(1L); Assert.assertNotNull(user); } Test public void testQuerySqlServerUser() { User user userService.getUserFromSqlServer(100L); Assert.assertNotNull(user); } Test public void testSwitchBetweenDataSources() { User mysqlUser userService.getUserFromMysql(1L); User sqlServerUser userService.getUserFromSqlServer(100L); Assert.assertNotNull(mysqlUser); Assert.assertNotNull(sqlServerUser); } }注意測試方法的執(zhí)行順序。JUnit 默認(rèn)的方法執(zhí)行順序是不固定的如果測試類里多個方法都在切換數(shù)據(jù)源ThreadLocal 里的值可能在方法結(jié)束后由After清理一般不會互相影響。但如果某些測試并發(fā)執(zhí)行異常可能會出現(xiàn)數(shù)據(jù)源串了的情況。穩(wěn)妥起見每個測試方法都從默認(rèn)狀態(tài)開始不依賴前一個方法的執(zhí)行結(jié)果。5.2 多數(shù)據(jù)源下的性能優(yōu)化多數(shù)據(jù)源不只是配置問題性能同樣要關(guān)注。幾個實(shí)測經(jīng)驗第一連接池參數(shù)要分別調(diào)優(yōu)。MySQL 作為主庫讀寫頻繁最大連接數(shù)可以設(shè)置得高一些SqlServer 作為輔助庫查詢量大但并發(fā)不高連接數(shù)可以少一些。第二跨數(shù)據(jù)源的循環(huán)查詢要避免。比如先查 SqlServer 拿到 1000 條記錄然后再循環(huán)查 MySQL 補(bǔ)充信息這種寫法性能極差。正確做法是把 SqlServer 查出來的 ID 集合一次性傳給 MySQL用IN查詢批量處理。第三如果查詢的數(shù)據(jù)量比較大利用好索引。SqlServer 老表的索引往往不夠優(yōu)化必要時可以創(chuàng)建覆蓋索引來加速常用查詢。但 DDL 操作要謹(jǐn)慎避免高峰期執(zhí)行。5.3 從 MyBatis 到 MyBatisPlus 的兼容保障項目里既有 MyBatis 的 XML 寫法也有 MyBatisPlus 的 Wrapper 寫法。多數(shù)據(jù)源下這兩種寫法都需要保證切換正常。我踩過的一個坑是在某個自定義 SQL 里用了${ew.customSqlSegment}結(jié)果 MyBatisPlus 的多表查詢沒有自動帶上數(shù)據(jù)源切換邏輯導(dǎo)致部分?jǐn)?shù)據(jù)查不到。這個問題的根源在于MyBatisPlus 的 Wrapper 條件構(gòu)造器在生成 SQL 時對IN類型的條件會有數(shù)量限制的優(yōu)化邏輯。對于超過 1000 條的IN查詢MyBatisPlus 會做拆分處理但這個拆分后的 SQL 執(zhí)行順序可能與數(shù)據(jù)源切換順序不一致。解決方案是手動把IN查詢拆分為多個小批次避免單條 SQL 過大。另外如果要在 MyBatisPlus 中使用自定義 SQL 并拼接 Wrapper建議用${ew.customSqlSegment}時注意轉(zhuǎn)義問題尤其是字段名包含關(guān)鍵字時要在注解或 XML 里確認(rèn)最終 SQL 的正確性。6. 常見問題速查表與排查技巧6.1 問題匯總癥狀可能原因解決辦法啟動報DataSource循環(huán)依賴多個數(shù)據(jù)源的 Bean 互相引用用Primary指定主數(shù)據(jù)源或在配置類中通過Qualifier明確注入切換數(shù)據(jù)源不生效AOP 切面沒有攔截到方法確認(rèn)自定義注解是否標(biāo)在 Service 方法上Order(1)是否配置事務(wù)方法內(nèi)切換數(shù)據(jù)源失敗事務(wù)開啟時連接已鎖定拆分方法或使用編程式事務(wù)SqlServer 查詢報錯字段名是保留字用方括號括起來MyBatisPlus 分頁在 SqlServer 下失效方言識別失敗PaginationInnerInterceptor注冊后確認(rèn)多數(shù)據(jù)源共享同一個SqlSessionFactory連接池報Connection is not available連接泄露或配置過小檢查連接池配置用SELECT * FROM sys.dm_exec_connections之類的語句排查6.2 排查思路與調(diào)試技巧多數(shù)據(jù)源問題排查第一步永遠(yuǎn)是確認(rèn)當(dāng)前線程的數(shù)據(jù)源是什么。我一般在DataSourceAspect里加一行日志log.info(switch datasource to{}, dataSource.value());然后觀察日志輸出是否與預(yù)期一致。如果日志顯示已切換但查詢還是走的老庫那問題大概率出在事務(wù)上如果日志都沒打印那就是 AOP 切面沒起作用需要檢查注解位置和 Spring 掃描路徑。第二個技巧是打開 HikariCP 的連接獲取日志通過監(jiān)控連接池的活動情況來判斷數(shù)據(jù)源是否正確。在application.yml里配置logging: level: com.zaxxer.hikari: DEBUG這樣可以看到每次獲取連接來自哪個數(shù)據(jù)源、連接池的活躍數(shù)是多少對定位連接泄露和切換異常都很有幫助。第三個技巧是查看 MyBatis 的執(zhí)行日志。MyBatisPlus 提供了 SQL 輸出日志可以配置輸出 SQL 內(nèi)容確認(rèn)執(zhí)行的 SQL 語句是否符合當(dāng)前數(shù)據(jù)源的方言。如果 SQL 語法是 MySQL 的但執(zhí)行到了 SqlServer 上基本可以斷定是數(shù)據(jù)源切換出了問題。6.3 后續(xù)擴(kuò)展動態(tài)加數(shù)據(jù)源、分布式事務(wù)如果項目后續(xù)要接入更多數(shù)據(jù)源比如再加一個 PostgreSQL只需要在DataSourceConfig中添加一個新的數(shù)據(jù)源 Bean然后在dynamicDataSource中把它put進(jìn)targetDataSources即可。但要注意如果數(shù)據(jù)源是運(yùn)行時動態(tài)增加的比如多租戶場景需要調(diào)用AbstractRoutingDataSource的afterPropertiesSet()方法來刷新配置。分布式事務(wù)是個更深的話題。如果業(yè)務(wù)上真的需要跨庫的強(qiáng)一致性比如一個操作既要寫 MySQL 又要寫 SqlServer多數(shù)據(jù)源方案已經(jīng)解決不了問題了得引入分布式事務(wù)中間件。我的建議是盡早評估業(yè)務(wù)場景如果只是簡單的查詢和異步補(bǔ)償多數(shù)據(jù)源方案完全夠用如果要做強(qiáng)一致的跨庫寫操作提前設(shè)計好技術(shù)選型不要等寫完了再返工。我在實(shí)際項目中的體會是多數(shù)據(jù)源本身并不復(fù)雜復(fù)雜的永遠(yuǎn)是業(yè)務(wù)邊界和異常處理。動手之前先想清楚哪個庫是主、哪個庫是輔在代碼層面規(guī)定好數(shù)據(jù)源的使用規(guī)范比什么花哨的框架都重要。最后再分享一個平時容易忽略的小細(xì)節(jié)如果你的項目在部署時切換了環(huán)境記得檢查數(shù)據(jù)庫連接串和賬號權(quán)限我遇到過多次因為新環(huán)境 SqlServer 登錄賬號缺少VIEW SERVER STATE權(quán)限導(dǎo)致連接池初始化異常的案例這類問題一般不報錯清楚排查起來比較費(fèi)勁提前做好環(huán)境檢查能省不少事。