大家好,我是飄渺。今天繼續(xù)DDD&微服務(wù)專欄。
在之前的文章 基于DDD的訂單創(chuàng)建 流程中,我們留下了一個(gè)問題:在createOrder()方法中,我將調(diào)用遠(yuǎn)程接口獲取購物車詳情、遠(yuǎn)程庫存校驗(yàn)、訂單保存放在一個(gè)事務(wù)中,顯然這并不是一個(gè)正確的做法,因?yàn)樗鼤?huì)導(dǎo)致長事務(wù),今天就讓我們來解決這個(gè)問題。
圖片
首先,讓我們來分析一下產(chǎn)生長事務(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ù)庫連接池中獲取連接并開啟事務(wù),然后綁定到ThreadLocal上,對于@Transactional注解包裹的整個(gè)方法都是使用同一個(gè)連接。如果出現(xiàn)耗時(shí)的操作,如第三方接口調(diào)用、業(yè)務(wù)邏輯復(fù)雜、大批量數(shù)據(jù)處理等,就會(huì)導(dǎo)致占用連接的時(shí)間很長,數(shù)據(jù)庫連接一直被占用不釋放。一旦類似操作過多,就會(huì)導(dǎo)致數(shù)據(jù)庫連接池耗盡。
在開頭的實(shí)例中,一個(gè)事務(wù)中執(zhí)行RPC操作是典型的長事務(wù)問題。類似的操作還包括在事務(wù)中進(jìn)行大量數(shù)據(jù)查詢、業(yè)務(wù)規(guī)則處理等。
長事務(wù)引發(fā)的常見危害有:
既然知道了長事務(wù)的危害,那么在開發(fā)中如何避免這個(gè)問題呢?
很明顯,解決長事務(wù)的宗旨就是 對事務(wù)方法進(jìn)行拆分,盡量讓事務(wù)變小,變快,減小事務(wù)的顆粒度。
因此,我們可以采用編程式事務(wù)替代聲明式事務(wù)@Transactional。在Spring項(xiàng)目中,可以注入TransactionTemplate對象,然后手動(dòng)控制事務(wù)范圍。改造過后的代碼如下所示:
public String createOrder(OrderCreateRequest orderCreateRequest) { // 獲取購物車詳情 ShoppingCartDetailDTO shoppingCartDetailDTO = cartRemoteFacade.queryCheckedCartItemByUserId(orderCreateRequest.getCustomerId()); List<CartItemDTO> cartItemList = shoppingCartDetailDTO.getCartItemDtoS(); //校驗(yàn)庫存 checkInventory(cartItemList); ... transactionTemplate.executeWithoutResult(status -> { orderRepository.save(tradeOrder); eventPublisher.publishEvent(new OrderCreatedEvent(tradeOrder)); }); return orderSn;}
然而,這里涉及到另一個(gè)問題:在保存訂單后我們通過EventPublisher發(fā)布了一個(gè)事件,讓監(jiān)聽者來處理剩下的業(yè)務(wù)邏輯,(在Dailymart中創(chuàng)建訂單后需要進(jìn)行庫存預(yù)扣),在默認(rèn)情況下,Spring的事件監(jiān)聽機(jī)制是同步的將代碼進(jìn)行解耦,我們希望庫存扣減如果出現(xiàn)失敗需要回滾訂單,而編程式事務(wù)無法控制監(jiān)聽者的事務(wù)。因此,在這種場景下并不適合使用編程式事務(wù)來處理。
敲黑板:使用編程式事務(wù)替代聲明式事務(wù)是解決長事務(wù)最簡單的實(shí)現(xiàn)方式,在大部分場景下都可以采用。在使用時(shí)要注意編程式事務(wù)搭配EventPublisher時(shí)無法控制監(jiān)聽者的事務(wù)。
另外一種常見的處理措施就是將方法進(jìn)行拆分,將大方法拆成小方法,將不需要事務(wù)管理的邏輯與事務(wù)操作拆開。
public String createOrder(OrderCreateRequest orderCreateRequest) { // 獲取購物車詳情 ShoppingCartDetailDTO shoppingCartDetailDTO = cartRemoteFacade.queryCheckedCartItemByUserId(orderCreateRequest.getCustomerId()); List<CartItemDTO> cartItemList = shoppingCartDetailDTO.getCartItemDtoS(); //校驗(yàn)庫存 checkInventory(cartItemList); ... this.saveOrder(tradeOrder) return orderSn;}@Transactional(rollbackFor = RuntimeException.class)private void saveOrder(TradeOrder tradeOrder){ orderRepository.save(tradeOrder); eventPublisher.publishEvent(new OrderCreatedEvent(tradeOrder)); }
在上述代碼中,獲取購物車詳情與庫存校驗(yàn)不需要事務(wù),將其與事務(wù)方法saveOrder()分開。然而,這樣的簡單拆分會(huì)導(dǎo)致事務(wù)不生效。這又涉及到另一個(gè)知識(shí)點(diǎn):
@Transactional注解的聲明式事務(wù)是通過spring aop起作用的,而spring aop需要生成代理對象,直接在同一個(gè)類中方法調(diào)用使用的還是原始對象,事務(wù)不生效。其他幾個(gè)常見的事務(wù)不生效的場景為:
正確的拆分方法應(yīng)該使用下面兩種:
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)。原來的業(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(); // 獲取購物車詳情 ShoppingCartDetailDTO shoppingCartDetailDTO = cartRemoteFacade.queryCheckedCartItemByUserId(orderCreateRequest.getCustomerId()); List<CartItemDTO> cartItemList = shoppingCartDetailDTO.getCartItemDtoS(); // 校驗(yàn)庫存 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)); }}
本文討論了長事務(wù)的危害及解決方案。首先,我們探討了長事務(wù)導(dǎo)致的問題,包括數(shù)據(jù)庫連接池耗盡、死鎖等。其次,介紹了兩種解決策略:采用編程式事務(wù)和對方法進(jìn)行拆分。編程式事務(wù)提供了手動(dòng)控制事務(wù)范圍的方式,但需要注意搭配EventPublisher可能導(dǎo)致監(jiān)聽者事務(wù)無法控制的問題。對方法進(jìn)行拆分是一種更通用的方法,能夠減小事務(wù)范圍,提高執(zhí)行效率。最后,通過實(shí)際的DDD分層架構(gòu)示例,展示了在應(yīng)用服務(wù)層和領(lǐng)域服務(wù)層中如何組織業(yè)務(wù)邏輯,確保事務(wù)正確性和性能。
本文鏈接:http://www.www897cc.com/showinfo-26-55266-0.htmlSpring事務(wù)長了個(gè)腿?輕松掌握技巧告別長事務(wù)煩惱!
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。郵件:2376512515@qq.com