麻了，這讓人絕望的大事務提交
一、背景
繼上次的if else優化也有段時間了，最近小貓又又又著道了，接手的那個項目又遇到了坑爹的地方，經常性的報死鎖異常，經常性的主從延遲......通過報錯信息按圖索驥，發現代碼是這樣的。
這是一段商品發布的邏輯，我們可以看到參數校驗、查詢、最終的insert以及update全部揉在一個事務中。遇到批量發布商品的時候就經常出現問題了，數據庫主從延遲是肯定少不了的。
二、開啟優化
其實像上述小貓遇到的這種狀況我們就稱其為大事務，那么我們就大概有這么一個定義。我們將執行時間長，并且操作數據比較多的事務叫做大事務。
1.大事務產生的原因
在我們日常開發過程中，其實經常會遇到大事務，老貓總結了一下，往往原因其實總結下來有這么幾點（當然存在紕漏的地方，也歡迎大家評論區留言補充）：
- 一次性操作的數據量確實多，大量的鎖競爭，比如批量操作這種行為。
- 事務粒度過大，代碼中的 @Transactional使用不當，其他非DB操作比較多，耗時久。比如調用RPC接口，在例如上述小貓遇到的check邏輯甚至都揉在一起等等。
2.造成的影響
那么大事務造成的影響又是什么呢？
從開發者的角度來看的話，部分大事務必定對應的復雜的業務邏輯，代碼封裝事務拆解不合理，研發側維護困難，維護成本高。
從最終系統以及運維角度來看：
- 出現了死鎖。
- 造成了主從延遲。
- 大事務消耗更多的磁盤空間，回滾成本高。
- 大事務發生的過程中，由于連接池持續被打開，很容易造成數據庫連接池被沾滿。
- 接口響應慢導致接口超時，甚至導致服務不可用等等 （歡迎大家補充）
3.優化方案
大事務既然有這么多坑，那么我們來看一下我們日常開發過程中，應該如何做到盡量規避呢？老貓整理了以下幾種優化方法。
a.降低事務顆粒度，大事務拆解小事務：
- 編程式事務代替@Transactional。
- 非update以及insert動作外移。
b.大數據量一次性提交盡可能拆解分批處理。
c.拆解原始事務，異步化處理。
(1) 降低事務顆粒度
1、我們對@Transactional的事務粒度把控不好，有時候如果使用不當的話事務功能可能會失效，如果經驗不足，很難排查，那么我們不如直接使用粗細粒度更好把控的編程式事務。TransactionTemplate。這樣的話咱們的優化代碼就可以寫好才能如下方式。
@Autowired
private 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等等方式將數據拆成多個小的批量然后再進行入庫操作處理。
@Servcie
public 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);
}
}
}
}
@Servcie
public 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異步化處理，還是針對上述業務邏輯，我們是否可以將最終的發送郵件的動作剝離出來，最終再去統一執行發送郵件。
關于偽代碼這里不展開了，有興趣的小伙伴可以自行實現一下。
