分布式事務(wù)框架Seata客戶端的使用
Seata (Simple Extensible Autonomous Transaction Architecture) 是一種開源的分布式事務(wù)解決方案,致力于在微服務(wù)架構(gòu)下提供高效且對業(yè)務(wù)無侵入的分布式事務(wù)服務(wù)。Seata 能夠幫助開發(fā)者輕松地解決在微服務(wù)架構(gòu)下服務(wù)間的數(shù)據(jù)一致性問題。
圖片
在分布式系統(tǒng)中,一個(gè)業(yè)務(wù)操作通常會(huì)涉及到多個(gè)服務(wù)的協(xié)作,這些服務(wù)可能會(huì)對不同的數(shù)據(jù)庫進(jìn)行操作。傳統(tǒng)的分布式事務(wù)解決方案(如2PC,即兩階段提交)雖然能夠保證強(qiáng)一致性,但卻在性能和可用性方面存在不小的挑戰(zhàn)。因此,Seata 提出了一種基于AT、TCC、SAGA、XA等模式的輕量級分布式事務(wù)協(xié)調(diào)方案。
Seata 確實(shí)支持多種分布式事務(wù)模式,包括 AT(自動(dòng)補(bǔ)償事務(wù))、TCC(Try-Confirm-Cancel)、SAGA 和 XA(擴(kuò)展的兩階段提交協(xié)議)。每種模式都有自己的使用場景和特點(diǎn):
1. AT模式(Auto-Compensating Transaction)
圖片
- 適用場景:簡單的CRUD操作,不需要特殊處理的業(yè)務(wù)邏輯。
- 特點(diǎn):
易于使用,開發(fā)者不需要編寫額外的補(bǔ)償邏輯,Seata 會(huì)自動(dòng)為每個(gè)分支事務(wù)生成撤銷(回滾)邏輯。
性能較好,因?yàn)樗鼫p少了準(zhǔn)備階段的通信開銷。
通過行鎖和UNDO_LOG(回濾日志),加鎖和數(shù)據(jù)改動(dòng)被記錄下來,保證在出現(xiàn)錯(cuò)誤時(shí)可以回滾事務(wù)。
@Service
public class OrderService {
@GlobalTransactional(timeoutMills = 300000, name = "create-order")
public void createOrder(Order order, Payment payment, Inventory inventory) {
// 更新庫存
inventoryService.reduceStock(inventory);
// 創(chuàng)建支付記錄
paymentService.pay(payment);
// 創(chuàng)建訂單
orderRepository.save(order);
}
}
按照官方配置AT模式后,在方法前面添加GlobalTransactional注解。
AT模式的主要思想就是通過一個(gè)中間層進(jìn)行協(xié)調(diào)事務(wù)的確認(rèn)和回滾操作,將相應(yīng)的操作記錄在例如數(shù)據(jù)庫表里面,在提交后進(jìn)行事務(wù)的信息的刪除,再通過一個(gè)全局鎖來避免資源的競爭。其方式對業(yè)務(wù)代碼不需要侵入。
2. TCC模式(Try-Confirm-Cancel)
圖片
- 適用場景:業(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ù)邏輯被拆分成這三部分。
開發(fā)者需要自行實(shí)現(xiàn)這三個(gè)操作,提供更強(qiáng)的業(yè)務(wù)手動(dòng)控制能力。
具體的業(yè)務(wù)操作和補(bǔ)償邏輯是可見的,有助于處理復(fù)雜的業(yè)務(wù)場景。
//定義接口實(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)類,并實(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ì)的思想就是通過代碼編寫確認(rèn)機(jī)制和補(bǔ)償機(jī)制,這種方式需要對業(yè)務(wù)的代碼的侵入。
3. SAGA模式
- 適用場景:長事務(wù)場景,例如一系列的步驟或服務(wù)調(diào)用需要在整體上保持一致性。
- 特點(diǎn):
基于狀態(tài)機(jī)實(shí)現(xiàn),每個(gè)步驟都對應(yīng)狀態(tài)遷移過程中的一個(gè)節(jié)點(diǎn)。
不適用于標(biāo)準(zhǔn)的兩階段提交,而是將一個(gè)全局事務(wù)分解成多個(gè)局部事務(wù),通過定義前向操作和反向補(bǔ)償操作來保證整體一致性。
適用于事務(wù)執(zhí)行時(shí)間較長的業(yè)務(wù)流程,減少了鎖資源的持有時(shí)間。
// 偽代碼,僅為示例說明
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ī)來進(jìn)行多事務(wù)的描述其本質(zhì)的思想就是對多事務(wù)進(jìn)行確認(rèn)和補(bǔ)償,這種也會(huì)需要對業(yè)務(wù)代碼的侵入。
4. XA模式
圖片
- 適用場景:需要嚴(yán)格的ACID事務(wù),并且各參與方(數(shù)據(jù)庫、消息中間件等)支持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ù)庫操作會(huì)自動(dòng)被Seata管理
orderRepository.save(order);
// ...其他可能涉及數(shù)據(jù)庫操作的代碼
}
}
其本質(zhì)的思想就是與AT模式類似,但是需要基于數(shù)據(jù)庫能支持XA模式才能運(yùn)行,AT模式是在中間層進(jìn)行確認(rèn)和回滾的日志記錄,而XA模式是將記錄交給數(shù)據(jù)庫來運(yùn)行,也避免了AT模式下手動(dòng)操作數(shù)據(jù)導(dǎo)致問題。XA模式不需要侵入業(yè)務(wù)代碼。
圖片
在選用分布式事務(wù)模式時(shí),需要根據(jù)具體業(yè)務(wù)場景和對一致性的需求做出選擇。每種模式都有其優(yōu)勢和局限,沒有絕對的“最佳”選擇。對于開發(fā)者來說,了解各模式的內(nèi)部機(jī)制和可能的性能影響是非常重要的。