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