1. 背景
一個主庫和N個應用庫的數據源,并且會同時操作主庫和應用庫的數據,需要解決以下兩個問題:
- 如何動態管理多個數據源以及切換?
- 如何保證多數據源場景下的數據一致性(事務)?
本文主要探討這兩個問題的解決方案,希望能對讀者有一定的啟發。
基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序,支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能
- 項目地址:https://github.com/YunaiV/ruoyi-vue-pro
- 視頻教程:https://doc.iocoder.cn/video/
2. 數據源切換原理
通過擴展Spring提供的抽象類AbstractRoutingDataSource
,可以實現切換數據源。其類結構如下圖所示:
- targetDataSources&defaultTargetDataSource
項目上需要使用的所有數據源和默認數據源。
- resolvedDataSources&resolvedDefaultDataSource
當Spring容器創建AbstractRoutingDataSource
對象時,通過調用afterPropertiesSet
復制上述目標數據源。由此可見,一旦數據源實例對象創建完畢,業務無法再添加新的數據源。
- determineCurrentLookupKey
此方法為抽象方法,通過擴展這個方法來實現數據源的切換。目標數據源的結構為:Map
其key為lookup key
。
我們來看官方對這個方法的注釋:
lookup key通常是綁定在線程上下文中,根據這個key去resolvedDataSources
中取出DataSource。
根據目標數據源的管理方式不同,可以使用基于配置文件和數據庫表兩種方式。基于配置文件管理方案無法后續添加新的數據源,而基于數據庫表方案管理,則更加靈活。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序,支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能
3. 配置文件解決方案
根據上面的分析,我們可以按照下面的步驟去實現:
-
定義
DynamicDataSource
類繼承AbstractRoutingDataSource
,重寫determineCurrentLookupKey()
方法。 -
配置多個數據源注入
targetDataSources
和defaultTargetDataSource
,通過afterPropertiesSet()
方法將數據源寫入resolvedDataSources
和resolvedDefaultDataSource
。 -
調用
AbstractRoutingDataSource
的getConnection()
方法時,determineTargetDataSource()
方法返回DataSource
執行底層的getConnection()
。
其流程如下圖所示:
3.1 創建數據源
DynamicDataSource
數據源的注入,目前業界主流實現步驟如下:
在配置文件中定義數據源
spring.datasource.type=com.alibaba.druid.pool.DruidDataSource
spring.datasource.driverClassName=com.mysql.jdbc.Driver
#主數據源
spring.datasource.druid.master.url=jdbcUrl
spring.datasource.druid.master.username=***
spring.datasource.druid.master.password=***
#其他數據源
spring.datasource.druid.second.url=jdbcUrl
spring.datasource.druid.second.username=***
spring.datasource.druid.second.password=***
在代碼中配置Bean
@Configuration
publicclassDynamicDataSourceConfig{
@Bean
@ConfigurationProperties("spring.datasource.druid.master")
publicDataSourcefirstDataSource(){
returnDruidDataSourceBuilder.create().build();
}
@Bean
@ConfigurationProperties("spring.datasource.druid.second")
publicDataSourcesecondDataSource(){
returnDruidDataSourceBuilder.create().build();
}
@Bean
@Primary
publicDynamicDataSourcedataSource(DataSourcefirstDataSource,DataSourcesecondDataSource){
Map
3.2 AOP處理
通過DataSourceAspect
切面技術來簡化業務上的使用,只需要在業務方法添加@SwitchDataSource
注解即可完成動態切換:
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public@interfaceSwitchDataSource{
Stringvalue();
}
DataSourceAspect
攔截業務方法,更新當前線程上下文DataSourceContextHolder
中存儲的key,即可實現數據源切換。
3.3 方案不足
基于AbstractRoutingDataSource
的多數據源動態切換,有個明顯的缺點,無法動態添加和刪除數據源。在我們的產品中,不能把應用數據源寫死在配置文件。接下來分享一下基于數據庫表的實現方案。
4. 數據庫表解決方案
我們需要實現可視化的數據源管理,并實時查看數據源的運行狀態。所以我們不能把數據源全部配置在文件中,應該將數據源定義保存到數據庫表。參考AbstractRoutingDataSource
的設計思路,實現自定義數據源管理。
4.1 設計數據源表
主庫的數據源信息仍然配置在項目配置文件中,應用庫數據源配置參數,則設計對應的數據表。表結構如下所示:
這個表主要就是DataSource
的相關配置參數,其相應的ORM操作代碼在此不再贅述,主要是實現數據源的增刪改查操作。
4.2 自定義數據源管理
4.2.1 定義管理接口
通過繼承AbstractDataSource
即可實現DynamicDataSource
。為了方便對數據源進行操作,我們定義一個接口DataSourceManager
,為業務提供操作數據源的統一接口。
publicinterfaceDataSourceManager{
voidput(Stringvar1,DataSourcevar2);
DataSourceget(Stringvar1);
BooleanhasDataSource(Stringvar1);
voidremove(Stringvar1);
voidcloseDataSource(Stringvar1);
Collectionall() ;
}
該接口主要是對數據表中定義的數據源,提供基礎管理功能。
4.2.2 自定義數據源
DynamicDataSource
的實現如下圖所示:
根據前面的分析,AbstractRoutingDataSource
是在容器啟動的時候,執行afterPropertiesSet
注入數據源對象,完成之后無法對數據源進行修改。DynamicDataSource
則實現DataSourceManager
接口,可以將數據表中的數據源加載到dataSources。
4.2.3 切面處理
這一塊的處理跟配置文件數據源方案處理方式相同,都是通過AOP技術切換lookup key。
publicDataSourcedetermineTargetDataSource(){
StringlookupKey=DataSourceContextHolder.getKey();
DataSourcedataSource=Optional.ofNullable(lookupKey)
.map(dataSources::get)
.orElse(defaultDataSource);
if(dataSource==null){
thrownewIllegalStateException("CannotdetermineDataSourceforlookupkey["+lookupKey+"]");
}
returndataSource;
}
4.2.4 管理數據源狀態
在項目啟動的時候,加載數據表中的所有數據源,并執行初始化。初始化操作主要是使用SpringBoot提供的DataSourceBuilder
類,根據數據源表的定義創建DataSource。在項目運行過程中,可以使用定時任務對數據源進行?;?,為了提升性能再添加一層緩存。
AbstractRoutingDataSource
只支持單庫事務,切換數據源是在開啟事務之前執行。 Spring使用 DataSourceTransactionManager
進行事務管理。開啟事務,會將數據源緩存到DataSourceTransactionObject
對象中,后續的commit和 rollback事務操作實際上是使用的同一個數據源。
如何解決切庫事務問題?借助Spring的聲明式事務處理,我們可以在多次切庫操作時強制開啟新的事務:
@SwitchDataSource
@Transactional(rollbackFor=Exception.class,propagation=Propagation.REQUIRES_NEW)
這樣的話,執行切庫操作的時候強制啟動新事務,便可實現多次切庫而且事務能夠生效。但是這種事務方式,存在數據一致性問題:
假若ServiceB正常執行提交事務,接著返回ServiceA執行并且發生異常。因為兩次處理是不同的事務,ServiceA這個事務執行回滾,而ServiceA事務已經提交。這樣的話,數據就不一致了。接下來,我們主要討論如何解決多庫的事務問題。
6. 多庫事務處理
6.1 關于事務的理解
首先有必要理解事務的本質。
1.提到Spring事務,就離不開事務的四大特性和隔離級別、七大傳播特性。
事務特性和離級別是屬于數據庫范疇。Spring事務的七大傳播特性是什么呢?它是Spring在當前線程內,處理多個事務操作時的事務應用策略,數據庫事務本身并不存在傳播特性。
2.Spring事務的定義包括:begin、commit、rollback、close、suspend、resume等動作。
-
begin(事務開始): 可以認為存在于數據庫的命令中,比如Mysql的
start transaction
命令,但是在JDBC編程方式中不存在。 -
close(事務關閉): Spring事務的close()方法,是把
Connection
對象歸還給數據庫連接池,與事務無關。 -
suspend(事務掛起): Spring中事務掛起的語義是:需要新事務時,將現有的
Connection
保存起來(還有尚未提交的事務),然后創建新的Connection2
,Connection2
提交、回滾、關閉完畢后,再把Connection1
取出來繼續執行。 - resume(事務恢復): 嵌套事務執行完畢,返回上層事務重新綁定連接對象到事務管理器的過程。
實際上,只有commit、rollback、close是在JDBC真實存在的,而其他動作都是應用的語意,而非JDBC事務的真實命令。因此,事務真實存在的方法是:setAutoCommit()
、commit()
、rollback()
。
close()語義為:
- 關閉一個數據庫連接,這已經不再是事務的方法了。
使用DataSource并不會執行物理關閉,只是歸還給連接池。
6.2 自定義管理事務
為了保證在多個數據源中事務的一致性,我們可以手動管理Connetion
的事務提交和回滾。考慮到不同ORM框架的事務管理實現差異,要求實現自定義事務管理不影響框架層的事務。
這可以通過使用裝飾器設計模式,對Connection
進行包裝重寫commit和rolllback屏蔽其默認行為,這樣就不會影響到原生Connection
和ORM框架的默認事務行為。其整體思路如下圖所示:
這里并沒有使用前面提到的@SwitchDataSource
,這是因為我們在TransactionAop
中已經執行了lookupKey的切換。
6.2.1 定義多事務注解
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public@interfaceMultiTransaction{
StringtransactionManager()default"multiTransactionManager";
//默認數據隔離級別,隨數據庫本身默認值
IsolationLevelisolationLevel()defaultIsolationLevel.DEFAULT;
//默認為主庫數據源
StringdatasourceId()default"default";
//只讀事務,若有更新操作會拋出異常
booleanreadOnly()defaultfalse;
業務方法只需使用該注解即可開啟事務,datasourceId
指定事務用到的數據源,不指定默認為主庫。
6.2.3 包裝Connection
自定義事務我們使用包裝過的Connection
,屏蔽其中的commit&rollback
方法。這樣我們就可以在主事務里進行統一的事務提交和回滾操作。
publicclassConnectionProxyimplementsConnection{
privatefinalConnectionconnection;
publicConnectionProxy(Connectionconnection){
this.connection=connection;
}
@Override
publicvoidcommit()throwsSQLException{
//connection.commit();
}
publicvoidrealCommit()throwsSQLException{
connection.commit();
}
@Override
publicvoidclose()throwsSQLException{
//connection.close();
}
publicvoidrealClose()throwsSQLException{
if(!connection.getAutoCommit()){
connection.setAutoCommit(true);
}
connection.close();
}
@Override
publicvoidrollback()throwsSQLException{
if(!connection.isClosed())
connection.rollback();
}
...
}
這里commit&close
方法不執行操作,rollback執行的前提是連接執行close才生效。這樣不管是使用哪個ORM框架,其自身事務管理都將失效。事務的控制就交由MultiTransaction
控制了。
6.2.4 事務上下文管理
publicclassTransactionHolder{
//是否開啟了一個MultiTransaction
privatebooleanisOpen;
//是否只讀事務
privatebooleanreadOnly;
//事務隔離級別
privateIsolationLevelisolationLevel;
//維護當前線程事務ID和連接關系
privateConcurrentHashMapconnectionMap;
//事務執行棧
privateStackexecuteStack;
//數據源切換棧
privateStackdatasourceKeyStack;
//主事務ID
privateStringmainTransactionId;
//執行次數
privateAtomicIntegertransCount;
//事務和數據源key關系
privateConcurrentHashMapexecuteIdDatasourceKeyMap;
}
每開啟一個事物,生成一個事務ID并綁定一個ConnectionProxy
。事務嵌套調用,保存事務ID和lookupKey至棧中,當內層事務執行完畢執行pop。這樣的話,外層事務只需在棧中執行peek即可獲取事務ID和lookupKey。
6.2.5 數據源兼容處理
為了不影響原生事務的使用,需要重寫getConnection
方法。當前線程沒有啟動自定義事務,則直接從數據源中返回連接。
@Override
publicConnectiongetConnection()throwsSQLException{
TransactionHoldertransactionHolder=MultiTransactionManager.TRANSACTION_HOLDER_THREAD_LOCAL.get();
if(Objects.isNull(transactionHolder)){
returndetermineTargetDataSource().getConnection();
}
ConnectionProxyConnectionProxy=transactionHolder.getConnectionMap()
.get(transactionHolder.getExecuteStack().peek());
if(ConnectionProxy==null){
//沒開跨庫事務,直接返回
returndetermineTargetDataSource().getConnection();
}else{
transactionHolder.addCount();
//開了跨庫事務,從當前線程中拿包裝過的Connection
returnConnectionProxy;
}
}
6.2.6 切面處理
切面處理的核心邏輯是:維護一個嵌套事務棧,當業務方法執行結束,或者發生異常時,判斷當前棧頂事務ID是否為主事務ID。如果是的話這時候已經到了最外層事務,這時才執行提交和回滾。詳細流程如下圖所示:
packagecom.github.mtxn.transaction.aop;
importcom.github.mtxn.application.Application;
importcom.github.mtxn.transaction.MultiTransactionManager;
importcom.github.mtxn.transaction.annotation.MultiTransaction;
importcom.github.mtxn.transaction.context.DataSourceContextHolder;
importcom.github.mtxn.transaction.support.IsolationLevel;
importcom.github.mtxn.transaction.support.TransactionHolder;
importcom.github.mtxn.utils.ExceptionUtils;
importlombok.extern.slf4j.Slf4j;
importorg.aspectj.lang.ProceedingJoinPoint;
importorg.aspectj.lang.annotation.Around;
importorg.aspectj.lang.annotation.Aspect;
importorg.aspectj.lang.annotation.Pointcut;
importorg.aspectj.lang.reflect.MethodSignature;
importorg.springframework.core.annotation.Order;
importorg.springframework.stereotype.Component;
importjava.lang.reflect.Method;
@Aspect
@Component
@Slf4j
@Order(99999)
publicclassMultiTransactionAop{
@Pointcut("@annotation(com.github.mtxn.transaction.annotation.MultiTransaction)")
publicvoidpointcut(){
if(log.isDebugEnabled()){
log.debug("startintransactionpointcut...");
}
}
@Around("pointcut()")
publicObjectaroundTransaction(ProceedingJoinPointpoint)throwsThrowable{
MethodSignaturesignature=(MethodSignature)point.getSignature();
//從切面中獲取當前方法
Methodmethod=signature.getMethod();
MultiTransactionmultiTransaction=method.getAnnotation(MultiTransaction.class);
if(multiTransaction==null){
returnpoint.proceed();
}
IsolationLevelisolationLevel=multiTransaction.isolationLevel();
booleanreadOnly=multiTransaction.readOnly();
StringprevKey=DataSourceContextHolder.getKey();
MultiTransactionManagermultiTransactionManager=Application.resolve(multiTransaction.transactionManager());
//切數據源,如果失敗使用默認庫
if(multiTransactionManager.switchDataSource(point,signature,multiTransaction))returnpoint.proceed();
//開啟事務棧
TransactionHoldertransactionHolder=multiTransactionManager.startTransaction(prevKey,isolationLevel,readOnly,multiTransactionManager);
Objectproceed;
try{
proceed=point.proceed();
multiTransactionManager.commit();
}catch(Throwableex){
log.error("executemethod:{}#{},err:",method.getDeclaringClass(),method.getName(),ex);
multiTransactionManager.rollback();
throwExceptionUtils.api(ex,"系統異常:%s",ex.getMessage());
}finally{
//當前事務結束出棧
StringtransId=multiTransactionManager.getTrans().getExecuteStack().pop();
transactionHolder.getDatasourceKeyStack().pop();
//恢復上一層事務
DataSourceContextHolder.setKey(transactionHolder.getDatasourceKeyStack().peek());
//最后回到主事務,關閉此次事務
multiTransactionManager.close(transId);
}
returnproceed;
}
}
7.總結
本文主要介紹了多數據源管理的解決方案(應用層事務,而非XA二段提交保證),以及對多個庫同時操作的事務管理。
需要注意的是,這種方式只適用于單體架構的應用。因為多個庫的事務參與者都是運行在同一個JVM進行。如果是在微服務架構的應用中,則需要使用分布式事務管理(譬如:Seata)。
審核編輯 :李倩
-
spring
+關注
關注
0文章
340瀏覽量
14353 -
數據源
+關注
關注
1文章
63瀏覽量
9688 -
微服務
+關注
關注
0文章
137瀏覽量
7360 -
SpringBoot
+關注
關注
0文章
173瀏覽量
183
原文標題:SpringBoot 多數據源及事務解決方案
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論