- 1. 什么是全局事務(wù)呢?
- 2. 2pc提交協(xié)議
- 3. XA事務(wù)存在的問(wèn)題
- 4. CAP理論
- 5. Sharding-JDBC分布式事務(wù)支持
- 6. 項(xiàng)目地址
在我們使用Sharding JDBC分庫(kù)分表的時(shí)候,會(huì)帶來(lái)另外一個(gè)問(wèn)題,就是分布式事務(wù)問(wèn)題,如下圖所示。用戶采購(gòu)商品業(yè)務(wù),整個(gè)業(yè)務(wù)包含3個(gè)微服務(wù):
- 庫(kù)存服務(wù): 扣減給定商品的庫(kù)存數(shù)量。
- 訂單服務(wù): 根據(jù)采購(gòu)請(qǐng)求生成訂單。
- 賬戶服務(wù): 用戶賬戶金額扣減。
這三個(gè)業(yè)務(wù)操作應(yīng)該屬于同一個(gè)事務(wù),但是這些數(shù)據(jù)卻分配在不同的數(shù)據(jù)庫(kù)上,所以沒(méi)辦法采用數(shù)據(jù)庫(kù)的事務(wù)來(lái)保證數(shù)據(jù)一致性。
這個(gè)時(shí)候,要解決分布式事務(wù)問(wèn)題,就需要引入全局事務(wù)。
1. 什么是全局事務(wù)呢?
全局事務(wù)是一個(gè)DTP模型的事務(wù),所謂DTP模型指的是 X/Open DTP (X/Open Distributed Transaction Processing Reference Model
),是 X/Open 這個(gè)組織定義的一套分布式事務(wù)的標(biāo)準(zhǔn)。
X/Open,即現(xiàn)在的open group,是一個(gè)獨(dú)立的組織,主要負(fù)責(zé)制定各種行業(yè)技術(shù)標(biāo)準(zhǔn)。
官網(wǎng)地址:http://www.opengroup.org/
X/Open組織主要由各大知名公司或者廠商進(jìn)行支持,這些組織不光遵循X/Open組織定義的行業(yè)技術(shù)標(biāo)準(zhǔn),也參與到標(biāo)準(zhǔn)的制定。
X/Open了定義了規(guī)范和API接口,由這個(gè)廠商進(jìn)行具體的實(shí)現(xiàn),這個(gè)標(biāo)準(zhǔn)提出了使用二階段提交(2PC –Two-Phase-Commit
)來(lái)保證分布式事務(wù)的完整性。后來(lái)J2EE也遵循了X/OpenDTP規(guī)范,設(shè)計(jì)并實(shí)現(xiàn)了java里的分布式事務(wù)編程接口規(guī)范-JTA,如下圖所示,表示一個(gè)X/Open DTP模型。
X/Open DTP模型定義了三個(gè)角色和兩個(gè)協(xié)議,其中三個(gè)角色分別如下:
- AP(Application Program) ,表示應(yīng)用程序,也可以理解成使用DTP模型的程序
- RM(Resource Manager) ,資源管理器,這個(gè)資源可以是數(shù)據(jù)庫(kù), 應(yīng)用程序通過(guò)資源管理器對(duì)資源進(jìn)行控制,資源管理器必須實(shí)現(xiàn)XA定義的接口
- TM(Transaction Manager) ,表示事務(wù)管理器,負(fù)責(zé)協(xié)調(diào)和管理全局事務(wù),事務(wù)管理器控制整個(gè)全局事務(wù),管理事務(wù)的生命周期,并且協(xié)調(diào)資源。
兩個(gè)協(xié)議分別是:
XA協(xié)議: XA 是X/Open DTP定義的資源管理器和事務(wù)管理器之間的接口規(guī)范,TM用它來(lái)通知和協(xié)調(diào)相關(guān)RM事務(wù)的開(kāi)始、結(jié)束、提交或回滾。
目前Oracle、Mysql、DB2都提供了對(duì)XA的支持;XA接口是雙向的系統(tǒng)接口,在事務(wù)管理器(TM ) 以及多個(gè)資源管理器之間形成通信的橋梁(XA不能自動(dòng) 提交)
- https://dev.mysql.com/doc/refman/8.0/en/xa.html
- https://dev.mysql.com/doc/refman/8.0/en/xa-statements.html
XA協(xié)議的語(yǔ)法,主流的數(shù)據(jù)庫(kù)都支持 XA協(xié)議,從而能夠?qū)崿F(xiàn)跨數(shù)據(jù)庫(kù)事務(wù)。
XA{START|BEGIN}xid[JOIN|RESUME]--負(fù)責(zé)開(kāi)啟或者恢復(fù)一個(gè)事務(wù)分支,并且管理XID到調(diào)用線程
XAENDxid[SUSPEND[FORMIGRATE]]--負(fù)責(zé)取消當(dāng)前線程與事務(wù)分支的關(guān)聯(lián)
XAPREPARExid--負(fù)責(zé)詢問(wèn)RM是否準(zhǔn)備好了提交事務(wù)分支
XACOMMITxid[ONEPHASE]--知RM提交事務(wù)分支
XAROLLBACKxid--通知RM回滾事務(wù)分支
XARECOVER[CONVERTXID]
TX協(xié)議: 全局事務(wù)管理器與資源管理器之間通信的接口
在分布式系統(tǒng)中,每一個(gè)機(jī)器節(jié)點(diǎn)雖然都能夠明確知道自己在進(jìn)行事務(wù)操作過(guò)程中的結(jié)果是成功還是失敗,但卻無(wú)法直接獲取到其他分布式節(jié)點(diǎn)的操作結(jié)果。
因此當(dāng)一個(gè)事務(wù)操作需要跨越多個(gè)分布式節(jié)點(diǎn)的時(shí)候,為了保持事務(wù)處理的ACID特性,就需要引入一個(gè)“協(xié)調(diào)者”(TM)來(lái)統(tǒng)一調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行邏輯,這些被調(diào)度的分布式節(jié)點(diǎn)被稱為AP。TM負(fù)責(zé)調(diào)度AP的行為,并最終決定這些AP是否要把事務(wù)真正進(jìn)行提交到(RM)。
基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序,支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
- 項(xiàng)目地址:https://github.com/YunaiV/ruoyi-vue-pro
- 視頻教程:https://doc.iocoder.cn/video/
2. 2pc提交協(xié)議
在X/OpenDTP模型中,一個(gè)分布式事務(wù)所涉及的SQL邏輯都執(zhí)行完成,并到了(RM)要最后提交事務(wù)的關(guān)鍵時(shí)刻,為了避免分布式系統(tǒng)所固有的不可靠性導(dǎo)致提交事務(wù)意外失敗,TM 果斷決定實(shí)施兩步走的方案,這個(gè)就稱為二階提交,如下圖所示。
二階段提交,是計(jì)算機(jī)網(wǎng)絡(luò)尤其是在數(shù)據(jù)庫(kù)領(lǐng)域內(nèi),為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點(diǎn)在進(jìn)行事務(wù)處理過(guò)程中能夠保持原子性和一致性而設(shè)計(jì)的一種算法。通常,二階段提交協(xié)議也被認(rèn)為是一種一致性協(xié)議,用來(lái)保證分布式系統(tǒng)數(shù)據(jù)的一致性。
目前,絕大部分的關(guān)系型數(shù)據(jù)庫(kù)都是采用二階段提交協(xié)議來(lái)完成分布式事務(wù)處理的,利用該協(xié)議能夠非常方便地完成所有分布式事務(wù)AP的協(xié)調(diào),統(tǒng)一決定事務(wù)的提交或回滾,從而能夠有效保證分布式數(shù)據(jù)一致性,因此2pc也被廣泛運(yùn)用在許多分布式系統(tǒng)中。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序,支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
3. XA事務(wù)存在的問(wèn)題
上述基于XA協(xié)議的全局事務(wù),是屬于強(qiáng)一致性事務(wù),因?yàn)樵谌质聞?wù)中,只要有任何一個(gè)RM出現(xiàn)異常,都會(huì)導(dǎo)致全局事務(wù)回滾。同時(shí),本地事務(wù)在Prepare階段鎖定資源時(shí),如果有其他事務(wù)要要修改相同的數(shù)據(jù),就必須要等待前面的事務(wù)完成,這本身是無(wú)可厚非的設(shè)計(jì),但是由于多個(gè)RM節(jié)點(diǎn)是跨網(wǎng)絡(luò),一旦出現(xiàn)網(wǎng)絡(luò)延遲,就導(dǎo)致該事務(wù)一直占用資源使得整體性能下降。
另外,在XA COMMIT階段,如果其中一個(gè)RM因?yàn)榫W(wǎng)絡(luò)超時(shí)沒(méi)有收到數(shù)據(jù)提交的指令,會(huì)導(dǎo)致數(shù)據(jù)不一致,為了解決這個(gè)問(wèn)題,很多開(kāi)源分布式事務(wù)框架都會(huì)提供重試機(jī)制來(lái)保證數(shù)據(jù)一致性。
4. CAP理論
說(shuō)到強(qiáng)一致性的問(wèn)題,必然要提到CAP理論。
CAP的含義:
- C:Consistency 一致性 同一數(shù)據(jù)的多個(gè)副本是否實(shí)時(shí)相同。
- A:Availability 可用性 可用性:一定時(shí)間內(nèi) & 系統(tǒng)返回一個(gè)明確的結(jié)果 則稱為該系統(tǒng)可用。
- P:Partition tolerance 分區(qū)容錯(cuò)性 將同一服務(wù)分布在多個(gè)系統(tǒng)中,從而保證某一個(gè)系統(tǒng)宕機(jī),仍然有其他系統(tǒng)提供相同的服務(wù)。
CAP理論告訴我們,在分布式系統(tǒng)中,C、A、P三個(gè)條件中我們最多只能選擇兩個(gè)。那么問(wèn)題來(lái)了,究竟選擇哪兩個(gè)條件較為合適呢?
對(duì)于一個(gè)業(yè)務(wù)系統(tǒng)來(lái)說(shuō),分區(qū)容錯(cuò)性是必須要滿足的條件。業(yè)務(wù)系統(tǒng)之所以使用分布式系統(tǒng),主要原因有兩個(gè):
- 提升整體性能 當(dāng)業(yè)務(wù)量猛增,單個(gè)服務(wù)器已經(jīng)無(wú)法滿足我們的業(yè)務(wù)需求的時(shí)候,就需要使用分布式系統(tǒng),使用多個(gè)節(jié)點(diǎn)提供相同的功能,從而整體上提升系統(tǒng)的性能,這就是使用分布式系統(tǒng)的第一個(gè)原因。
- 實(shí)現(xiàn)分區(qū)容錯(cuò)性 單一節(jié)點(diǎn) 或 多個(gè)節(jié)點(diǎn)處于相同的網(wǎng)絡(luò)環(huán)境下,那么會(huì)存在一定的風(fēng)險(xiǎn),萬(wàn)一該機(jī)房斷電、該地區(qū)發(fā)生自然災(zāi)害,那么業(yè)務(wù)系統(tǒng)就全面癱瘓了。為了防止這一問(wèn)題,采用分布式系統(tǒng),將多個(gè)子系統(tǒng)分布在不同的地域、不同的機(jī)房中,從而保證系統(tǒng)高可用性。
所以我們需要根據(jù)自己的業(yè)務(wù)需求,選擇采取CP還是AP。
5. Sharding-JDBC分布式事務(wù)支持
了解了X/Open DTP模型的全局事務(wù)解決方案,就必然需要一個(gè)成熟的技術(shù)中間件來(lái)簡(jiǎn)化我們對(duì)于分布式事務(wù)的開(kāi)發(fā)邏輯,而Sharding-JDBC提供了分布式事務(wù)解決方案。
Sharding-JDBC支持以下四種事務(wù)模型,實(shí)際上這些分布式事務(wù)模式都是集成開(kāi)源的事務(wù)組件做的集成。
- Atomikos事務(wù)
- Narayana事務(wù)
- Bitronix事務(wù)
- Seata事務(wù)
Apache ShardingSphere 默認(rèn)的 XA 事務(wù)管理器為 Atomikos,下面我們通過(guò)Atomikos來(lái)配置一個(gè)分布式事務(wù)的使用模型。
5.1 Atomikos事務(wù)
Atomikos是為Java平臺(tái)提供的開(kāi)源的事務(wù)管理工具,它包含收費(fèi)和開(kāi)源兩個(gè)版本,開(kāi)源版本基本能滿足我們的需求。
Atomikos實(shí)現(xiàn)了JTA/XA規(guī)范中的事務(wù)管理器(Transaction Manager
)應(yīng)該實(shí)現(xiàn)的相關(guān)接口。
JTA,即Java Transaction API
,JTA允許應(yīng)用程序執(zhí)行分布式事務(wù)處理——在兩個(gè)或多個(gè)網(wǎng)絡(luò)計(jì)算機(jī)資源上訪問(wèn)并且更新數(shù)據(jù),JDBC驅(qū)動(dòng)程序的JTA支持極大地增強(qiáng)了數(shù)據(jù)訪問(wèn)能力。
-
TransactionManager : 常用方法,可以開(kāi)啟、回滾、獲取事務(wù)。
begin(),rollback()…
-
XAResouce : 資源管理,通過(guò)Session來(lái)進(jìn)行事務(wù)管理。
commit(xid)…
- XID : 每一個(gè)事務(wù)都分配一個(gè)特定的XID
JTA是如何實(shí)現(xiàn)多數(shù)據(jù)源的事務(wù)管理呢?
主要的原理是兩階段提交,以上面的請(qǐng)求業(yè)務(wù)為例,當(dāng)整個(gè)業(yè)務(wù)完成了之后只是第一階段提交,在第二階段提交之前會(huì)檢查其他所有事務(wù)是否已經(jīng)提交,如果前面出現(xiàn)了錯(cuò)誤或是沒(méi)有提交,那么第二階段就不會(huì)提交,而是直接rollback操作,這樣所有的事務(wù)都會(huì)做Rollback操作。
5.2 實(shí)戰(zhàn)
5.2.1 項(xiàng)目搭建
使用IDEA直接創(chuàng)建Spring boot 項(xiàng)目即可。
5.2.2 依賴
由于使用XA事務(wù),所以除了Sharding依賴外還需要引入事務(wù)依賴。
<dependency>
<groupId>org.apache.shardingspheregroupId>
<artifactId>shardingsphere-jdbc-core-spring-boot-starterartifactId>
<version>5.0.0-alphaversion>
dependency>
<dependency>
<groupId>com.zaxxergroupId>
<artifactId>HikariCPartifactId>
<version>3.4.2version>
dependency>
<dependency>
<groupId>org.freemarkergroupId>
<artifactId>freemarkerartifactId>
dependency>
<dependency>
<groupId>org.apache.shardingspheregroupId>
<artifactId>shardingsphere-transaction-xa-coreartifactId>
<version>5.0.0-alphaversion>
dependency>
5.2.3 配置
接下來(lái)就是配置相關(guān)數(shù)據(jù)庫(kù)連接信息以及分片規(guī)則;
在這里主要做的是創(chuàng)建了兩個(gè)數(shù)據(jù)源(數(shù)據(jù)源最好設(shè)置兩臺(tái)服務(wù)器的數(shù)據(jù)庫(kù))以及設(shè)置好了相應(yīng)的分庫(kù)規(guī)則。
server.port=8080
spring.mvc.view.prefix=classpath:/templates/
spring.mvc.view.suffix=.html
spring.shardingsphere.props.sql-show=true
spring.shardingsphere.datasource.names="ds-0,ds-1"
spring.shardingsphere.datasource.common.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.common.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds-0.jdbc-url=jdbc//localhost:3306/shard01?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
spring.shardingsphere.datasource.ds-0.username=root
spring.shardingsphere.datasource.ds-0.password=123456
spring.shardingsphere.datasource.ds-1.jdbc-url=jdbc//localhost:3306/shard02?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
spring.shardingsphere.datasource.ds-1.username=root
spring.shardingsphere.datasource.ds-1.password=123456
spring.shardingsphere.rules.sharding.default-database-strategy.standard.sharding-column=user_id
spring.shardingsphere.rules.sharding.default-database-strategy.standard.sharding-algorithm-name=database-inline
spring.shardingsphere.rules.sharding.sharding-algorithms.database-inline.type=INLINE
spring.shardingsphere.rules.sharding.sharding-algorithms.database-inline.props.algorithm-expression=ds-$->{user_id % 2}
spring.shardingsphere.rules.sharding.tables.t_order.key-generate-strategy.column=order_id
spring.shardingsphere.rules.sharding.tables.t_order.key-generate-strategy.key-generator-name=snowflake
spring.shardingsphere.rules.sharding.key-generators.snowflake.type=SNOWFLAKE
spring.shardingsphere.rules.sharding.key-generators.snowflake.props.worker-id=123
5.2.4 事務(wù)一致性注解
Sharding jdbc解決事務(wù)一致性可以直接通過(guò)@ShardingTransactionType(TransactionType.XA)
注解實(shí)現(xiàn),我們只需要在對(duì)應(yīng)的方法上加上即可。
比如下圖,由于我們?cè)谂渲梦募惺峭ㄟ^(guò)user_id
進(jìn)行分庫(kù)的,然后我們?cè)谶@里通過(guò)隨機(jī)數(shù),會(huì)根據(jù)分片規(guī)則往兩個(gè)數(shù)據(jù)庫(kù)中插入數(shù)據(jù)。
當(dāng)i=4的時(shí)候,我們?nèi)藶榈闹圃飚惓?,如果我們不采用全局事?wù)的話,則之前插入的數(shù)據(jù)還會(huì)再數(shù)據(jù)庫(kù)中。所以這個(gè)時(shí)候我們只需要加上@ShardingTransactionType(TransactionType.XA)
注解即可,XA屬于強(qiáng)一致性。
6. 項(xiàng)目地址
https://gitee.com/cl1429745331/sharding-jdbc-demo
審核編輯 :李倩
-
數(shù)據(jù)庫(kù)
+關(guān)注
關(guān)注
7文章
3712瀏覽量
64025 -
分布式
+關(guān)注
關(guān)注
1文章
824瀏覽量
74396 -
JDBC
+關(guān)注
關(guān)注
0文章
25瀏覽量
13368
原文標(biāo)題:Sharding JDBC 實(shí)戰(zhàn):分布式事務(wù)處理
文章出處:【微信號(hào):芋道源碼,微信公眾號(hào):芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論