1. 項(xiàng)目背景與多數(shù)據(jù)源需求拆解1.1 為什么一個(gè)項(xiàng)目會(huì)同時(shí)連上 MySQL 和 SqlServer在實(shí)際業(yè)務(wù)里一套服務(wù)對(duì)接多個(gè)數(shù)據(jù)庫的需求比想象中要普遍。我這次遇到的項(xiàng)目就是一個(gè)典型的傳統(tǒng)行業(yè)改造場(chǎng)景老系統(tǒng)跑在 SqlServer 上沉淀了十多年的歷史數(shù)據(jù)包括訂單流水、人員檔案、流程審批記錄這些數(shù)據(jù)不能說丟就丟也不可能短期內(nèi)做完整遷移。而新開發(fā)的業(yè)務(wù)模塊比如用戶畫像、消息推送、數(shù)據(jù)分析報(bào)表則更適合放到 MySQL 里畢竟這套技術(shù)棧更輕量生態(tài)也更活躍團(tuán)隊(duì)維護(hù)起來成本更低。項(xiàng)目要求很直白同一個(gè) SpringBoot 服務(wù)里既要能查 SqlServer 里的歷史數(shù)據(jù)又要能讀寫 MySQL 里的新業(yè)務(wù)數(shù)據(jù)還得保證切換過程對(duì)業(yè)務(wù)代碼盡可能透明。翻譯成技術(shù)語言就是要在 MyBatisPlus 這套 ORM 框架下實(shí)現(xiàn)多數(shù)據(jù)源接入和動(dòng)態(tài)切換。這里先說明一個(gè)容易混淆的概念。多數(shù)據(jù)源和讀寫分離是兩回事。讀寫分離是同一個(gè)數(shù)據(jù)庫的主從副本結(jié)構(gòu)完全一致只是分擔(dān)讀寫的壓力。多數(shù)據(jù)源則是多個(gè)獨(dú)立的數(shù)據(jù)庫實(shí)例結(jié)構(gòu)可能完全不同甚至數(shù)據(jù)庫類型都不一樣——MySQL 和 SqlServer 在 SQL 語法、分頁方式、數(shù)據(jù)類型上都有差異。本次項(xiàng)目屬于后者難點(diǎn)在于不是簡(jiǎn)單配兩個(gè)連接池就完事而是要讓上層業(yè)務(wù)代碼在幾乎無感知的情況下完成數(shù)據(jù)源的切換。1.2 方案選型對(duì)比分包、AOP切面還是動(dòng)態(tài)路由多數(shù)據(jù)源的實(shí)現(xiàn)方案業(yè)界主流有幾種我簡(jiǎn)單梳理一下方便大家對(duì)照自己的場(chǎng)景選型。第一種叫分包方式也是最古老的做法。按照包名區(qū)分 dao 層接口比如com.example.mapper.mysql下的走 MySQL 數(shù)據(jù)源com.example.mapper.sqlserver下的走 SqlServer 數(shù)據(jù)源。每個(gè)數(shù)據(jù)源配置獨(dú)立的SqlSessionFactory各管各的包互不干擾。優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單、邏輯清晰問題是有多少數(shù)據(jù)源就要配置多少套 MyBatis 環(huán)境代碼一多維護(hù)成本就上來了而且一旦出現(xiàn)跨庫業(yè)務(wù)就得寫多套 Mapper 去拼裝數(shù)據(jù)。第二種是 AOP 自定義注解的方式。核心思路是定義一個(gè)DataSource注解標(biāo)注在 Service 或 Mapper 方法上通過切面在方法執(zhí)行前動(dòng)態(tài)切換數(shù)據(jù)源執(zhí)行完再切回來。這種方式靈活度高可以做到按方法粒度控制數(shù)據(jù)源而且改造量相對(duì)小只要在需要切換的方法上加個(gè)注解就行。第三種是動(dòng)態(tài)路由方式基于 Spring 提供的AbstractRoutingDataSource抽象類。它內(nèi)部維護(hù)一個(gè)目標(biāo)數(shù)據(jù)源的 Map通過determineCurrentLookupKey()方法動(dòng)態(tài)決定當(dāng)前線程使用哪個(gè)數(shù)據(jù)源。配合 ThreadLocal 存儲(chǔ)數(shù)據(jù)源標(biāo)識(shí)就能實(shí)現(xiàn)運(yùn)行時(shí)的自由切換。我最終選的是方案二和方案三的結(jié)合基于AbstractRoutingDataSource做底層路由再封裝自定義注解和 AOP 切面做上層控制。這樣既能享受動(dòng)態(tài)切換的靈活性又能通過注解讓業(yè)務(wù)代碼保持整潔。這也是目前大多數(shù)互聯(lián)網(wǎng)項(xiàng)目的通行做法如果你看過一些開源的多數(shù)據(jù)源框架比如dynamic-datasource-spring-boot-starter底層思路其實(shí)是一樣的。1.3 項(xiàng)目環(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很多老依賴都跑不起來。如果項(xiàng)目里還有歷史代碼建議先用 2.x 的穩(wěn)定版本把功能跑通。2. 靜態(tài)雙數(shù)據(jù)源配置從零開始接入 MySQL 和 SqlServer2.1 Maven 依賴引入的正確姿勢(shì)先把基礎(chǔ)依賴配好。除了 SpringBoot 和 MyBatisPlus 的常規(guī)依賴之外還需要把兩個(gè)數(shù)據(jù)庫的驅(qū)動(dòng)都引進(jìn)來。這里有個(gè)容易踩的坑MySQL 驅(qū)動(dòng)的 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ū)動(dòng)的版本選擇有個(gè)細(xì)節(jié)。mssql-jdbc的版本號(hào)后綴jre8表示支持 Java 8如果你用的 JDK 是 1.8選帶這個(gè)后綴的版本最穩(wěn)妥。如果項(xiàng)目用 JDK 11 以上可以選不帶后綴或帶jre11的版本。2.2 application.yml 配置兩個(gè)數(shù)據(jù)源的參數(shù)化配置依賴配好后就是寫配置。我習(xí)慣把數(shù)據(jù)源信息放在application.yml里動(dòng)態(tài)配置這樣不同環(huán)境之間切換只需要改配置文件不用動(dòng)代碼。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)配置會(huì)嘗試把它當(dāng)作默認(rèn)數(shù)據(jù)源來處理導(dǎo)致多數(shù)據(jù)源場(chǎng)景下的配置錯(cuò)亂。這是我見過很多人踩過的坑寫的時(shí)候一定要看清。另外有個(gè)小細(xì)節(jié)每套數(shù)據(jù)源的driver-class-name必須明確指定不要依賴 SpringBoot 自動(dòng)推斷。MySQL 8.0 以上版本驅(qū)動(dòng)類名變成了com.mysql.cj.jdbc.Driver如果你用的是 8.x 驅(qū)動(dòng)卻配了舊類名啟動(dòng)時(shí)必報(bào)錯(cuò)。2.3 數(shù)據(jù)源配置類手動(dòng)裝配 SqlSessionFactory多數(shù)據(jù)源場(chǎng)景下需要手動(dòng)創(chuàng)建數(shù)據(jù)源和SqlSessionFactory繞開 SpringBoot 的自動(dòng)配置。這里以 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(); } }這里有幾個(gè)關(guān)鍵點(diǎn)。第一MybatisSqlSessionFactoryBean用的是 MyBatisPlus 自帶的類不是 mybatis 原生的SqlSessionFactoryBean這樣才能讓 MyBatisPlus 的分頁插件、邏輯刪除等功能生效。第二mapperLocations用classpath*通配符這樣多個(gè)數(shù)據(jù)源的 Mapper XML 文件可以放在不同子目錄下避免路徑?jīng)_突。第三dynamicDataSource作為唯一的數(shù)據(jù)源注入到 MyBatis 里所以最終所有 Mapper 操作的入口都是動(dòng)態(tài)數(shù)據(jù)源由它在內(nèi)部做轉(zhuǎn)發(fā)。3. 動(dòng)態(tài)數(shù)據(jù)源實(shí)現(xiàn)核心類與 AOP 自動(dòng)切換3.1 AbstractRoutingDataSourceSpring 預(yù)留的擴(kuò)展點(diǎn)AbstractRoutingDataSource是 Spring 提供的一個(gè)抽象類它的核心作用就是做一個(gè)路由分發(fā)。你可以把它理解成一個(gè)中轉(zhuǎn)站它自己不是一個(gè)真正意義上的數(shù)據(jù)庫連接池而是維護(hù)著一組目標(biāo)數(shù)據(jù)源每次獲取連接的時(shí)候通過抽象方法determineCurrentLookupKey()來決定應(yīng)該返回哪個(gè)真實(shí)數(shù)據(jù)源的連接。實(shí)現(xiàn)起來很簡(jiǎ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因?yàn)?Spring 的DataSourceUtils在獲取連接的時(shí)候會(huì)先看當(dāng)前事務(wù)上下文里是否已有連接如果有就直接復(fù)用。ThreadLocal 能保證同一線程內(nèi)數(shù)據(jù)源切換在當(dāng)前線程內(nèi)是隔離的不會(huì)影響其他線程。但這也引出一個(gè)隱患——線程池復(fù)用問題后面我會(huì)在踩坑部分詳細(xì)說。3.2 自定義注解 DataSource光有路由還不夠得讓業(yè)務(wù)代碼能方便地指定數(shù)據(jù)源。我定義了一個(gè)注解Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) Documented public interface DataSource { String value() default mysql; }這個(gè)注解可以標(biāo)注在 Service 方法上也可以標(biāo)注在類上。標(biāo)注在類上表示整個(gè)類的所有方法默認(rèn)走某個(gè)數(shù)據(jù)源標(biāo)注在方法上則覆蓋類級(jí)別的配置。一個(gè)是粗粒度一個(gè)是細(xì)粒度兩者結(jié)合使用起來非常靈活。3.3 AOP 切面方法執(zhí)行前自動(dòng)切換核心切面邏輯如下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)很重要。如果項(xiàng)目里同時(shí)有事務(wù)切面必須保證數(shù)據(jù)源切面的優(yōu)先級(jí)高于事務(wù)切面。原因在于Spring 的事務(wù)管理在開啟事務(wù)時(shí)就要確定使用哪個(gè)數(shù)據(jù)源如果事務(wù)切面先執(zhí)行它拿到的還是默認(rèn)數(shù)據(jù)源后面的切換就白做了。切面邏輯里有個(gè)細(xì)節(jié)within是用來匹配類級(jí)別注解的。我的切點(diǎn)同時(shí)寫了annotation和within這樣能兼顧方法級(jí)和類級(jí)的注解配置避免在使用類級(jí)注解時(shí)切面不生效的問題。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ù)不配置的話某些版本會(huì)限制單頁查詢條數(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 限制的源頭。如果不希望限制單頁大小可以把這個(gè)值設(shè)大或者不設(shè)置。但我要提醒一句這個(gè)限制其實(shí)是好心防止有人寫LIMIT 1000000這種查詢把數(shù)據(jù)庫打掛。生產(chǎn)環(huán)境建議保留只是結(jié)合實(shí)際業(yè)務(wù)把閾值調(diào)到一個(gè)合理的值。另外一個(gè)更隱蔽的問題是在多數(shù)據(jù)源場(chǎng)景下MySQL 和 SqlServer 的分頁語法不一樣。MySQL 用LIMIT ? OFFSETSqlServer 2012 以上用OFFSET ? ROWS FETCH NEXT ? ROWS ONLY。如果只給 MyBatisPlus 配置了 MySQL 方言的分頁插件切到 SqlServer 后分頁邏輯就會(huì)出錯(cuò)。好在 MyBatisPlus 的PaginationInnerInterceptor是支持多方言的它會(huì)根據(jù)當(dāng)前數(shù)據(jù)源的類型自動(dòng)選擇合適的方言。但這要求你的多個(gè)數(shù)據(jù)源必須都注冊(cè)到同一個(gè) MyBatis 環(huán)境里而不能拆成多個(gè)SqlSessionFactory否則多方言識(shí)別就失效了。4.2 關(guān)鍵字沖突表名和字段名的那些坑SqlServer 有一些保留關(guān)鍵字是 MySQL 里可以隨便用的比如order、user、group、index等。我在項(xiàng)目里就碰到過一張 SqlServer 的歷史表字段名叫index在 MySQL 里這個(gè)字段名完全合法在 SqlServer 里必須加方括號(hào)才能查。MyBatisPlus 提供了全局的關(guān)鍵字自動(dòng)轉(zhuǎn)義開關(guān)mybatis-plus: global-config: db-config: column-format: %s但這個(gè)配置只對(duì) MySQL 的反引號(hào)有效。如果同時(shí)操作 SqlServer反引號(hào)就不認(rèn)了。更穩(wěn)妥的做法是在實(shí)體類的TableField注解上手動(dòng)指定別名TableField(index) private Integer index;如果是 SqlServer需要寫成TableField([index]) private Integer index;這種問題防不勝防尤其是接手老數(shù)據(jù)庫的時(shí)候。我的建議是先用工具連上 SqlServer把涉及的表結(jié)構(gòu)和字段整體瀏覽一遍建一個(gè)關(guān)鍵字清單寫 Mapper 的時(shí)候?qū)φ罩幚韯e等到運(yùn)行時(shí)報(bào)錯(cuò)了再回頭一個(gè)個(gè)查。4.3 事務(wù)與數(shù)據(jù)源切換的沖突這個(gè)坑非常典型。場(chǎng)景是這樣的有一個(gè)方法需要先查 SqlServer 的數(shù)據(jù)再做業(yè)務(wù)處理最后寫 MySQL。一開始我直接在方法上加了Transactional然后通過 AOP 切數(shù)據(jù)源結(jié)果發(fā)現(xiàn)第二個(gè)操作還是走的老數(shù)據(jù)源。原因一句話說清楚事務(wù)開啟時(shí)數(shù)據(jù)源就已經(jīng)固定了。Transactional是在方法進(jìn)入前就通過事務(wù)管理器獲取了連接后續(xù)的數(shù)據(jù)源切換只是在DataSourceContextHolder里改了 ThreadLocal 的值但事務(wù)上下文里持有的連接還是老數(shù)據(jù)源的那個(gè)切不過去。解決辦法有這么幾種第一種業(yè)務(wù)允許的情況下把跨數(shù)據(jù)源的操作拆成兩個(gè)方法分別加事務(wù)通過調(diào)用另一個(gè) Service 的方法來完成。這是最省事的辦法。第二種使用分布式事務(wù)方案比如 Seata、Atomikos但引入成本較高小項(xiàng)目沒必要。第三種也是最常用的用編程式事務(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(); } }); }這樣每個(gè)數(shù)據(jù)源的操作在自己的事務(wù)模板里管理互不干擾。但跨數(shù)據(jù)源的數(shù)據(jù)一致性就只能靠業(yè)務(wù)補(bǔ)償來保證了這也是多數(shù)據(jù)源方案天然的限制。4.4 連接池配置多個(gè)數(shù)據(jù)源各自為戰(zhàn)連接池這塊也容易出問題。默認(rèn)情況下SpringBoot 2.x 會(huì)使用 HikariCP 作為連接池。多數(shù)據(jù)源時(shí)每個(gè)數(shù)據(jù)源應(yīng)該有自己的連接池配置避免共用一個(gè)連接池導(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 一樣大。因?yàn)?SqlServer 在老系統(tǒng)里主要用于查詢歷史數(shù)據(jù)并發(fā)量相對(duì)較低配小一點(diǎn)可以節(jié)省資源。同理超時(shí)時(shí)間也可以設(shè)置短一些避免 SqlServer 響應(yīng)慢的時(shí)候拖垮應(yīng)用線程。4.5 SqlServer 排序規(guī)則沖突問題網(wǎng)上有個(gè)熱詞是sqlserver cannot resolve the collation conflict翻譯過來就是排序規(guī)則沖突。這個(gè)問題出現(xiàn)在 SqlServer 的臨時(shí)表關(guān)聯(lián)查詢時(shí)如果兩個(gè)表的排序規(guī)則比如Chinese_PRC_CI_AS和SQL_Latin1_General_CP1_CI_AS不一致關(guān)聯(lián)查詢會(huì)報(bào)錯(cuò)。在多數(shù)據(jù)源場(chǎng)景下如果我們從 MySQL 同步數(shù)據(jù)到 SqlServer再臨時(shí)建表去關(guān)聯(lián)歷史表很容易觸發(fā)這個(gè)問題。解決辦法是建臨時(shí)表時(shí)顯式指定排序規(guī)則CREATE TABLE #temp_table ( user_name NVARCHAR(50) COLLATE Chinese_PRC_CI_AS )或者在關(guān)聯(lián)時(shí)用COLLATE強(qiáng)制指定SELECT * FROM table_a a INNER JOIN table_b b ON a.name b.name COLLATE Chinese_PRC_CI_AS這個(gè)坑可能隱藏得比較深我遇到過因?yàn)榕判蛞?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。如果項(xiàng)目里有共用 Mapper XML不同數(shù)據(jù)庫的轉(zhuǎn)換語法就得分別寫不能混用。我的做法是把這類數(shù)據(jù)庫相關(guān)的 SQL 拆到各自的 Mapper 里通過數(shù)據(jù)源切換來保證執(zhí)行正確。另外要注意 SqlServer 的CAST轉(zhuǎn)換失敗會(huì)直接報(bào)錯(cuò)不像 MySQL 在某些模式下會(huì)有寬松處理。生產(chǎn)環(huán)境如果遇到臟數(shù)據(jù)字符串里有空格或特殊字符轉(zhuǎn)換就會(huì)炸。建議先用ISNUMERIC判斷一下SELECT CASE WHEN ISNUMERIC(column_name) 1 THEN CAST(column_name AS INT) ELSE 0 END FROM table_name5. 多數(shù)據(jù)源方案驗(yàn)證與優(yōu)化建議5.1 單元測(cè)試怎么寫才靠譜數(shù)據(jù)源切換這種邏輯一定要寫測(cè)試驗(yàn)證不能等上線了再看效果。我用 SpringBootTest 寫了幾組測(cè)試用例覆蓋不同場(chǎng)景的切換邏輯。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); } }注意測(cè)試方法的執(zhí)行順序。JUnit 默認(rèn)的方法執(zhí)行順序是不固定的如果測(cè)試類里多個(gè)方法都在切換數(shù)據(jù)源ThreadLocal 里的值可能在方法結(jié)束后由After清理一般不會(huì)互相影響。但如果某些測(cè)試并發(fā)執(zhí)行異?？赡軙?huì)出現(xiàn)數(shù)據(jù)源串了的情況。穩(wěn)妥起見每個(gè)測(cè)試方法都從默認(rèn)狀態(tài)開始不依賴前一個(gè)方法的執(zhí)行結(jié)果。5.2 多數(shù)據(jù)源下的性能優(yōu)化多數(shù)據(jù)源不只是配置問題性能同樣要關(guān)注。幾個(gè)實(shí)測(cè)經(jīng)驗(yàn)第一連接池參數(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)化必要時(shí)可以創(chuàng)建覆蓋索引來加速常用查詢。但 DDL 操作要謹(jǐn)慎避免高峰期執(zhí)行。5.3 從 MyBatis 到 MyBatisPlus 的兼容保障項(xiàng)目里既有 MyBatis 的 XML 寫法也有 MyBatisPlus 的 Wrapper 寫法。多數(shù)據(jù)源下這兩種寫法都需要保證切換正常。我踩過的一個(gè)坑是在某個(gè)自定義 SQL 里用了${ew.customSqlSegment}結(jié)果 MyBatisPlus 的多表查詢沒有自動(dòng)帶上數(shù)據(jù)源切換邏輯導(dǎo)致部分?jǐn)?shù)據(jù)查不到。這個(gè)問題的根源在于MyBatisPlus 的 Wrapper 條件構(gòu)造器在生成 SQL 時(shí)對(duì)IN類型的條件會(huì)有數(shù)量限制的優(yōu)化邏輯。對(duì)于超過 1000 條的IN查詢MyBatisPlus 會(huì)做拆分處理但這個(gè)拆分后的 SQL 執(zhí)行順序可能與數(shù)據(jù)源切換順序不一致。解決方案是手動(dòng)把IN查詢拆分為多個(gè)小批次避免單條 SQL 過大。另外如果要在 MyBatisPlus 中使用自定義 SQL 并拼接 Wrapper建議用${ew.customSqlSegment}時(shí)注意轉(zhuǎn)義問題尤其是字段名包含關(guān)鍵字時(shí)要在注解或 XML 里確認(rèn)最終 SQL 的正確性。6. 常見問題速查表與排查技巧6.1 問題匯總癥狀可能原因解決辦法啟動(dòng)報(bào)DataSource循環(huán)依賴多個(gè)數(shù)據(jù)源的 Bean 互相引用用Primary指定主數(shù)據(jù)源或在配置類中通過Qualifier明確注入切換數(shù)據(jù)源不生效AOP 切面沒有攔截到方法確認(rèn)自定義注解是否標(biāo)在 Service 方法上Order(1)是否配置事務(wù)方法內(nèi)切換數(shù)據(jù)源失敗事務(wù)開啟時(shí)連接已鎖定拆分方法或使用編程式事務(wù)SqlServer 查詢報(bào)錯(cuò)字段名是保留字用方括號(hào)括起來MyBatisPlus 分頁在 SqlServer 下失效方言識(shí)別失敗PaginationInnerInterceptor注冊(cè)后確認(rèn)多數(shù)據(jù)源共享同一個(gè)SqlSessionFactory連接池報(bào)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 掃描路徑。第二個(gè)技巧是打開 HikariCP 的連接獲取日志通過監(jiān)控連接池的活動(dòng)情況來判斷數(shù)據(jù)源是否正確。在application.yml里配置logging: level: com.zaxxer.hikari: DEBUG這樣可以看到每次獲取連接來自哪個(gè)數(shù)據(jù)源、連接池的活躍數(shù)是多少對(duì)定位連接泄露和切換異常都很有幫助。第三個(gè)技巧是查看 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ò)展動(dòng)態(tài)加數(shù)據(jù)源、分布式事務(wù)如果項(xiàng)目后續(xù)要接入更多數(shù)據(jù)源比如再加一個(gè) PostgreSQL只需要在DataSourceConfig中添加一個(gè)新的數(shù)據(jù)源 Bean然后在dynamicDataSource中把它put進(jìn)targetDataSources即可。但要注意如果數(shù)據(jù)源是運(yùn)行時(shí)動(dòng)態(tài)增加的比如多租戶場(chǎng)景需要調(diào)用AbstractRoutingDataSource的afterPropertiesSet()方法來刷新配置。分布式事務(wù)是個(gè)更深的話題。如果業(yè)務(wù)上真的需要跨庫的強(qiáng)一致性比如一個(gè)操作既要寫 MySQL 又要寫 SqlServer多數(shù)據(jù)源方案已經(jīng)解決不了問題了得引入分布式事務(wù)中間件。我的建議是盡早評(píng)估業(yè)務(wù)場(chǎng)景如果只是簡(jiǎn)單的查詢和異步補(bǔ)償多數(shù)據(jù)源方案完全夠用如果要做強(qiáng)一致的跨庫寫操作提前設(shè)計(jì)好技術(shù)選型不要等寫完了再返工。我在實(shí)際項(xiàng)目中的體會(huì)是多數(shù)據(jù)源本身并不復(fù)雜復(fù)雜的永遠(yuǎn)是業(yè)務(wù)邊界和異常處理。動(dòng)手之前先想清楚哪個(gè)庫是主、哪個(gè)庫是輔在代碼層面規(guī)定好數(shù)據(jù)源的使用規(guī)范比什么花哨的框架都重要。最后再分享一個(gè)平時(shí)容易忽略的小細(xì)節(jié)如果你的項(xiàng)目在部署時(shí)切換了環(huán)境記得檢查數(shù)據(jù)庫連接串和賬號(hào)權(quán)限我遇到過多次因?yàn)樾颅h(huán)境 SqlServer 登錄賬號(hào)缺少VIEW SERVER STATE權(quán)限導(dǎo)致連接池初始化異常的案例這類問題一般不報(bào)錯(cuò)清楚排查起來比較費(fèi)勁提前做好環(huán)境檢查能省不少事。