摸魚心法第一章——和配置文件說拜拜
為了能摸魚我們團隊做了容器化，但是帶來的問題是服務配置文件很麻煩，然后大家在群里進行了“親切友好”的溝通圖片圖片圖片圖片對比就對比，簡單對比下獨立配置中心和k8s作為配
繼上次的if else優化也有段時間了，最近小貓又又又著道了，接手的那個項目又遇到了坑爹的地方，經常性的報死鎖異常，經常性的主從延遲......通過報錯信息按圖索驥，發現代碼是這樣的。
這是一段商品發布的邏輯，我們可以看到參數校驗、查詢、最終的insert以及update全部揉在一個事務中。遇到批量發布商品的時候就經常出現問題了，數據庫主從延遲是肯定少不了的。
其實像上述小貓遇到的這種狀況我們就稱其為大事務，那么我們就大概有這么一個定義。我們將執行時間長，并且操作數據比較多的事務叫做大事務。
在我們日常開發過程中，其實經常會遇到大事務，老貓總結了一下，往往原因其實總結下來有這么幾點（當然存在紕漏的地方，也歡迎大家評論區留言補充）：
那么大事務造成的影響又是什么呢？
從開發者的角度來看的話，部分大事務必定對應的復雜的業務邏輯，代碼封裝事務拆解不合理，研發側維護困難，維護成本高。
從最終系統以及運維角度來看：
大事務既然有這么多坑，那么我們來看一下我們日常開發過程中，應該如何做到盡量規避呢？老貓整理了以下幾種優化方法。
a.降低事務顆粒度，大事務拆解小事務：
b.大數據量一次性提交盡可能拆解分批處理。
c.拆解原始事務，異步化處理。
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 再次注入到自身（老貓覺得這種方式不優雅，不太推薦，這里就不寫了）
我們再來看大數量批量請求的場景，咱們具體來分析一下，假設上游系統存在一個批量導入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) } }}這種異步化處理的方案其實有兩種方式進行異步化操作。尤其是涉及到第三方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.www897cc.com/showinfo-26-60936-0.html麻了，這讓人絕望的大事務提交
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號