Spring事務(wù)長(zhǎng)了個(gè)腿?輕松掌握技巧告別長(zhǎng)事務(wù)煩惱!
大家好,我是飄渺。今天繼續(xù)DDD&微服務(wù)專欄。
在之前的文章 基于DDD的訂單創(chuàng)建 流程中,我們留下了一個(gè)問題:在createOrder()方法中,我將調(diào)用遠(yuǎn)程接口獲取購(gòu)物車詳情、遠(yuǎn)程庫(kù)存校驗(yàn)、訂單保存放在一個(gè)事務(wù)中,顯然這并不是一個(gè)正確的做法,因?yàn)樗鼤?huì)導(dǎo)致長(zhǎng)事務(wù),今天就讓我們來(lái)解決這個(gè)問題。
圖片
為什么會(huì)產(chǎn)生長(zhǎng)事務(wù)
首先,讓我們來(lái)分析一下產(chǎn)生長(zhǎng)事務(wù)的原因。
在Spring中,@Transactional注解是基于AOP實(shí)現(xiàn)的,本質(zhì)上是在目標(biāo)方法執(zhí)行前后進(jìn)行攔截。在目標(biāo)方法執(zhí)行前加入或創(chuàng)建一個(gè)事務(wù),在方法執(zhí)行后,根據(jù)實(shí)際情況選擇提交或回滾事務(wù)。
當(dāng)Spring遇到該注解時(shí),會(huì)自動(dòng)從數(shù)據(jù)庫(kù)連接池中獲取連接并開啟事務(wù),然后綁定到ThreadLocal上,對(duì)于@Transactional注解包裹的整個(gè)方法都是使用同一個(gè)連接。如果出現(xiàn)耗時(shí)的操作,如第三方接口調(diào)用、業(yè)務(wù)邏輯復(fù)雜、大批量數(shù)據(jù)處理等,就會(huì)導(dǎo)致占用連接的時(shí)間很長(zhǎng),數(shù)據(jù)庫(kù)連接一直被占用不釋放。一旦類似操作過(guò)多,就會(huì)導(dǎo)致數(shù)據(jù)庫(kù)連接池耗盡。
在開頭的實(shí)例中,一個(gè)事務(wù)中執(zhí)行RPC操作是典型的長(zhǎng)事務(wù)問題。類似的操作還包括在事務(wù)中進(jìn)行大量數(shù)據(jù)查詢、業(yè)務(wù)規(guī)則處理等。
長(zhǎng)事務(wù)會(huì)產(chǎn)生哪些問題
長(zhǎng)事務(wù)引發(fā)的常見危害有:
- 數(shù)據(jù)庫(kù)連接池被占滿,應(yīng)用無(wú)法獲取連接資源;
- 容易引發(fā)數(shù)據(jù)庫(kù)死鎖;
- 數(shù)據(jù)庫(kù)回滾時(shí)間長(zhǎng);
- 在主從架構(gòu)中會(huì)導(dǎo)致主從延時(shí)變大。
如何避免長(zhǎng)事務(wù)
既然知道了長(zhǎng)事務(wù)的危害,那么在開發(fā)中如何避免這個(gè)問題呢?
很明顯,解決長(zhǎng)事務(wù)的宗旨就是 對(duì)事務(wù)方法進(jìn)行拆分,盡量讓事務(wù)變小,變快,減小事務(wù)的顆粒度。
編程式事務(wù)
因此,我們可以采用編程式事務(wù)替代聲明式事務(wù)@Transactional。在Spring項(xiàng)目中,可以注入TransactionTemplate對(duì)象,然后手動(dòng)控制事務(wù)范圍。改造過(guò)后的代碼如下所示:
public String createOrder(OrderCreateRequest orderCreateRequest) {
// 獲取購(gòu)物車詳情
ShoppingCartDetailDTO shoppingCartDetailDTO = cartRemoteFacade.queryCheckedCartItemByUserId(orderCreateRequest.getCustomerId());
List<CartItemDTO> cartItemList = shoppingCartDetailDTO.getCartItemDtoS();
//校驗(yàn)庫(kù)存
checkInventory(cartItemList);
...
transactionTemplate.executeWithoutResult(status -> {
orderRepository.save(tradeOrder);
eventPublisher.publishEvent(new OrderCreatedEvent(tradeOrder));
});
return orderSn;
}
然而,這里涉及到另一個(gè)問題:在保存訂單后我們通過(guò)EventPublisher發(fā)布了一個(gè)事件,讓監(jiān)聽者來(lái)處理剩下的業(yè)務(wù)邏輯,(在Dailymart中創(chuàng)建訂單后需要進(jìn)行庫(kù)存預(yù)扣),在默認(rèn)情況下,Spring的事件監(jiān)聽機(jī)制是同步的將代碼進(jìn)行解耦,我們希望庫(kù)存扣減如果出現(xiàn)失敗需要回滾訂單,而編程式事務(wù)無(wú)法控制監(jiān)聽者的事務(wù)。因此,在這種場(chǎng)景下并不適合使用編程式事務(wù)來(lái)處理。
敲黑板:使用編程式事務(wù)替代聲明式事務(wù)是解決長(zhǎng)事務(wù)最簡(jiǎn)單的實(shí)現(xiàn)方式,在大部分場(chǎng)景下都可以采用。在使用時(shí)要注意編程式事務(wù)搭配EventPublisher時(shí)無(wú)法控制監(jiān)聽者的事務(wù)。
對(duì)方法進(jìn)行拆分
另外一種常見的處理措施就是將方法進(jìn)行拆分,將大方法拆成小方法,將不需要事務(wù)管理的邏輯與事務(wù)操作拆開。
public String createOrder(OrderCreateRequest orderCreateRequest) {
// 獲取購(gòu)物車詳情
ShoppingCartDetailDTO shoppingCartDetailDTO = cartRemoteFacade.queryCheckedCartItemByUserId(orderCreateRequest.getCustomerId());
List<CartItemDTO> cartItemList = shoppingCartDetailDTO.getCartItemDtoS();
//校驗(yàn)庫(kù)存
checkInventory(cartItemList);
...
this.saveOrder(tradeOrder)
return orderSn;
}
@Transactional(rollbackFor = RuntimeException.class)
private void saveOrder(TradeOrder tradeOrder){
orderRepository.save(tradeOrder);
eventPublisher.publishEvent(new OrderCreatedEvent(tradeOrder));
}
在上述代碼中,獲取購(gòu)物車詳情與庫(kù)存校驗(yàn)不需要事務(wù),將其與事務(wù)方法saveOrder()分開。然而,這樣的簡(jiǎn)單拆分會(huì)導(dǎo)致事務(wù)不生效。這又涉及到另一個(gè)知識(shí)點(diǎn):
@Transactional注解的聲明式事務(wù)是通過(guò)spring aop起作用的,而spring aop需要生成代理對(duì)象,直接在同一個(gè)類中方法調(diào)用使用的還是原始對(duì)象,事務(wù)不生效。其他幾個(gè)常見的事務(wù)不生效的場(chǎng)景為:
- @Transactional 應(yīng)用在非 public 修飾的方法上
- @Transactional 注解屬性 propagation 設(shè)置錯(cuò)誤
- @Transactional 注解屬性 rollbackFor 設(shè)置錯(cuò)誤
- 同一個(gè)類中方法調(diào)用,導(dǎo)致@Transactional失效
- 異常被catch捕獲導(dǎo)致@Transactional失效
正確的拆分方法應(yīng)該使用下面兩種:
- 將方法放入另一個(gè)類,如新增一個(gè)Manager層,通過(guò)Spring注入,這樣符合了在對(duì)象之間調(diào)用的條件。詳細(xì)說(shuō)明可以參考我的文章為什么阿里建議給MVC三層架構(gòu)再加一層Manager層!。
- 啟動(dòng)類添加@EnableAspectJAutoProxy(exposeProxy = true),方法內(nèi)使用AopContext.currentProxy()獲得代理類,使用事務(wù)。
SpringBootApplication.java
@EnableAspectJAutoProxy(exposeProxy = true)
@SpringBootApplication
public class SpringBootApplication {}
public String createOrder(OrderCreateRequest orderCreateRequest) {
...
OrderService orderService = (OrderService)AopContext.currentProxy();
orderService.saveData(tradeOrder);
return orderSn;
}
@Transactional(rollbackFor = RuntimeException.class)
private void saveOrder(TradeOrder tradeOrder){
orderRepository.save(tradeOrder);
eventPublisher.publishEvent(new OrderCreatedEvent(tradeOrder));
}
然而,Dailymart項(xiàng)目是基于DDD的分層架構(gòu)模型實(shí)現(xiàn)。原來(lái)的業(yè)務(wù)邏輯是在應(yīng)用服務(wù)編寫,在我們項(xiàng)目中只需要將保存訂單的邏輯放在領(lǐng)域服務(wù)層,由領(lǐng)域服務(wù)保證事務(wù),而應(yīng)用服務(wù)層負(fù)責(zé)組裝業(yè)務(wù)邏輯。最終代碼如下:
private final TradeOrderService tradeOrderService;
@Override
// @Transactional(rollbackFor = RuntimeException.class)
public String createOrder(OrderCreateRequest orderCreateRequest) {
// 生成訂單編號(hào)
String orderSn = IdUtils.nextIdStr();
// 獲取購(gòu)物車詳情
ShoppingCartDetailDTO shoppingCartDetailDTO = cartRemoteFacade.queryCheckedCartItemByUserId(orderCreateRequest.getCustomerId());
List<CartItemDTO> cartItemList = shoppingCartDetailDTO.getCartItemDtoS();
// 校驗(yàn)庫(kù)存
checkInventory(cartItemList);
...
tradeOrderService.save(tradeOrder);
return orderSn;
}
@Service
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class TradeOrderServiceImpl implements TradeOrderService {
private final ApplicationEventPublisher eventPublisher;
private final OrderRepository orderRepository;
@Override
@Transactional
public void save(TradeOrder tradeOrder) {
orderRepository.save(tradeOrder);
eventPublisher.publishEvent(new OrderCreatedEvent(tradeOrder));
}
}
小結(jié)
本文討論了長(zhǎng)事務(wù)的危害及解決方案。首先,我們探討了長(zhǎng)事務(wù)導(dǎo)致的問題,包括數(shù)據(jù)庫(kù)連接池耗盡、死鎖等。其次,介紹了兩種解決策略:采用編程式事務(wù)和對(duì)方法進(jìn)行拆分。編程式事務(wù)提供了手動(dòng)控制事務(wù)范圍的方式,但需要注意搭配EventPublisher可能導(dǎo)致監(jiān)聽者事務(wù)無(wú)法控制的問題。對(duì)方法進(jìn)行拆分是一種更通用的方法,能夠減小事務(wù)范圍,提高執(zhí)行效率。最后,通過(guò)實(shí)際的DDD分層架構(gòu)示例,展示了在應(yīng)用服務(wù)層和領(lǐng)域服務(wù)層中如何組織業(yè)務(wù)邏輯,確保事務(wù)正確性和性能。