所謂的大事務就是耗時比較長的事務。
Spring有兩種方式實現事務，分別是程式設計式和宣告式兩種。
不手動開啟事務，mysql 預設自動提交事務，一條語句執行完自動提交。
一、大事務產生的原因
- 操作的資料比較多
- 呼叫了 rpc 方法
- 有其他非 DB 的耗時操作
- 大量的鎖競爭
- 執行了比較耗時的計算
二、大事務造成的影響
- 併發情況下，資料庫連線池容易被撐爆
- 鎖定太多的資料，造成大量的阻塞和鎖超時
- 執行時間長，容易造成主從延遲
- 回滾所需要的時間比較長
- undo log日誌膨脹，不僅增加了儲存的空間，而且可能降低查詢的效能
最主要的影響資料庫連線池容易被撐爆，導致大量執行緒等待，造成請求無響應或請求超時。
三、大事務優化方案
1、使用程式設計式事務
在實際專案開發中，有多個寫請求就需要用到事務,我們在業務方法加上@Transactional註解開啟事務功能，這是非常普遍的做法，它被稱為宣告式事務。
部分程式碼如下：
@Transactional
public void save(User user) {
//doSameThing...
}
然而，我要說的第一條是：少用@Transactional註解。
為什麼？
- 我們知道@Transactional註解是通過spring的aop起作用的，但是如果使用不當，事務功能可能會失效。如果恰巧你經驗不足，這種問題不太好排查。
- @Transactional 註解一般加在某個業務方法上，會導致整個業務方法都在同一個事務中，粒度太粗，不好控制事務範圍，是出現大事務問題的最常見的原因。
那我們該怎麼辦呢？
可以使用程式設計式事務，在spring專案中使用TransactionTemplate類的物件，手動執行事務。
部分程式碼如下：
@Autowired
private TransactionTemplate transactionTemplate;
public void save() {
transactionTemplate.execute((status) -> {
userMapper.insertSelective(user);
goodsMapper.insert(goods);
return Boolean.TRUE;
});
}
如果是在說在程式設計式事務事務中，需要回滾，我們可以這樣操作
public void save() {
transactionTemplate.execute((status) -> {
userMapper.insertSelective(user);
//直接拋異常，就會自動回滾
Assert.error("業務邏輯沒通過，直接報錯");
goodsMapper.insert(goods);
return Boolean.TRUE;
});
}
從上面的程式碼中可以看出，使用TransactionTemplate的程式設計式事務功能自己靈活控制事務的範圍，是避免大事務問題的首選辦法。
當然，我說少使用@Transactional註解開啟事務，並不是說一定不能用它，如果專案中有些業務邏輯比較簡單，而且不經常變動，使用@Transactional註解開啟事務開啟事務
也無妨，因為它更簡單，開發效率更高，但是千萬要小心事務失效的問題。
2、將查詢(select)方法放到事務外
如果出現大事務，可以將查詢(select)方法放到事務外，也是比較常用的做法，因為一般情況下這類方法是不需要事務的。
比如出現如下程式碼：
@Transactional(rollbackFor=Exception.class)
public void save() {
queryData1();
queryData2();
saveData1();
updateData2();
}
可以將 queryData1 和 queryData2 兩個查詢方法放在事務外執行，將真正需要事務執行的程式碼才放到事務中，比如：saveData1 和updateData2 方法，這樣就能有效的
減少事務的粒度。
如果使用TransactionTemplate的 程式設計式事務 這裡就非常好修改。
public void save() {
queryData1();
queryData2();
transactionTemplate.execute((status) -> {
saveData1();
updateData2();
return Boolean.TRUE;
})
}
但是如果你實在還是想用@Transactional註解，該怎麼拆分呢？
public void save() {
queryData1();
queryData2();
doSave();
}
@Transactional(rollbackFor = Exception.class)
public void doSave() {
saveData1();
updateData2();
}
這個例子是非常經典的錯誤，這種直接方法呼叫的做法事務不會生效，給正在坑中的朋友提個醒。因為@Transactional註解的宣告式事務是通過spring aop起作用的，
而spring aop 需要生成代理物件，直接方法呼叫使用的還是原始物件，所以事務不會生效。
有沒有辦法解決這個問題呢？
1、新加一個Service方法
這個方法非常簡單，只需要新加一個Service方法，把 @Transactional 註解加到新Service方法上，把需要事務執行的程式碼移到新方法中。
具體程式碼如下：
@Servcie
publicclass ServiceA {
@Autowired
prvate ServiceB serviceB;
public void save() {
queryData1();
queryData2();
serviceB.doSave();
}
}
@Servcie
publicclass ServiceB {
@Transactional(rollbackFor=Exception.class)
public void doSave() {
saveData1();
updateData2();
}
}
2、在該Service類中注入自己
如果不想再新加一個Service類，在該Service類中注入自己也是一種選擇。
具體程式碼如下：
@Servcie
public class ServiceA {
@Autowired
prvate ServiceA serviceA;
public void save() {
queryData1();
queryData2();
serviceA.doSave();
}
@Transactional(rollbackFor = Exception.class)
public void doSave() {
saveData1();
updateData2();
}
}
可能有些人可能會有這樣的疑問：這種做法會不會出現迴圈依賴問題？
其實spring ioc內部的三級快取保證了它，不會出現迴圈依賴問題。
3、在該Service類中使用AopContext.currentProxy()獲取代理物件
上面的方法2確實可以解決問題，但是程式碼看起來並不直觀，還可以通過在該Service類中使用AOPProxy獲取代理物件，實現相同的功能。具體程式碼如下：
@Servcie
publicclass ServiceA {
public void save() {
queryData1();
queryData2();
((ServiceA)AopContext.currentProxy()).doSave();
}
@Transactional(rollbackFor=Exception.class)
public void doSave() {
saveData1();
updateData2();
}
}
3、事務中避免遠端呼叫
我們在介面中呼叫其他系統的介面是不能避免的，由於網路不穩定，這種遠端調的響應時間可能比較長，如果遠端呼叫的程式碼放在某個事物中，這個事物就可能是大事務。
當然，遠端呼叫不僅僅是指呼叫介面，還有包括：發MQ訊息，或者連線redis、mongodb儲存資料等。
@Transactional(rollbackFor=Exception.class)
public void save(User user) {
callRemoteApi();
addData1();
}
遠端呼叫的程式碼可能耗時較長，切記一定要放在事務之外。
@Autowired
private TransactionTemplate transactionTemplate;
public void save(final User user) {
callRemoteApi();
transactionTemplate.execute((status) => {
addData1();
return Boolean.TRUE;
})
}
有些朋友可能會問，遠端呼叫的程式碼不放在事務中如何保證資料一致性呢？這就需要建立：重試+補償機制，達到資料最終一致性了。
4、事務中避免一次性處理太多資料
如果一個事務中處理的資料太多，也會造成大事務問題。比如為了操作方便，你可能會一次批量更新1000條資料，這樣會導致大量資料鎖等待，在高併發的系統中問題尤為明顯。
解決辦法是分頁處理，1000條資料，分20頁，前端每次請求只處理當頁面50條資料，這樣可以大大減少大事務的出現。
5、是否可以通過非事務方式執行
在使用事務之前，我們都應該思考一下，是不是所有的資料庫操作都需要在事務中執行？
@Autowired
private TransactionTemplate transactionTemplate;
...
public void save(final User user) {
transactionTemplate.execute((status) => {
addData();
addLog();
updateCount();
return Boolean.TRUE;
})
}
上面的例子中，其實addLog增加操作日誌方法 和 updateCount更新統計數量方法，是可以不在事務中執行的，因為操作日誌和統計數量這種業務允許少量資料不一致的情況。
@Autowired
private TransactionTemplate transactionTemplate;
...
public void save(final User user) {
transactionTemplate.execute((status) => {
addData();
return Boolean.TRUE;
})
addLog();
updateCount();
}
當然大事務中要鑑別出哪些方法可以非事務執行，其實沒那麼容易，需要對整個業務梳理一遍，才能找出最合理的答案。
6、是否可以通過非同步處理？
還有一點也非常重要，是不是事務中的所有方法都需要同步執行？
我們都知道，方法同步執行需要等待方法返回，如果一個事務中同步執行的方法太多了，勢必會造成等待時間過長，出現大事務問題。
看看下面這個列子：
@Autowired
private TransactionTemplate transactionTemplate;
...
public void save(final User user) {
transactionTemplate.execute((status) => {
order();
delivery();
return Boolean.TRUE;
})
}
order方法用於下單，delivery方法用於發貨，是不是下單後就一定要馬上發貨呢？
答案是否定的。
這裡發貨功能其實可以走mq非同步處理邏輯。
@Autowired
private TransactionTemplate transactionTemplate;
...
public void save(final User user) {
transactionTemplate.execute((status) => {
order();
return Boolean.TRUE;
})
sendMq();
}
總結
本人從網友的一個問題出發，結合自己實際的工作經驗分享了處理大事務的6種辦法：
- 少用@Transactional註解
- 將查詢(select)方法放到事務外
- 事務中避免遠端呼叫
- 事務中避免一次性處理太多資料
- 非事務執行
- 非同步處理
參考
1、讓人頭痛的大事務問題到底要如何解決？(非常感謝，這篇部落格主要基於本篇）
2、注意Spring事務這一點，避免出現大事務
3、spring 大事務