據(jù)源配置實戰(zhàn)：原理、踩坑與最佳實踐)
做多數(shù)據(jù)源這件事我前前后后折騰過好幾個方案從最開始手動寫AbstractRoutingDataSource到后來切到mybatis-plus的dynamic-datasource最大的感受就是如果項目里已經(jīng)用了mybatis-plus多數(shù)據(jù)源配置真的沒必要自己造輪子。這個starter把最臟最累的活都干完了而且坑也填得差不多了。這篇文章就把我的完整配置過程、踩過的坑、以及一些網(wǎng)上很少說清楚的細(xì)節(jié)一次性講透保證你照著做就能跑起來。為什么項目會需要多數(shù)據(jù)源先別急著上手配置你得先想清楚一個問題你到底是不是真的需要多數(shù)據(jù)源我見過不少項目其實只有一個庫但開發(fā)同學(xué)提前把多數(shù)據(jù)源的架子搭好了。這種“未雨綢繆”我一般不建議因為多數(shù)據(jù)源會引入額外的復(fù)雜度尤其是事務(wù)邊界變模糊、連接管理變復(fù)雜一旦出了問題排查成本很高。真正需要多數(shù)據(jù)源的場景大致就這么幾類讀寫分離主庫負(fù)責(zé)寫從庫負(fù)責(zé)讀這是最常見的訴求。分庫分表的過渡階段還沒上ShardingSphere這種中間件先用多數(shù)據(jù)源頂著。業(yè)務(wù)數(shù)據(jù)隔離比如訂單庫、用戶庫、日志庫物理上分離各有各的連接池。第三方系統(tǒng)對接需要直連別人家的數(shù)據(jù)庫人家只給你只讀賬號。報表統(tǒng)計場景大查詢走獨立的庫免得把業(yè)務(wù)庫拖垮。我之前遇到的一個典型場景就是讀寫分離線上訂單系統(tǒng)主庫的壓力還好但后臺的報表查詢?nèi)悄欠N多表關(guān)聯(lián)的大SQL一跑就是好幾秒直接把主庫的CPU干到80%。后來就是把報表查詢?nèi)壳械街蛔x從庫主庫瞬間就穩(wěn)了。這種場景用mybatis-plus的多數(shù)據(jù)源就是一兩行注解的事收益非常直接。再說說為什么選mybatis-plus而不是自己寫或者用Spring自帶的方案。其實Spring的AbstractRoutingDataSource本身就能實現(xiàn)動態(tài)數(shù)據(jù)源我早年也這么干過得自己寫AOP切面、自己維護(hù)數(shù)據(jù)源上下文、自己處理事務(wù)的綁定問題。說白了技術(shù)上能做但代碼量不小而且邊界情況特別多。mybatis-plus的dynamic-datasource-spring-boot-starter把這些封裝好了還額外支持了嵌套切換、懶加載數(shù)據(jù)源、連接池監(jiān)控這些實用功能。既然項目里已經(jīng)用了mybatis-plus那直接用這個starter是最平滑的路子。動態(tài)數(shù)據(jù)源的核心原理用mybatis-plus配置多數(shù)據(jù)源很多人上來就抄配置跑通了就完事。但你要是不理解它背后的原理遇到問題的時候會非常痛苦。這個starter的原理一句話就能說清它本質(zhì)上還是基于Spring的AbstractRoutingDataSource在每次數(shù)據(jù)庫操作前通過AOP攔截DS注解把當(dāng)前要用的數(shù)據(jù)源標(biāo)識存到ThreadLocal里然后在真正獲取連接的時候動態(tài)路由到對應(yīng)的數(shù)據(jù)源上。我展開說一下這條鏈路你理解了以后排錯會容易很多。先說底層的數(shù)據(jù)源路由。Spring提供了一個抽象類叫AbstractRoutingDataSource它維護(hù)了一個Mapkey是數(shù)據(jù)源標(biāo)識value是實際的數(shù)據(jù)源對象。它有一個determineCurrentLookupKey()方法你重寫這個方法返回一個keySpring在每次獲取數(shù)據(jù)庫連接的時候都會調(diào)它根據(jù)key取對應(yīng)的數(shù)據(jù)源。mybatis-plus的dynamic-datasource對這個類做了增強(qiáng)如果當(dāng)前線程沒設(shè)置數(shù)據(jù)源標(biāo)識就用默認(rèn)主庫如果設(shè)置了就用對應(yīng)的庫。這就是整個多數(shù)據(jù)源能跑起來的地基。再說AOP攔截。dynamic-datasource定義了一個切面攔截所有加了DS注解的方法。在方法執(zhí)行前它會把DS里指定的數(shù)據(jù)源名稱存到DynamicDataSourceContextHolder的ThreadLocal里方法執(zhí)行完再把這個值清理掉。所以**DS注解的作用范圍就是當(dāng)前線程內(nèi)的方法執(zhí)行期**方法結(jié)束ThreadLocal就清了不會串到下一個請求。這里有個非常關(guān)鍵的細(xì)節(jié)DS注解是加在方法上的不是加在類上全局生效的。雖然注解本身支持加在Service類上但那也只是給這個類的所有方法都套了同一個數(shù)據(jù)源本質(zhì)上還是方法級別的攔截。很多人誤以為加在類上就是“這個類永遠(yuǎn)走某個庫”其實不是事務(wù)和嵌套調(diào)用都會改變實際路由結(jié)果。理解了原理你再看配置里的每一行就都看得懂了。比如yml里的primary: master就是決定當(dāng)ThreadLocal里沒值的時候默認(rèn)走哪個庫strict: true是當(dāng)DS指定了一個不存在的庫名時直接報錯防止你寫錯名字后靜默走了主庫這個務(wù)必要開。mybatis-plus的多數(shù)據(jù)源starter還做了一些深層的適配比如數(shù)據(jù)源懶加載也就是在Spring容器啟動的時候并不立即創(chuàng)建所有數(shù)據(jù)源連接池而是等第一次用到某個庫的時候才初始化。你如果配了很多個庫這個特性會讓啟動速度快不少。另外它還內(nèi)置了Druid、HikariCP的監(jiān)控支持不過這個看你實際用什么連接池Druid配合的監(jiān)控面板用起來更順手一些。開箱即用完整配置步驟接下來就是實戰(zhàn)環(huán)節(jié)。我盡量把每一步都寫清楚包括依賴版本、配置文件、代碼位置你照著做就行。先說環(huán)境SpringBoot 2.7.18mybatis-plus-boot-starter 3.5.7JDK 8。高版本的SpringBoot 3.x我也用過配置方式基本一致就是javax換成jakarta注意一下就行。第一步引入依賴在pom.xml里加入dynamic-datasource的starter。注意這個starter是獨立的和mybatis-plus的starter是兩回事別搞混了。!-- mybatis-plus 核心starter -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.7/version /dependency !-- mybatis-plus 多數(shù)據(jù)源starter -- dependency groupIdcom.baomidou/groupId artifactIddynamic-datasource-spring-boot-starter/artifactId version3.6.1/version /dependency版本這里我多說一句3.6.1是目前比較穩(wěn)定的版本3.5.x和3.6.x都有一些迭代但如果你項目里已經(jīng)有mybatis-plus了建議讓多數(shù)據(jù)源starter和mybatis-plus保持相近版本避免出現(xiàn)兼容問題。我踩過一次坑mybatis-plus用的3.5.3多數(shù)據(jù)源starter用的3.5.0結(jié)果是DS注解在某些場景下不生效排查了半天升級版本后就好了。第二步配置yml數(shù)據(jù)源在application.yml里配置數(shù)據(jù)源信息。這個是核心配置spring: datasource: dynamic: primary: master strict: true strategy: com.baomidou.dynamic.datasource.DynamicDataSourceStrategy datasource: master: url: jdbc:mysql://192.168.1.10:3306/order_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver slave: url: jdbc:mysql://192.168.1.11:3306/order_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: readonly_user password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver report: url: jdbc:postgresql://192.168.1.12:5432/report_db username: report password: 123456 driver-class-name: org.postgresql.Driver幾個關(guān)鍵點解釋一下primary: master默認(rèn)數(shù)據(jù)源所有沒加DS注解的Mapper操作都會走這個庫。這是兜底的我建議永遠(yuǎn)保留一個master別把主庫配成別的名字。strict: true嚴(yán)格模式。如果DS里寫了一個不存在的庫名直接拋異常不會靜默走主庫。這個建議開啟否則你拼錯一個字母數(shù)據(jù)寫到主庫里去排查的時候想哭的心都有。數(shù)據(jù)源名稱你可以隨便起比如master、slave、report但注意這些名字會在DS注解里引用要保持一致。第三步在啟動類排除DataSourceAutoConfiguration這一步很多人會漏掉但關(guān)鍵程度不亞于前面的配置。如果你使用的是SpringBoot 2.x以上版本啟動類要加這個排除SpringBootApplication(exclude DataSourceAutoConfiguration.class) public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }為什么要排除因為SpringBoot的自動配置會讀到spring.datasource.url之類的配置去創(chuàng)建DataSource你現(xiàn)在的配置是放在spring.datasource.dynamic.datasource.master下面的SpringBoot默認(rèn)配置根本讀不到就會報錯說找不到主數(shù)據(jù)源。dynamic-datasource的starter自己會創(chuàng)建一個動態(tài)數(shù)據(jù)源所以必須把SpringBoot默認(rèn)的數(shù)據(jù)源自動配置排除掉。這一步網(wǎng)上很多教程沒提或者提了沒解釋為什么。實際上一開始我沒加這個排除啟動直接報錯Failed to configure a DataSource: url attribute is not specified加了排除以后馬上就好了。第四步寫測試代碼驗證配置完成后寫一個簡單的Service來驗證效果。DS注解加在Service層的方法上或者直接加在Mapper的方法上。我建議加在Service層因為業(yè)務(wù)上你更關(guān)心的是“這個業(yè)務(wù)方法走哪個庫”而且Mapper層面太細(xì)了不好管理。Service public class UserServiceImpl implements UserService { Autowired private UserMapper userMapper; Override public User getMasterUser(Long id) { return userMapper.selectById(id); } DS(slave) Override public User getSlaveUser(Long id) { return userMapper.selectById(id); } DS(report) Override public ListReport getReportList() { return reportMapper.selectList(null); } }這里有個非常關(guān)鍵的區(qū)別getMasterUser方法沒加DS走的就是primary指定的主庫getSlaveUser加了DS(slave)走的就是從庫getReportList走的是report庫。注意DS注解可以加在類上表示這個類所有方法都走同一個庫如果類上和方法上都有DS以方法上的為準(zhǔn)方法級的優(yōu)先級更高。從庫的UserMapper和主庫的UserMapper其實是同一個Java接口同一個實體類。區(qū)別只在于你調(diào)用時走的方法加沒加注解。這一點就體現(xiàn)了dynamic-datasource的設(shè)計精髓一個Mapper可以自由穿梭在多個數(shù)據(jù)源之間。高版本SpringBoot的額外注意事項如果你用的是SpringBoot 3.x也就是JDK 17的環(huán)境配置會有一個額外的變化。除了剛才說的排除DataSourceAutoConfiguration還得注意數(shù)據(jù)庫驅(qū)動的坐標(biāo)變化dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependencyMyBatis、Druid這些組件在Boot 3.x下都需要對應(yīng)新版本。dynamic-datasource 3.6.1本身就兼容SpringBoot 3.x這個倒不用擔(dān)心。還有一點SpringBoot 3.x里用的是Jakarta命名空間如果項目里引了老的javax依賴會直接起不來。高版本還有個常見的坑是數(shù)據(jù)源初始化順序的問題。SpringBoot 3.x對自動配置的順序要求更嚴(yán)格如果你發(fā)現(xiàn)啟動報錯說什么DataSource被循環(huán)依賴了試試在啟動類上把SpringBoot的DataSourceTransactionManagerAutoConfiguration也排除掉SpringBootApplication(exclude { DataSourceAutoConfiguration.class, DataSourceTransactionManagerAutoConfiguration.class })不過要注意排除掉DataSourceTransactionManagerAutoConfiguration之后事務(wù)管理器的自動配置就沒了需要你自己注冊或者直接用dynamic-datasource提供的事務(wù)管理器。這個坑一般出現(xiàn)在你同時用了Spring的Transactional和DS的場景后面我會詳細(xì)說。事務(wù)和數(shù)據(jù)源切換的那點事兒這是多數(shù)據(jù)源配置里最讓人頭疼的部分我放在這里單獨講。當(dāng)你用Transactional的時候事務(wù)是在方法進(jìn)入前就開啟了連接也是在事務(wù)開始時從默認(rèn)數(shù)據(jù)源拿的。如果這個事務(wù)方法內(nèi)部又調(diào)用了帶DS的方法那DS可能根本不會切換數(shù)據(jù)源或者切換了也不生效?？聪旅娴睦覶ransactional public void transfer() { orderMapper.insert(order); // 走主庫 getSlaveUser(1L); // 想切到從庫但可能不生效 }問題出在Transactional開啟事務(wù)時已經(jīng)把連接和事務(wù)綁定到當(dāng)前線程了DS的AOP切面在事務(wù)方法內(nèi)部執(zhí)行時試圖去切換數(shù)據(jù)源但事務(wù)管理器還是拿著舊連接不放。所以事務(wù)內(nèi)的數(shù)據(jù)源切換會失效或者報錯。我實測過的結(jié)果是如果你的transfer()方法上加了Transactional內(nèi)部再調(diào)getSlaveUser()實際查詢還是會走主庫。這不是bug而是Spring事務(wù)機(jī)制的固有行為。解決辦法有幾個思路把不需要走主庫的操作拆出去放到一個獨立的事務(wù)方法里這個方法單獨加DS和Transactional。使用dynamic-datasource的DSTransactional來代替Spring的Transactional它支持多數(shù)據(jù)源下的事務(wù)管理但它是本地事務(wù)不支持跨庫的分布式事務(wù)。如果確實需要跨庫強(qiáng)一致那你需要引入Seata這類分布式事務(wù)中間件這是另一個范疇了本文不展開。特別注意多數(shù)據(jù)源配置開啟了以后Spring自帶的Transactional默認(rèn)綁定的是主數(shù)據(jù)源的事務(wù)管理器。如果你在從庫上做寫操作并加了Transactional事務(wù)并不會真正在從庫上生效這個細(xì)節(jié)很多人踩坑后才回過神來。這一點非常容易忽略務(wù)必注意。我個人的習(xí)慣是從庫只做查詢不開放寫權(quán)限數(shù)據(jù)庫賬號也不給寫權(quán)限。這樣從根本上避免從庫上出現(xiàn)寫事務(wù)。實操中遇到的坑和排查心得配置跑通之后還有一堆實際問題。我把這些坑按頻率從高到低列出來你遇到的時候可以直接對號入座?？?DS注解不生效表現(xiàn)是有DS注解的方法實際還是走的默認(rèn)庫。排查思路先確認(rèn)starter版本是否兼容然后確認(rèn)方法是否被Spring代理。如果你是在一個類內(nèi)部的this.xxx()調(diào)用那DS注解是不會被AOP攔截的。因為Spring的AOP基于代理this調(diào)用不走代理對象。Service public class OrderService { // 這樣調(diào)用DS會失效 public void doSomething() { this.queryFromSlave(); } DS(slave) public void queryFromSlave() { // ... } }解決辦法是通過注入自己的代理對象或者把方法拆到另一個Service里調(diào)用。這個是最常見的DS不生效原因沒有之一?？?連接池耗盡或者連接泄漏多數(shù)據(jù)源意味著多個連接池每個都是獨立的默認(rèn)的連接池大小可能不夠。如果你同時有主庫、從庫、報表庫高峰期很容易出現(xiàn)某個庫的連接池被打滿的提示。而且如果你手寫代碼時手動拿了連接沒有釋放那個連接池就泄漏一個時間長了就滿了。建議給每個連接池設(shè)置合理的上限spring: datasource: dynamic: datasource: master: hikari: maximum-pool-size: 30 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 slave: hikari: maximum-pool-size: 20 minimum-idle: 5另外注意從庫的連接池峰值往往更高因為讀請求多把從庫的maximum-pool-size調(diào)大一點是合理的。我之前就是主庫30、從庫50這么配的。坑3MyBatis二級緩存串庫如果你開了MyBatis的二級緩存緩存的是查詢結(jié)果但二級緩存的key是Mapper的namespace不區(qū)分?jǐn)?shù)據(jù)源。這意味著你用主庫查了一次緩存的鍵沒有數(shù)據(jù)源維度同類查詢切到從庫時命中的可能是主庫的緩存結(jié)果。這個問題在小項目里可能不出事但一旦兩個庫的數(shù)據(jù)不一致就會出詭異的問題。建議多數(shù)據(jù)源場景下直接關(guān)閉二級緩存老老實實用一級緩存和Redis。坑4主從延遲導(dǎo)致的數(shù)據(jù)不一致讀寫分離的場景下從庫的數(shù)據(jù)有延遲。你剛寫完主庫馬上去查從庫可能查不到剛寫的數(shù)據(jù)。這時候需要區(qū)分業(yè)務(wù)場景對實時性要求高的查詢強(qiáng)制走主庫能容忍延遲的就放心走從庫。比如訂單詳情頁的查詢建議直接走主庫或者做一個短時間的緩存別讓主從延遲影響用戶體驗。這個問題跟多數(shù)據(jù)源本身無關(guān)但既然做了讀寫分離就一定會遇到提前了解解法是很有必要的?？?連接在事務(wù)方法內(nèi)部切換導(dǎo)致連接管理器報錯這個場景其實比較偏但我確實遇到過。動態(tài)數(shù)據(jù)源里如果在一個事務(wù)執(zhí)行途中切換數(shù)據(jù)源DynamicRoutingDataSource會嘗試在當(dāng)前線程重新綁定連接而舊連接和事務(wù)的關(guān)系會變得很微妙進(jìn)而出現(xiàn)一些奇怪的SQL執(zhí)行錯誤日志里會蹦出來類似Connection is not available這種。所以再次強(qiáng)調(diào)不要在一個事務(wù)方法里來回切換數(shù)據(jù)源要么拆分方法要么全走多數(shù)據(jù)源事務(wù)注解。多數(shù)據(jù)源常見問題排查速查表我整理了一下實戰(zhàn)中比較高頻的場景做成一個速查表方便你遇到問題時快速定位方向。問題現(xiàn)象可能原因解決思路啟動報錯url attribute is not specified沒排除DataSourceAutoConfiguration啟動類排除該自動配置DS注解完全不生效類內(nèi)部this調(diào)用沒走代理拆到獨立Bean或注入代理對象事務(wù)內(nèi)部切換數(shù)據(jù)源失敗Transactional在DS之前開啟連接已綁定拆分事務(wù)方法或使用DSTransactional從庫數(shù)據(jù)查不到剛寫入的數(shù)據(jù)主從同步延遲實時性要求高的查詢走主庫連接池大量超時連接泄漏或連接池太小排查泄漏點調(diào)整Hikari參數(shù)查詢結(jié)果串庫MyBatis二級緩存不區(qū)分?jǐn)?shù)據(jù)源關(guān)閉二級緩存strict模式下報數(shù)據(jù)源不存在DS注解寫錯庫名核對yml里的數(shù)據(jù)源名稱這個速查表不敢說覆蓋所有情況但大部分新手遇到的就這些了。真正高級的問題得靠日志和監(jiān)控一步步定位比如Druid的監(jiān)控頁面可以看到每個數(shù)據(jù)源當(dāng)前的活躍連接數(shù)遇到連接問題看那個是最直觀的。多數(shù)據(jù)源場景下的最佳實踐建議最后聊幾點實戰(zhàn)心得。這些不是配置層面的東西而是架構(gòu)層面的取舍但我覺得比配置本身更重要。能用主從復(fù)制解決的別用多數(shù)據(jù)源。如果你只是想減輕主庫壓力優(yōu)先考慮從庫復(fù)制然后在業(yè)務(wù)代碼里通過切面或Mapper注解走從庫。如果業(yè)務(wù)模塊之間的依賴并不緊密干脆拆庫拆服務(wù)走微服務(wù)每個服務(wù)管自己的庫這才是徹底的解耦。配置層面建議每個數(shù)據(jù)源的最小空閑連接數(shù)不要太小即使流量不大也至少維持3到5個空閑連接避免突然的流量尖峰把連接池打滿。連接池初始化是耗時的如果空閑連接全被回收了高峰時突然新建連接會產(chǎn)生明顯的毛刺延遲。還有一個很多人忽略的管理問題多數(shù)據(jù)源的密碼保管和變更。三個庫的密碼分別寫在yml里每過幾個月密碼就會過期改起來雖然不難但容易漏。我之前就漏改了一個報表庫的密碼導(dǎo)致報表服務(wù)在凌晨定時任務(wù)跑了兩個小時全失敗了。建議引入配置中心來統(tǒng)一管理或者至少把數(shù)據(jù)源配置抽到獨立的profile文件里別所有環(huán)境混成一個yml。最后說一個我比較堅持的原則生產(chǎn)環(huán)境開啟strict模式任何SQL都不允許因為寫錯名字而靜默落到默認(rèn)庫上。寧可讓錯誤快速暴露寧可讓自己半夜被電話叫醒也不要在用戶頁面出現(xiàn)數(shù)據(jù)錯亂后去追查好幾天的庫。這是我吃了虧之后才長記性的。 MyBatis-Plus多數(shù)據(jù)源配置實戰(zhàn)：原理、踩坑與最佳實踐
做多數(shù)據(jù)源這件事我前前后后折騰過好幾個方案從最開始手動寫AbstractRoutingDataSource到后來切到mybatis-plus的dynamic-datasource最大的感受就是如果項目里已經(jīng)用了mybatis-plus多數(shù)據(jù)源配置真的沒必要自己造輪子。這個starter把最臟最累的活都干完了而且坑也填得差不多了。這篇文章就把我的完整配置過程、踩過的坑、以及一些網(wǎng)上很少說清楚的細(xì)節(jié)一次性講透保證你照著做就能跑起來。為什么項目會需要多數(shù)據(jù)源先別急著上手配置你得先想清楚一個問題你到底是不是真的需要多數(shù)據(jù)源我見過不少項目其實只有一個庫但開發(fā)同學(xué)提前把多數(shù)據(jù)源的架子搭好了。這種“未雨綢繆”我一般不建議因為多數(shù)據(jù)源會引入額外的復(fù)雜度尤其是事務(wù)邊界變模糊、連接管理變復(fù)雜一旦出了問題排查成本很高。真正需要多數(shù)據(jù)源的場景大致就這么幾類讀寫分離主庫負(fù)責(zé)寫從庫負(fù)責(zé)讀這是最常見的訴求。分庫分表的過渡階段還沒上ShardingSphere這種中間件先用多數(shù)據(jù)源頂著。業(yè)務(wù)數(shù)據(jù)隔離比如訂單庫、用戶庫、日志庫物理上分離各有各的連接池。第三方系統(tǒng)對接需要直連別人家的數(shù)據(jù)庫人家只給你只讀賬號。報表統(tǒng)計場景大查詢走獨立的庫免得把業(yè)務(wù)庫拖垮。我之前遇到的一個典型場景就是讀寫分離線上訂單系統(tǒng)主庫的壓力還好但后臺的報表查詢?nèi)悄欠N多表關(guān)聯(lián)的大SQL一跑就是好幾秒直接把主庫的CPU干到80%。后來就是把報表查詢?nèi)壳械街蛔x從庫主庫瞬間就穩(wěn)了。這種場景用mybatis-plus的多數(shù)據(jù)源就是一兩行注解的事收益非常直接。再說說為什么選mybatis-plus而不是自己寫或者用Spring自帶的方案。其實Spring的AbstractRoutingDataSource本身就能實現(xiàn)動態(tài)數(shù)據(jù)源我早年也這么干過得自己寫AOP切面、自己維護(hù)數(shù)據(jù)源上下文、自己處理事務(wù)的綁定問題。說白了技術(shù)上能做但代碼量不小而且邊界情況特別多。mybatis-plus的dynamic-datasource-spring-boot-starter把這些封裝好了還額外支持了嵌套切換、懶加載數(shù)據(jù)源、連接池監(jiān)控這些實用功能。既然項目里已經(jīng)用了mybatis-plus那直接用這個starter是最平滑的路子。動態(tài)數(shù)據(jù)源的核心原理用mybatis-plus配置多數(shù)據(jù)源很多人上來就抄配置跑通了就完事。但你要是不理解它背后的原理遇到問題的時候會非常痛苦。這個starter的原理一句話就能說清它本質(zhì)上還是基于Spring的AbstractRoutingDataSource在每次數(shù)據(jù)庫操作前通過AOP攔截DS注解把當(dāng)前要用的數(shù)據(jù)源標(biāo)識存到ThreadLocal里然后在真正獲取連接的時候動態(tài)路由到對應(yīng)的數(shù)據(jù)源上。我展開說一下這條鏈路你理解了以后排錯會容易很多。先說底層的數(shù)據(jù)源路由。Spring提供了一個抽象類叫AbstractRoutingDataSource它維護(hù)了一個Mapkey是數(shù)據(jù)源標(biāo)識value是實際的數(shù)據(jù)源對象。它有一個determineCurrentLookupKey()方法你重寫這個方法返回一個keySpring在每次獲取數(shù)據(jù)庫連接的時候都會調(diào)它根據(jù)key取對應(yīng)的數(shù)據(jù)源。mybatis-plus的dynamic-datasource對這個類做了增強(qiáng)如果當(dāng)前線程沒設(shè)置數(shù)據(jù)源標(biāo)識就用默認(rèn)主庫如果設(shè)置了就用對應(yīng)的庫。這就是整個多數(shù)據(jù)源能跑起來的地基。再說AOP攔截。dynamic-datasource定義了一個切面攔截所有加了DS注解的方法。在方法執(zhí)行前它會把DS里指定的數(shù)據(jù)源名稱存到DynamicDataSourceContextHolder的ThreadLocal里方法執(zhí)行完再把這個值清理掉。所以**DS注解的作用范圍就是當(dāng)前線程內(nèi)的方法執(zhí)行期**方法結(jié)束ThreadLocal就清了不會串到下一個請求。這里有個非常關(guān)鍵的細(xì)節(jié)DS注解是加在方法上的不是加在類上全局生效的。雖然注解本身支持加在Service類上但那也只是給這個類的所有方法都套了同一個數(shù)據(jù)源本質(zhì)上還是方法級別的攔截。很多人誤以為加在類上就是“這個類永遠(yuǎn)走某個庫”其實不是事務(wù)和嵌套調(diào)用都會改變實際路由結(jié)果。理解了原理你再看配置里的每一行就都看得懂了。比如yml里的primary: master就是決定當(dāng)ThreadLocal里沒值的時候默認(rèn)走哪個庫strict: true是當(dāng)DS指定了一個不存在的庫名時直接報錯防止你寫錯名字后靜默走了主庫這個務(wù)必要開。mybatis-plus的多數(shù)據(jù)源starter還做了一些深層的適配比如數(shù)據(jù)源懶加載也就是在Spring容器啟動的時候并不立即創(chuàng)建所有數(shù)據(jù)源連接池而是等第一次用到某個庫的時候才初始化。你如果配了很多個庫這個特性會讓啟動速度快不少。另外它還內(nèi)置了Druid、HikariCP的監(jiān)控支持不過這個看你實際用什么連接池Druid配合的監(jiān)控面板用起來更順手一些。開箱即用完整配置步驟接下來就是實戰(zhàn)環(huán)節(jié)。我盡量把每一步都寫清楚包括依賴版本、配置文件、代碼位置你照著做就行。先說環(huán)境SpringBoot 2.7.18mybatis-plus-boot-starter 3.5.7JDK 8。高版本的SpringBoot 3.x我也用過配置方式基本一致就是javax換成jakarta注意一下就行。第一步引入依賴在pom.xml里加入dynamic-datasource的starter。注意這個starter是獨立的和mybatis-plus的starter是兩回事別搞混了。!-- mybatis-plus 核心starter -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.7/version /dependency !-- mybatis-plus 多數(shù)據(jù)源starter -- dependency groupIdcom.baomidou/groupId artifactIddynamic-datasource-spring-boot-starter/artifactId version3.6.1/version /dependency版本這里我多說一句3.6.1是目前比較穩(wěn)定的版本3.5.x和3.6.x都有一些迭代但如果你項目里已經(jīng)有mybatis-plus了建議讓多數(shù)據(jù)源starter和mybatis-plus保持相近版本避免出現(xiàn)兼容問題。我踩過一次坑mybatis-plus用的3.5.3多數(shù)據(jù)源starter用的3.5.0結(jié)果是DS注解在某些場景下不生效排查了半天升級版本后就好了。第二步配置yml數(shù)據(jù)源在application.yml里配置數(shù)據(jù)源信息。這個是核心配置spring: datasource: dynamic: primary: master strict: true strategy: com.baomidou.dynamic.datasource.DynamicDataSourceStrategy datasource: master: url: jdbc:mysql://192.168.1.10:3306/order_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver slave: url: jdbc:mysql://192.168.1.11:3306/order_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: readonly_user password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver report: url: jdbc:postgresql://192.168.1.12:5432/report_db username: report password: 123456 driver-class-name: org.postgresql.Driver幾個關(guān)鍵點解釋一下primary: master默認(rèn)數(shù)據(jù)源所有沒加DS注解的Mapper操作都會走這個庫。這是兜底的我建議永遠(yuǎn)保留一個master別把主庫配成別的名字。strict: true嚴(yán)格模式。如果DS里寫了一個不存在的庫名直接拋異常不會靜默走主庫。這個建議開啟否則你拼錯一個字母數(shù)據(jù)寫到主庫里去排查的時候想哭的心都有。數(shù)據(jù)源名稱你可以隨便起比如master、slave、report但注意這些名字會在DS注解里引用要保持一致。第三步在啟動類排除DataSourceAutoConfiguration這一步很多人會漏掉但關(guān)鍵程度不亞于前面的配置。如果你使用的是SpringBoot 2.x以上版本啟動類要加這個排除SpringBootApplication(exclude DataSourceAutoConfiguration.class) public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }為什么要排除因為SpringBoot的自動配置會讀到spring.datasource.url之類的配置去創(chuàng)建DataSource你現(xiàn)在的配置是放在spring.datasource.dynamic.datasource.master下面的SpringBoot默認(rèn)配置根本讀不到就會報錯說找不到主數(shù)據(jù)源。dynamic-datasource的starter自己會創(chuàng)建一個動態(tài)數(shù)據(jù)源所以必須把SpringBoot默認(rèn)的數(shù)據(jù)源自動配置排除掉。這一步網(wǎng)上很多教程沒提或者提了沒解釋為什么。實際上一開始我沒加這個排除啟動直接報錯Failed to configure a DataSource: url attribute is not specified加了排除以后馬上就好了。第四步寫測試代碼驗證配置完成后寫一個簡單的Service來驗證效果。DS注解加在Service層的方法上或者直接加在Mapper的方法上。我建議加在Service層因為業(yè)務(wù)上你更關(guān)心的是“這個業(yè)務(wù)方法走哪個庫”而且Mapper層面太細(xì)了不好管理。Service public class UserServiceImpl implements UserService { Autowired private UserMapper userMapper; Override public User getMasterUser(Long id) { return userMapper.selectById(id); } DS(slave) Override public User getSlaveUser(Long id) { return userMapper.selectById(id); } DS(report) Override public ListReport getReportList() { return reportMapper.selectList(null); } }這里有個非常關(guān)鍵的區(qū)別getMasterUser方法沒加DS走的就是primary指定的主庫getSlaveUser加了DS(slave)走的就是從庫getReportList走的是report庫。注意DS注解可以加在類上表示這個類所有方法都走同一個庫如果類上和方法上都有DS以方法上的為準(zhǔn)方法級的優(yōu)先級更高。從庫的UserMapper和主庫的UserMapper其實是同一個Java接口同一個實體類。區(qū)別只在于你調(diào)用時走的方法加沒加注解。這一點就體現(xiàn)了dynamic-datasource的設(shè)計精髓一個Mapper可以自由穿梭在多個數(shù)據(jù)源之間。高版本SpringBoot的額外注意事項如果你用的是SpringBoot 3.x也就是JDK 17的環(huán)境配置會有一個額外的變化。除了剛才說的排除DataSourceAutoConfiguration還得注意數(shù)據(jù)庫驅(qū)動的坐標(biāo)變化dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependencyMyBatis、Druid這些組件在Boot 3.x下都需要對應(yīng)新版本。dynamic-datasource 3.6.1本身就兼容SpringBoot 3.x這個倒不用擔(dān)心。還有一點SpringBoot 3.x里用的是Jakarta命名空間如果項目里引了老的javax依賴會直接起不來。高版本還有個常見的坑是數(shù)據(jù)源初始化順序的問題。SpringBoot 3.x對自動配置的順序要求更嚴(yán)格如果你發(fā)現(xiàn)啟動報錯說什么DataSource被循環(huán)依賴了試試在啟動類上把SpringBoot的DataSourceTransactionManagerAutoConfiguration也排除掉SpringBootApplication(exclude { DataSourceAutoConfiguration.class, DataSourceTransactionManagerAutoConfiguration.class })不過要注意排除掉DataSourceTransactionManagerAutoConfiguration之后事務(wù)管理器的自動配置就沒了需要你自己注冊或者直接用dynamic-datasource提供的事務(wù)管理器。這個坑一般出現(xiàn)在你同時用了Spring的Transactional和DS的場景后面我會詳細(xì)說。事務(wù)和數(shù)據(jù)源切換的那點事兒這是多數(shù)據(jù)源配置里最讓人頭疼的部分我放在這里單獨講。當(dāng)你用Transactional的時候事務(wù)是在方法進(jìn)入前就開啟了連接也是在事務(wù)開始時從默認(rèn)數(shù)據(jù)源拿的。如果這個事務(wù)方法內(nèi)部又調(diào)用了帶DS的方法那DS可能根本不會切換數(shù)據(jù)源或者切換了也不生效?？聪旅娴睦覶ransactional public void transfer() { orderMapper.insert(order); // 走主庫 getSlaveUser(1L); // 想切到從庫但可能不生效 }問題出在Transactional開啟事務(wù)時已經(jīng)把連接和事務(wù)綁定到當(dāng)前線程了DS的AOP切面在事務(wù)方法內(nèi)部執(zhí)行時試圖去切換數(shù)據(jù)源但事務(wù)管理器還是拿著舊連接不放。所以事務(wù)內(nèi)的數(shù)據(jù)源切換會失效或者報錯。我實測過的結(jié)果是如果你的transfer()方法上加了Transactional內(nèi)部再調(diào)getSlaveUser()實際查詢還是會走主庫。這不是bug而是Spring事務(wù)機(jī)制的固有行為。解決辦法有幾個思路把不需要走主庫的操作拆出去放到一個獨立的事務(wù)方法里這個方法單獨加DS和Transactional。使用dynamic-datasource的DSTransactional來代替Spring的Transactional它支持多數(shù)據(jù)源下的事務(wù)管理但它是本地事務(wù)不支持跨庫的分布式事務(wù)。如果確實需要跨庫強(qiáng)一致那你需要引入Seata這類分布式事務(wù)中間件這是另一個范疇了本文不展開。特別注意多數(shù)據(jù)源配置開啟了以后Spring自帶的Transactional默認(rèn)綁定的是主數(shù)據(jù)源的事務(wù)管理器。如果你在從庫上做寫操作并加了Transactional事務(wù)并不會真正在從庫上生效這個細(xì)節(jié)很多人踩坑后才回過神來。這一點非常容易忽略務(wù)必注意。我個人的習(xí)慣是從庫只做查詢不開放寫權(quán)限數(shù)據(jù)庫賬號也不給寫權(quán)限。這樣從根本上避免從庫上出現(xiàn)寫事務(wù)。實操中遇到的坑和排查心得配置跑通之后還有一堆實際問題。我把這些坑按頻率從高到低列出來你遇到的時候可以直接對號入座?？?DS注解不生效表現(xiàn)是有DS注解的方法實際還是走的默認(rèn)庫。排查思路先確認(rèn)starter版本是否兼容然后確認(rèn)方法是否被Spring代理。如果你是在一個類內(nèi)部的this.xxx()調(diào)用那DS注解是不會被AOP攔截的。因為Spring的AOP基于代理this調(diào)用不走代理對象。Service public class OrderService { // 這樣調(diào)用DS會失效 public void doSomething() { this.queryFromSlave(); } DS(slave) public void queryFromSlave() { // ... } }解決辦法是通過注入自己的代理對象或者把方法拆到另一個Service里調(diào)用。這個是最常見的DS不生效原因沒有之一?？?連接池耗盡或者連接泄漏多數(shù)據(jù)源意味著多個連接池每個都是獨立的默認(rèn)的連接池大小可能不夠。如果你同時有主庫、從庫、報表庫高峰期很容易出現(xiàn)某個庫的連接池被打滿的提示。而且如果你手寫代碼時手動拿了連接沒有釋放那個連接池就泄漏一個時間長了就滿了。建議給每個連接池設(shè)置合理的上限spring: datasource: dynamic: datasource: master: hikari: maximum-pool-size: 30 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 slave: hikari: maximum-pool-size: 20 minimum-idle: 5另外注意從庫的連接池峰值往往更高因為讀請求多把從庫的maximum-pool-size調(diào)大一點是合理的。我之前就是主庫30、從庫50這么配的。坑3MyBatis二級緩存串庫如果你開了MyBatis的二級緩存緩存的是查詢結(jié)果但二級緩存的key是Mapper的namespace不區(qū)分?jǐn)?shù)據(jù)源。這意味著你用主庫查了一次緩存的鍵沒有數(shù)據(jù)源維度同類查詢切到從庫時命中的可能是主庫的緩存結(jié)果。這個問題在小項目里可能不出事但一旦兩個庫的數(shù)據(jù)不一致就會出詭異的問題。建議多數(shù)據(jù)源場景下直接關(guān)閉二級緩存老老實實用一級緩存和Redis。坑4主從延遲導(dǎo)致的數(shù)據(jù)不一致讀寫分離的場景下從庫的數(shù)據(jù)有延遲。你剛寫完主庫馬上去查從庫可能查不到剛寫的數(shù)據(jù)。這時候需要區(qū)分業(yè)務(wù)場景對實時性要求高的查詢強(qiáng)制走主庫能容忍延遲的就放心走從庫。比如訂單詳情頁的查詢建議直接走主庫或者做一個短時間的緩存別讓主從延遲影響用戶體驗。這個問題跟多數(shù)據(jù)源本身無關(guān)但既然做了讀寫分離就一定會遇到提前了解解法是很有必要的?？?連接在事務(wù)方法內(nèi)部切換導(dǎo)致連接管理器報錯這個場景其實比較偏但我確實遇到過。動態(tài)數(shù)據(jù)源里如果在一個事務(wù)執(zhí)行途中切換數(shù)據(jù)源DynamicRoutingDataSource會嘗試在當(dāng)前線程重新綁定連接而舊連接和事務(wù)的關(guān)系會變得很微妙進(jìn)而出現(xiàn)一些奇怪的SQL執(zhí)行錯誤日志里會蹦出來類似Connection is not available這種。所以再次強(qiáng)調(diào)不要在一個事務(wù)方法里來回切換數(shù)據(jù)源要么拆分方法要么全走多數(shù)據(jù)源事務(wù)注解。多數(shù)據(jù)源常見問題排查速查表我整理了一下實戰(zhàn)中比較高頻的場景做成一個速查表方便你遇到問題時快速定位方向。問題現(xiàn)象可能原因解決思路啟動報錯url attribute is not specified沒排除DataSourceAutoConfiguration啟動類排除該自動配置DS注解完全不生效類內(nèi)部this調(diào)用沒走代理拆到獨立Bean或注入代理對象事務(wù)內(nèi)部切換數(shù)據(jù)源失敗Transactional在DS之前開啟連接已綁定拆分事務(wù)方法或使用DSTransactional從庫數(shù)據(jù)查不到剛寫入的數(shù)據(jù)主從同步延遲實時性要求高的查詢走主庫連接池大量超時連接泄漏或連接池太小排查泄漏點調(diào)整Hikari參數(shù)查詢結(jié)果串庫MyBatis二級緩存不區(qū)分?jǐn)?shù)據(jù)源關(guān)閉二級緩存strict模式下報數(shù)據(jù)源不存在DS注解寫錯庫名核對yml里的數(shù)據(jù)源名稱這個速查表不敢說覆蓋所有情況但大部分新手遇到的就這些了。真正高級的問題得靠日志和監(jiān)控一步步定位比如Druid的監(jiān)控頁面可以看到每個數(shù)據(jù)源當(dāng)前的活躍連接數(shù)遇到連接問題看那個是最直觀的。多數(shù)據(jù)源場景下的最佳實踐建議最后聊幾點實戰(zhàn)心得。這些不是配置層面的東西而是架構(gòu)層面的取舍但我覺得比配置本身更重要。能用主從復(fù)制解決的別用多數(shù)據(jù)源。如果你只是想減輕主庫壓力優(yōu)先考慮從庫復(fù)制然后在業(yè)務(wù)代碼里通過切面或Mapper注解走從庫。如果業(yè)務(wù)模塊之間的依賴并不緊密干脆拆庫拆服務(wù)走微服務(wù)每個服務(wù)管自己的庫這才是徹底的解耦。配置層面建議每個數(shù)據(jù)源的最小空閑連接數(shù)不要太小即使流量不大也至少維持3到5個空閑連接避免突然的流量尖峰把連接池打滿。連接池初始化是耗時的如果空閑連接全被回收了高峰時突然新建連接會產(chǎn)生明顯的毛刺延遲。還有一個很多人忽略的管理問題多數(shù)據(jù)源的密碼保管和變更。三個庫的密碼分別寫在yml里每過幾個月密碼就會過期改起來雖然不難但容易漏。我之前就漏改了一個報表庫的密碼導(dǎo)致報表服務(wù)在凌晨定時任務(wù)跑了兩個小時全失敗了。建議引入配置中心來統(tǒng)一管理或者至少把數(shù)據(jù)源配置抽到獨立的profile文件里別所有環(huán)境混成一個yml。最后說一個我比較堅持的原則生產(chǎn)環(huán)境開啟strict模式任何SQL都不允許因為寫錯名字而靜默落到默認(rèn)庫上。寧可讓錯誤快速暴露寧可讓自己半夜被電話叫醒也不要在用戶頁面出現(xiàn)數(shù)據(jù)錯亂后去追查好幾天的庫。這是我吃了虧之后才長記性的。