麻了，这让人绝望的大事务提交
背景
繼上次的if else優(yōu)化也有段時間了，最近小貓又又又著道了，接手的那個項目又遇到了坑爹的地方，經(jīng)常性的報死鎖異常，經(jīng)常性的主從延遲......通過報錯信息按圖索驥，發(fā)現(xiàn)代碼是這樣的。
這是一段商品發(fā)布的邏輯，我們可以看到參數(shù)校驗、查詢、最終的insert以及update全部揉在一個事務(wù)中。遇到批量發(fā)布商品的時候就經(jīng)常出現(xiàn)問題了，數(shù)據(jù)庫主從延遲是肯定少不了的。
開啟優(yōu)化
其實像上述小貓遇到的這種狀況我們就稱其為大事務(wù)，那么我們就大概有這么一個定義。我們將執(zhí)行時間長，并且操作數(shù)據(jù)比較多的事務(wù)叫做大事務(wù)。
大事務(wù)產(chǎn)生的原因
在我們?nèi)粘ｉ_發(fā)過程中，其實經(jīng)常會遇到大事務(wù)，老貓總結(jié)了一下，往往原因其實總結(jié)下來有這么幾點（當(dāng)然存在紕漏的地方，也歡迎大家評論區(qū)留言補充）
- 一次性操作的數(shù)據(jù)量確實多，大量的鎖競爭，比如批量操作這種行為。
- 事務(wù)粒度過大，代碼中的 @Transactional使用不當(dāng)，其他非DB操作比較多，耗時久。比如調(diào)用RPC接口，在例如上述小貓遇到的check邏輯甚至都揉在一起等等。
造成的影響
那么大事務(wù)造成的影響又是什么呢？
- 從開發(fā)者的角度來看的話，部分大事務(wù)必定對應(yīng)的復(fù)雜的業(yè)務(wù)邏輯，代碼封裝事務(wù)拆解不合理，研發(fā)側(cè)維護困難，維護成本高。
- 從最終系統(tǒng)以及運維角度來看
- 出現(xiàn)了死鎖。
- 造成了主從延遲。
- 大事務(wù)消耗更多的磁盤空間，回滾成本高。
- 大事務(wù)發(fā)生的過程中，由于連接池持續(xù)被打開，很容易造成數(shù)據(jù)庫連接池被沾滿。
- 接口響應(yīng)慢導(dǎo)致接口超時，甚至導(dǎo)致服務(wù)不可用等等
（歡迎大家補充）
優(yōu)化方案
大事務(wù)既然有這么多坑，那么我們來看一下我們?nèi)粘ｉ_發(fā)過程中，應(yīng)該如何做到盡量規(guī)避呢？老貓整理了以下幾種優(yōu)化方法。
- 降低事務(wù)顆粒度，大事務(wù)拆解小事務(wù)
- 編程式事務(wù)代替@Transactional。
- 非update以及insert動作外移。
- 大數(shù)據(jù)量一次性提交盡可能拆解分批處理。
- 拆解原始事務(wù)，異步化處理。
降低事務(wù)顆粒度
1、我們對@Transactional的事務(wù)粒度把控不好，有時候如果使用不當(dāng)?shù)脑捠聞?wù)功能可能會失效，如果經(jīng)驗不足，很難排查，那么我們不如直接使用粗細粒度更好把控的編程式事務(wù)。TransactionTemplate。這樣的話咱們的優(yōu)化代碼就可以寫好才能如下方式。
@Autowired
private TransactionTemplate transactionTemplate;
public boolean publishProduct(PublishProductRequest request) {
externalSellerAuthorizeService.checkAuthorizeValid(request.getSellerId(),request.getThirdCategoryId(),request.getBrandId());
......
transactionTemplate.execute((status) -> {
try{
//執(zhí)行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);
}
}
這個例子是非常經(jīng)典的錯誤，這種直接方法調(diào)用的做法事務(wù)不會生效，老貓以前也踩過這樣的坑。因為 @Transactional 注解的聲明式事務(wù)是通過 spring aop 起作用的，
而 spring aop 需要生成代理對象，直接方法調(diào)用使用的還是原始對象，所以事務(wù)不會生效。那么我們應(yīng)該如何改造呢？我們看下正確的改造。
正確改造方案1,當(dāng)然還是利用上面的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方法上，把需要事務(wù)執(zhí)行的代碼移到新方法中。
@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 再次注入到自身（老貓覺得這種方式不優(yōu)雅，不太推薦，這里就不寫了）
大數(shù)據(jù)量一次性提交盡可能拆解分批處理。
我們再來看大數(shù)量批量請求的場景，咱們具體來分析一下，假設(shè)上游系統(tǒng)存在一個批量導(dǎo)入2w的數(shù)據(jù)操作。如果我們讀取到上游導(dǎo)入的數(shù)據(jù)，并且直接執(zhí)行DB一次性執(zhí)行肯定是不合適的。這種情況就需要我們對其請求的數(shù)據(jù)量做一個拆解。我們可以采用Lists.partition等等方式將數(shù)據(jù)拆成多個小的批量然后再進行入庫操作處理。
@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)
}
}
}
拆解原始事務(wù)，異步化處理。
這種異步化處理的方案其實有兩種方式進行異步化操作。尤其是涉及到第三方RPC調(diào)用或者HTTP調(diào)用的時候，這種方案就更加適合。
方案一，采用CompletableFuture異步編排特性，當(dāng)業(yè)務(wù)流程比較長的時候，我們可以將一個大業(yè)務(wù)拆解成多個小的任務(wù)進行異步化執(zhí)行。比如咱們有個批量支付的業(yè)務(wù)邏輯，因為整個流程是同步的，所以大概有了下面這樣的流程。（關(guān)于CompletableFeature老貓覺得挺有意思的，后續(xù)老貓會出專門的文章來理透該特性，歡迎大家持續(xù)關(guān)注）。
對應(yīng)轉(zhuǎn)換成代碼邏輯的話，大概是這樣的：
void doBatchPay() {
CompletableFuture<Object> task1 = CompletableFuture.supplyAsync(() -> {
return "訂單信息";
});
CompletableFuture<Object> task2 = CompletableFuture.supplyAsync(() -> {
try {
return doPay();
} catch (InterruptedException e) {
//log add
}
});
//task1、task2 執(zhí)行完執(zhí)行task3 ,需要感知task1和task2的執(zhí)行結(jié)果
CompletableFuture<Object> future = task1.thenCombineAsync(task2, (t1, t2) -> {
return "郵件發(fā)送成功";
});
}
方案二，Mq異步化處理，還是針對上述業(yè)務(wù)邏輯，我們是否可以將最終的發(fā)送郵件的動作剝離出來，最終再去統(tǒng)一執(zhí)行發(fā)送郵件。
關(guān)于偽代碼這里不展開了，有興趣的小伙伴可以自行實現(xiàn)一下。
總結(jié)
雖然有時候業(yè)務(wù)催的確實比較急，我們也不得不加班加點趕工擼代碼。但是我們不能由于這樣的原因而舍棄對系統(tǒng)性能的追求。有人說反正這個項目我后面不維護的，坑的話還是留一個下一個人去解決吧，代碼能跑就行，在此老貓還是想奉勸一句“研發(fā)何必為難研發(fā)”。在日常開發(fā)的過程中不僅僅是上面這樣的大事務(wù)問題，其實還有很多優(yōu)化的點，例如對象的創(chuàng)建，接口冪等，重試容錯等等。后續(xù)老貓會持續(xù)分享近年來的經(jīng)驗，可能不是最好的，但是希望對你有用，當(dāng)然也希望大家能夠給出寶貴建議，歡迎大家持續(xù)關(guān)注。
總結(jié)
以上是生活随笔為你收集整理的麻了，这让人绝望的大事务提交的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python异步编程之asyncio高阶
- 下一篇： Supershell防溯源反制配置