分布式事務(wù)框架Seata客戶端的使用
Seata (Simple Extensible Autonomous Transaction Architecture) 是一種開(kāi)源的分布式事務(wù)解決方案,致力于在微服務(wù)架構(gòu)下提供高效且對(duì)業(yè)務(wù)無(wú)侵入的分布式事務(wù)服務(wù)。Seata 能夠幫助開(kāi)發(fā)者輕松地解決在微服務(wù)架構(gòu)下服務(wù)間的數(shù)據(jù)一致性問(wèn)題。
圖片
在分布式系統(tǒng)中,一個(gè)業(yè)務(wù)操作通常會(huì)涉及到多個(gè)服務(wù)的協(xié)作,這些服務(wù)可能會(huì)對(duì)不同的數(shù)據(jù)庫(kù)進(jìn)行操作。傳統(tǒng)的分布式事務(wù)解決方案(如2PC,即兩階段提交)雖然能夠保證強(qiáng)一致性,但卻在性能和可用性方面存在不小的挑戰(zhàn)。因此,Seata 提出了一種基于AT、TCC、SAGA、XA等模式的輕量級(jí)分布式事務(wù)協(xié)調(diào)方案。
Seata 確實(shí)支持多種分布式事務(wù)模式,包括 AT(自動(dòng)補(bǔ)償事務(wù))、TCC(Try-Confirm-Cancel)、SAGA 和 XA(擴(kuò)展的兩階段提交協(xié)議)。每種模式都有自己的使用場(chǎng)景和特點(diǎn):
1. AT模式(Auto-Compensating Transaction)
圖片
- 適用場(chǎng)景:簡(jiǎn)單的CRUD操作,不需要特殊處理的業(yè)務(wù)邏輯。
- 特點(diǎn):
易于使用,開(kāi)發(fā)者不需要編寫(xiě)額外的補(bǔ)償邏輯,Seata 會(huì)自動(dòng)為每個(gè)分支事務(wù)生成撤銷(xiāo)(回滾)邏輯。
性能較好,因?yàn)樗鼫p少了準(zhǔn)備階段的通信開(kāi)銷(xiāo)。
通過(guò)行鎖和UNDO_LOG(回濾日志),加鎖和數(shù)據(jù)改動(dòng)被記錄下來(lái),保證在出現(xiàn)錯(cuò)誤時(shí)可以回滾事務(wù)。
@Service
public class OrderService {
@GlobalTransactional(timeoutMills = 300000, name = "create-order")
public void createOrder(Order order, Payment payment, Inventory inventory) {
// 更新庫(kù)存
inventoryService.reduceStock(inventory);
// 創(chuàng)建支付記錄
paymentService.pay(payment);
// 創(chuàng)建訂單
orderRepository.save(order);
}
}
按照官方配置AT模式后,在方法前面添加GlobalTransactional注解。
AT模式的主要思想就是通過(guò)一個(gè)中間層進(jìn)行協(xié)調(diào)事務(wù)的確認(rèn)和回滾操作,將相應(yīng)的操作記錄在例如數(shù)據(jù)庫(kù)表里面,在提交后進(jìn)行事務(wù)的信息的刪除,再通過(guò)一個(gè)全局鎖來(lái)避免資源的競(jìng)爭(zhēng)。其方式對(duì)業(yè)務(wù)代碼不需要侵入。
2. TCC模式(Try-Confirm-Cancel)
圖片
- 適用場(chǎng)景:業(yè)務(wù)邏輯較為復(fù)雜,或者需要明確的業(yè)務(wù)補(bǔ)償操作。
- 特點(diǎn):
分為三個(gè)操作:Try(嘗試執(zhí)行業(yè)務(wù))、Confirm(確認(rèn)執(zhí)行業(yè)務(wù))、Cancel(取消執(zhí)行業(yè)務(wù)),業(yè)務(wù)邏輯被拆分成這三部分。
開(kāi)發(fā)者需要自行實(shí)現(xiàn)這三個(gè)操作,提供更強(qiáng)的業(yè)務(wù)手動(dòng)控制能力。
具體的業(yè)務(wù)操作和補(bǔ)償邏輯是可見(jiàn)的,有助于處理復(fù)雜的業(yè)務(wù)場(chǎng)景。
//定義接口實(shí)現(xiàn)注解
@LocalTCC
public interface PaymentService {
// "try" 方法,準(zhǔn)備資源,比如凍結(jié)用戶資金
@TwoPhaseBusinessAction(name = "preparePay", commitMethod = "commitPay", rollbackMethod = "cancelPay")
boolean preparePay(BusinessActionContext context, String accountId, double amount);
// "confirm" 方法,確認(rèn)并實(shí)際扣除凍結(jié)的資金
boolean commitPay(BusinessActionContext context);
// "cancel" 方法,取消操作,解凍之前凍結(jié)的資金
boolean cancelPay(BusinessActionContext context);
}
//然后,為接口提供一個(gè)實(shí)現(xiàn)類(lèi),并實(shí)現(xiàn)try、confirm和cancel方法:
@Service
public class PaymentServiceImpl implements PaymentService {
@Autowired
private AccountRepository accountRepository;
@Override
public boolean preparePay(BusinessActionContext context, String accountId, double amount) {
// 實(shí)現(xiàn)資金的凍結(jié)邏輯
// ...
return true;
}
@Override
public boolean commitPay(BusinessActionContext context) {
// 實(shí)現(xiàn)實(shí)際扣除資金的邏輯
// ...
return true;
}
@Override
public boolean cancelPay(BusinessActionContext context) {
// 實(shí)現(xiàn)取消扣款,即解凍資金的邏輯
// ...
return true;
}
}
//最后,在需要執(zhí)行TCC事務(wù)的業(yè)務(wù)邏輯中注入PaymentService并調(diào)用上述方法:
@Service
public class OrderService {
@Autowired
private PaymentService paymentService;
@GlobalTransactional
public void createOrder(Order order, String accountId, double amount) {
// TCC try 階段
boolean result = paymentService.preparePay(null, accountId, amount);
if (!result) {
throw new RuntimeException("Payment preparation failed.");
}
// TCC confirm 或 cancel 階段將由Seata框架根據(jù)全局事務(wù)的最終狀態(tài)自動(dòng)調(diào)用
// ...
}
}
其本質(zhì)的思想就是通過(guò)代碼編寫(xiě)確認(rèn)機(jī)制和補(bǔ)償機(jī)制,這種方式需要對(duì)業(yè)務(wù)的代碼的侵入。
3. SAGA模式
- 適用場(chǎng)景:長(zhǎng)事務(wù)場(chǎng)景,例如一系列的步驟或服務(wù)調(diào)用需要在整體上保持一致性。
- 特點(diǎn):
基于狀態(tài)機(jī)實(shí)現(xiàn),每個(gè)步驟都對(duì)應(yīng)狀態(tài)遷移過(guò)程中的一個(gè)節(jié)點(diǎn)。
不適用于標(biāo)準(zhǔn)的兩階段提交,而是將一個(gè)全局事務(wù)分解成多個(gè)局部事務(wù),通過(guò)定義前向操作和反向補(bǔ)償操作來(lái)保證整體一致性。
適用于事務(wù)執(zhí)行時(shí)間較長(zhǎng)的業(yè)務(wù)流程,減少了鎖資源的持有時(shí)間。
// 偽代碼,僅為示例說(shuō)明
StateMachineBuilder stateMachineBuilder = StateMachineBuilderFactory.create();
StateMachine stateMachine = stateMachineBuilder
.state("Start")
.initial("CreateOrder")
.to("ReserveInventory").on("InventoryReserved")
.to("CancelOrder").on("InventoryReserveFailed")
.step("ReserveInventory")
.to("ProcessPayment").on("PaymentProcessed")
.to("RevertInventory").on("PaymentProcessFailed")
.step("ProcessPayment")
.to("End").on("Success")
.step("CancelOrder")
.compensateWith("CancelOrderOperation")
.step("RevertInventory")
.compensateWith("RevertInventoryOperation")
.build();
stateMachine.start();
使用狀態(tài)機(jī)來(lái)進(jìn)行多事務(wù)的描述其本質(zhì)的思想就是對(duì)多事務(wù)進(jìn)行確認(rèn)和補(bǔ)償,這種也會(huì)需要對(duì)業(yè)務(wù)代碼的侵入。
4. XA模式
圖片
- 適用場(chǎng)景:需要嚴(yán)格的ACID事務(wù),并且各參與方(數(shù)據(jù)庫(kù)、消息中間件等)支持XA接口。
- 特點(diǎn):
基于兩階段提交(2PC),第一階段是準(zhǔn)備階段,第二階段是提交或回濾階段。
實(shí)現(xiàn)了跨資源管理器的全局事務(wù)。
通常比AT模式效率低,因?yàn)樗诘谝浑A段結(jié)束時(shí)需要所有參與者就事務(wù)結(jié)果達(dá)成一致,然后在第二階段進(jìn)行提交或回滾。
將動(dòng)態(tài)的代理數(shù)據(jù)源替換成XA模式,然后和AT模式一樣,在需要的方法前面添加GlobalTransactional注解
@Service
public class OrderService {
@Autowired
private OrderRepository orderRepository;
@GlobalTransactional
public void createOrder(Order order) {
// 此處的數(shù)據(jù)庫(kù)操作會(huì)自動(dòng)被Seata管理
orderRepository.save(order);
// ...其他可能涉及數(shù)據(jù)庫(kù)操作的代碼
}
}
其本質(zhì)的思想就是與AT模式類(lèi)似,但是需要基于數(shù)據(jù)庫(kù)能支持XA模式才能運(yùn)行,AT模式是在中間層進(jìn)行確認(rèn)和回滾的日志記錄,而XA模式是將記錄交給數(shù)據(jù)庫(kù)來(lái)運(yùn)行,也避免了AT模式下手動(dòng)操作數(shù)據(jù)導(dǎo)致問(wèn)題。XA模式不需要侵入業(yè)務(wù)代碼。
圖片
在選用分布式事務(wù)模式時(shí),需要根據(jù)具體業(yè)務(wù)場(chǎng)景和對(duì)一致性的需求做出選擇。每種模式都有其優(yōu)勢(shì)和局限,沒(méi)有絕對(duì)的“最佳”選擇。對(duì)于開(kāi)發(fā)者來(lái)說(shuō),了解各模式的內(nèi)部機(jī)制和可能的性能影響是非常重要的。