当前位置：首页 > 科技 > 软件

麻了，这让人绝望的大事务提交

来源：责编：时间：2024-01-15 09:20:19 132观看

导读一、背景继上次的if else优化也有段时间了，最近小猫又又又着道了，接手的那个项目又遇到了坑爹的地方，经常性的报死锁异常，经常性的主从延迟......通过报错信息按图索骥，发现代码是这样的。这是一段商品发布的逻辑，我们可以

一、背景

继上次的if else优化也有段时间了，最近小猫又又又着道了，接手的那个项目又遇到了坑爹的地方，经常性的报死锁异常，经常性的主从延迟......通过报错信息按图索骥，发现代码是这样的。

这是一段商品发布的逻辑，我们可以看到参数校验、查询、最终的insert以及update全部揉在一个事务中。遇到批量发布商品的时候就经常出现问题了，数据库主从延迟是肯定少不了的。

二、开启优化

其实像上述小猫遇到的这种状况我们就称其为大事务，那么我们就大概有这么一个定义。我们将执行时间长，并且操作数据比较多的事务叫做大事务。

1.大事务产生的原因

在我们日常开发过程中，其实经常会遇到大事务，老猫总结了一下，往往原因其实总结下来有这么几点（当然存在纰漏的地方，也欢迎大家评论区留言补充）：

一次性操作的数据量确实多，大量的锁竞争，比如批量操作这种行为。
事务粒度过大，代码中的 @Transactional使用不当，其他非DB操作比较多，耗时久。比如调用RPC接口，在例如上述小猫遇到的check逻辑甚至都揉在一起等等。

2.造成的影响

那么大事务造成的影响又是什么呢？

从开发者的角度来看的话，部分大事务必定对应的复杂的业务逻辑，代码封装事务拆解不合理，研发侧维护困难，维护成本高。

从最终系统以及运维角度来看：

出现了死锁。
造成了主从延迟。
大事务消耗更多的磁盘空间，回滚成本高。
大事务发生的过程中，由于连接池持续被打开，很容易造成数据库连接池被沾满。
接口响应慢导致接口超时，甚至导致服务不可用等等（欢迎大家补充）

3.优化方案

大事务既然有这么多坑，那么我们来看一下我们日常开发过程中，应该如何做到尽量规避呢？老猫整理了以下几种优化方法。

a.降低事务颗粒度，大事务拆解小事务：

编程式事务代替@Transactional。
非update以及insert动作外移。

b.大数据量一次性提交尽可能拆解分批处理。

c.拆解原始事务，异步化处理。

(1) 降低事务颗粒度

1、我们对@Transactional的事务粒度把控不好，有时候如果使用不当的话事务功能可能会失效，如果经验不足，很难排查，那么我们不如直接使用粗细粒度更好把控的编程式事务。TransactionTemplate。这样的话咱们的优化代码就可以写好才能如下方式。

