做word文档什么网站好,网络推广平台有哪些,做淘宝客网站域名是别人的,企业规划设计经常性的报死锁异常#xff0c;经常性的主从延迟......通过报错信息按图索骥#xff0c;发现代码是这样的。 这是一段商品发布的逻辑#xff0c;我们可以看到参数校验、查询、最终的insert以及update全部揉在一个事务中。遇到批量发布商品的时候就经常出现问题了#xff0c…经常性的报死锁异常经常性的主从延迟......通过报错信息按图索骥发现代码是这样的。 这是一段商品发布的逻辑我们可以看到参数校验、查询、最终的insert以及update全部揉在一个事务中。遇到批量发布商品的时候就经常出现问题了数据库主从延迟是肯定少不了的。
开启优化
其实像上述小猫遇到的这种状况我们就称其为大事务那么我们就大概有这么一个定义。我们将执行时间长并且操作数据比较多的事务叫做大事务。
大事务产生的原因
在我们日常开发过程中其实经常会遇到大事务老猫总结了一下往往原因其实总结下来有这么几点当然存在纰漏的地方也欢迎大家评论区留言补充
一次性操作的数据量确实多大量的锁竞争比如批量操作这种行为。事务粒度过大代码中的 Transactional使用不当其他非DB操作比较多耗时久。比如调用RPC接口在例如上述小猫遇到的check逻辑甚至都揉在一起等等。
造成的影响
那么大事务造成的影响又是什么呢
从开发者的角度来看的话部分大事务必定对应的复杂的业务逻辑代码封装事务拆解不合理研发侧维护困难维护成本高。从最终系统以及运维角度来看 出现了死锁。造成了主从延迟。大事务消耗更多的磁盘空间回滚成本高。大事务发生的过程中由于连接池持续被打开很容易造成数据库连接池被沾满。接口响应慢导致接口超时甚至导致服务不可用等等 欢迎大家补充
优化方案
大事务既然有这么多坑那么我们来看一下我们日常开发过程中应该如何做到尽量规避呢老猫整理了以下几种优化方法。
降低事务颗粒度大事务拆解小事务 编程式事务代替Transactional。非update以及insert动作外移。大数据量一次性提交尽可能拆解分批处理。拆解原始事务异步化处理。
降低事务颗粒度
1、我们对Transactional的事务粒度把控不好有时候如果使用不当的话事务功能可能会失效如果经验不足很难排查那么我们不如直接使用粗细粒度更好把控的编程式事务。TransactionTemplate。这样的话咱们的优化代码就可以写好才能如下方式。
Autowiredprivate TransactionTemplate transactionTemplate;public boolean publishProduct(PublishProductRequest request) {externalSellerAuthorizeService.checkAuthorizeValid(request.getSellerId(),request.getThirdCategoryId(),request.getBrandId());......transactionTemplate.execute((status) - {try{//执行insertproductDao.insert(productDO);productDescDao.insert(productDescDO);....//其他insert以及update操作}catch (Exception e) {//回滚status.setRollbackOnly();return true;}return false;});return true;}
非update以及insert动作外移。
原始代码
Transactional(rollbackForException.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(rollbackForException.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
Autowiredprivate 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方法上把需要事务执行的代码移到新方法中。
Servciepublic class ServiceA {Autowiredprivate 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);}}Servciepublic class ServiceB {Transactional(rollbackForException.class)public void save(Req req) {saveData1(req);updateData2(req);}}
正确改造方案3将ServiceA 再次注入到自身
大数据量一次性提交尽可能拆解分批处理。
我们再来看大数量批量请求的场景咱们具体来分析一下假设上游系统存在一个批量导入2w的数据操作。如果我们读取到上游导入的数据并且直接执行DB一次性执行肯定是不合适的。这种情况就需要我们对其请求的数据量做一个拆解。我们可以采用Lists.partition等等方式将数据拆成多个小的批量然后再进行入库操作处理。
Servciepublic class ServiceA {Autowiredprivate ServiceB serviceB;private void batchAdd(ListLong inventorySkuIdList){ListListLong partition Lists.partition(inventorySkuIdList, 1000);for (ListLong idList : partition) {ListInventorySkuDO inventorySkuDOList inventorySkuDao.selectByIdList(idList, null);if (CollectionUtils.isNotEmpty(inventorySkuDOList)) {serviceB.doInsertUpdate(inventorySkuDOList);}}}}Servciepublic class ServiceB {Transactional(rollbackForException.class)private void doInsertUpdate(ListInventorySkuDO inventorySkuDOList){for (InventorySkuDO inventorySkuDO : inventorySkuDOList) {doInsert(inventorySkuDO);doUpdate(inventorySkuDO)}}}
拆解原始事务异步化处理。
这种异步化处理的方案其实有两种方式进行异步化操作。尤其是涉及到第三方RPC调用或者HTTP调用的时候这种方案就更加适合。
方案一采用CompletableFuture异步编排特性当业务流程比较长的时候我们可以将一个大业务拆解成多个小的任务进行异步化执行。比如咱们有个批量支付的业务逻辑因为整个流程是同步的所以大概有了下面这样的流程。 对应转换成代码逻辑的话大概是这样的 void doBatchPay() {CompletableFutureObject task1 CompletableFuture.supplyAsync(() - {return 订单信息;});CompletableFutureObject task2 CompletableFuture.supplyAsync(() - {try {return doPay();} catch (InterruptedException e) {//log add}});//task1、task2 执行完执行task3 ,需要感知task1和task2的执行结果CompletableFutureObject future task1.thenCombineAsync(task2, (t1, t2) - {return 邮件发送成功;});}
方案二Mq异步化处理还是针对上述业务逻辑我们是否可以将最终的发送邮件的动作剥离出来最终再去统一执行发送邮件。