@Autowiredprivate TransactionTemplate transactionTemplate;public boolean publishProduct(PublishProductRequest request) {        externalSellerAuthorizeService.checkAuthorizeValid(request.getSellerId(),request.getThirdCategoryId(),request.getBrandId());        ......        transactionTemplate.execute((status) -> {            try{                //执行insert                productDao.insert(productDO);                productDescDao.insert(productDescDO);                ....                //其他insert以及update操作            }catch (Exception e) {                //回滚                status.setRollbackOnly();                return true;            }            return false;        });        return true;    }

非update以及insert动作外移。

原始代码：

@Transactional(rollbackFor=Exception.class)   public void save(Req req) {         checkParam(req);         saveData1(req);         updateData2(req);   }   private void checkParam(Req req){       Data1 data = selectData1();       Data2 data2 = selectData2();       if(data.getSomeThing() != STATUS_YES){          throw new BusinessTimeException(.....);       }   }

然后部分小伙伴就觉得外移么，如果不用@Transactional的情况，那直接这样不就行了么。

错误改造案例：

class ServiceAImpl implements ServiceA {  @Transactional(rollbackFor=Exception.class)   public void save(Req req) {         saveData1(req);         updateData2(req);   }   private void checkParam(Req req){       Data1 data = selectData1();       Data2 data2 = selectData2();       if(data.getSomeThing() != STATUS_YES){          throw new BusinessTimeException(.....);       }   } public void save(Req req){    checkParam(req);    doSave(req); }}

这个例子是非常经典的错误，这种直接方法调用的做法事务不会生效，老猫以前也踩过这样的坑。因为 @Transactional 注解的声明式事务是通过 spring aop 起作用的，而 spring aop 需要生成代理对象，直接方法调用使用的还是原始对象，所以事务不会生效。那么我们应该如何改造呢？我们看下正确的改造。

正确改造方案1,当然还是利用上面的TransactionTemplate：

  @Autowired  private TransactionTemplate transactionTemplate;   public void save(Req req) {         checkParam(req);         transactionTemplate.execute((status) -> {            try{                saveData1(req);                updateData2(req);                ....                //其他insert以及update操作            }catch (Exception e) {                //回滚                status.setRollbackOnly();                return true;            }            return false;        });   }   private void checkParam(Req req){       Data1 data = selectData1();       Data2 data2 = selectData2();       if(data.getSomeThing() != STATUS_YES){          throw new BusinessTimeException(.....);       }   }

正确改造方案2，把 @Transactional 注解加到新Service方法上，把需要事务执行的代码移到新方法中。

  @Servcie  public class ServiceA {     @Autowired     private ServiceB serviceB;     private void checkParam(Req req){       Data1 data = selectData1();       Data2 data2 = selectData2();       if(data.getSomeThing() != STATUS_YES){          throw new BusinessTimeException(.....);       }   }    public void save(Req req) {          checkParam(req);          serviceB.save(req);    }  }   @Servcie   public class ServiceB {      @Transactional(rollbackFor=Exception.class)      public void save(Req req) {         saveData1(req);         updateData2(req);      }   }

正确改造方案3：将ServiceA 再次注入到自身（老猫觉得这种方式不优雅，不太推荐，这里就不写了）

(2) 大数据量一次性提交尽可能拆解分批处理

我们再来看大数量批量请求的场景，咱们具体来分析一下，假设上游系统存在一个批量导入2w的数据操作。如果我们读取到上游导入的数据，并且直接执行DB一次性执行肯定是不合适的。这种情况就需要我们对其请求的数据量做一个拆解。我们可以采用Lists.partition等等方式将数据拆成多个小的批量然后再进行入库操作处理。

@Servciepublic class ServiceA {  @Autowired  private ServiceB serviceB;  private void batchAdd(List<Long> inventorySkuIdList){      List<List<Long>> partition = Lists.partition(inventorySkuIdList, 1000);        for (List<Long> idList : partition) {            List<InventorySkuDO> inventorySkuDOList = inventorySkuDao.selectByIdList(idList, null);            if (CollectionUtils.isNotEmpty(inventorySkuDOList)) {               serviceB.doInsertUpdate(inventorySkuDOList);            }        }  }}@Servciepublic class ServiceB {  @Transactional(rollbackFor=Exception.class)  private void doInsertUpdate(List<InventorySkuDO> inventorySkuDOList){        for (InventorySkuDO inventorySkuDO : inventorySkuDOList) {           doInsert(inventorySkuDO);           doUpdate(inventorySkuDO)        }  }}

(3) 拆解原始事务，异步化处理

这种异步化处理的方案其实有两种方式进行异步化操作。尤其是涉及到第三方RPC调用或者HTTP调用的时候，这种方案就更加适合。

方案一，采用CompletableFuture异步编排特性，当业务流程比较长的时候，我们可以将一个大业务拆解成多个小的任务进行异步化执行。比如咱们有个批量支付的业务逻辑，因为整个流程是同步的，所以大概有了下面这样的流程。（关于CompletableFeature老猫觉得挺有意思的，后续老猫会出专门的文章来理透该特性，欢迎大家持续关注）。

completeFeature

对应转换成代码逻辑的话，大概是这样的：

void doBatchPay() {        CompletableFuture<Object> task1 = CompletableFuture.supplyAsync(() -> {            return "订单信息";        });        CompletableFuture<Object> task2 = CompletableFuture.supplyAsync(() -> {            try {               return doPay();            } catch (InterruptedException e) {                //log add            }        });        //task1、task2 执行完执行task3 ,需要感知task1和task2的执行结果        CompletableFuture<Object> future = task1.thenCombineAsync(task2, (t1, t2) -> {            return "邮件发送成功";        });    }

方案二，Mq异步化处理，还是针对上述业务逻辑，我们是否可以将最终的发送邮件的动作剥离出来，最终再去统一执行发送邮件。

关于伪代码这里不展开了，有兴趣的小伙伴可以自行实现一下。

本文链接：http://www.28at.com/showinfo-26-60936-0.html麻了，这让人绝望的大事务提交

声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com

上一篇：我们优雅判断 interface 是否为 nil

下一篇：为啥我放弃用 Pinia 和 Vuex 去做字典状态管理呢？

标签：

热门焦点

Mate60手机壳曝光致敬自己的经典设计

8月3日消息，今天下午博主数码闲聊站带来了华为Mate60的第三方手机壳图，可以让我们在真机发布之前看看这款华为全新旗舰的大致轮廓。从曝光的图片看，Mate 60背后摄像头面积依然
对标苹果的灵动岛华为带来实况窗功能

继苹果的灵动岛之后，华为也在今天正式推出了“实况窗”功能。据今天鸿蒙OS 4.0的现场演示显示，华为的实况窗可以更高效的展现出实时通知，比如锁屏上就能看到外卖、打车、银行
中兴AX5400Pro+上手体验：再升级双2.5G网口+USB 3.0这次全都有

2021年11月的时候，中兴先后发布了两款路由器产品，中兴AX5400和中兴AX5400 Pro，从产品命名上就不难看出这是隶属于同一系列的，但在外观设计上这两款产品可以说是完全没一点关系
K8S | Service服务发现

一、背景在微服务架构中，这里以开发环境「Dev」为基础来描述，在K8S集群中通常会开放：路由网关、注册中心、配置中心等相关服务，可以被集群外部访问；图片对于测试「Tes」环境或者
三分钟白话RocketMQ系列—— 如何发送消息

我们知道RocketMQ主要分为消息生产、存储（消息堆积）、消费三大块领域。那接下来，我们白话一下，RocketMQ是如何发送消息的，揭秘消息生产全过程。注意，如果白话中不小心提到相关代
余承东:AI大模型技术的发展将会带来下一代智能终端操作系统的智慧体验

8月4日消息，2023年华为开发者大会（HDC.Together）今天正式开幕，华为发布HarmonyOS 4、全新升级的鸿蒙开发套件、HarmonyOS Next开发者预览版本等一系列
iQOO Neo8 Pro评测：旗舰双芯加持最强性能游戏旗舰

【Techweb评测】去年10月，iQOO推出了一款Neo7手机，该机搭载了联发科天玑9000+，配备独显芯片Pro+，带来了同价位段最佳的游戏体验，一经上市便受到了诸多用
最薄的14英寸游戏笔记本电脑 Alienware X14已可以购买

2022年1月份在国际消费电子展(CES2022)上首次亮相的Alienware新品——Alienware X14现在已经可以购买了，这款笔记本电脑被誉为世界上最薄的 14 英寸游戏笔
利用职权私自解除被封帐号 Meta开除20多名员工

11月18日消息，据外媒援引知情人士表示，过去一年时间内，Facebook母公司Meta解雇或处罚了20多名员工以及合同工，指控这些人通过内部系统以不当方式重置用户帐号，其