讓人頭痛的大事務問題到底要如何解決？
本文轉載自微信公眾號「蘇三說技術」，作者因為熱愛所以堅持ing。轉載本文請聯系蘇三說技術公眾號。
前言
最近有個網友問了我一個問題：系統中大事務問題要如何處理?
正好前段時間我在公司處理過這個問題，我們當時由于項目初期時間比較緊張，為了快速完成業務功能，忽略了系統部分性能問題。項目順利上線后，專門抽了一個迭代的時間去解決大事務問題，目前已經優化完成，并且順利上線。現給大家總結了一下，我們當時使用的一些解決辦法，以便大家被相同問題困擾時，可以參考一下。
大事務引發的問題
在分享解決辦法之前，先看看系統中如果出現大事務可能會引發哪些問題
從上圖可以看出如果系統中出現大事務時，問題還不小，所以我們在實際項目開發中應該盡量避免大事務的情況。如果我們已有系統中存在大事務問題，該如何解決呢?
解決辦法
少用@Transactional注解
大家在實際項目開發中，我們在業務方法加上@Transactional注解開啟事務功能，這是非常普遍的做法，它被稱為聲明式事務。
部分代碼如下：
- @Transactional(rollbackFor=Exception.class)
- public void save(User user) {
- doSameThing...
- }
然而，我要說的第一條是：少用@Transactional注解。
為什么?
- 我們知道@Transactional注解是通過spring的aop起作用的，但是如果使用不當，事務功能可能會失效。如果恰巧你經驗不足，這種問題不太好排查。至于事務哪些情況下會失效，可以參考我之前寫的《spring事務的這10種坑，你稍不注意可能就會踩中!!!》這篇文章。
- @Transactional注解一般加在某個業務方法上，會導致整個業務方法都在同一個事務中，粒度太粗，不好控制事務范圍，是出現大事務問題的最常見的原因。
那我們該怎么辦呢?
可以使用編程式事務，在spring項目中使用TransactionTemplate類的對象，手動執行事務。
部分代碼如下：
- @Autowired
- private TransactionTemplate transactionTemplate;
- ...
- public void save(final User user) {
- transactionTemplate.execute((status) => {
- doSameThing...
- return Boolean.TRUE;
- })
- }
從上面的代碼中可以看出，使用TransactionTemplate的編程式事務功能自己靈活控制事務的范圍，是避免大事務問題的首選辦法。
當然，我說少使用@Transactional注解開啟事務，并不是說一定不能用它，如果項目中有些業務邏輯比較簡單，而且不經常變動，使用@Transactional注解開啟事務開啟事務也無妨，因為它更簡單，開發效率更高，但是千萬要小心事務失效的問題。
將查詢(select)方法放到事務外
如果出現大事務，可以將查詢(select)方法放到事務外，也是比較常用的做法，因為一般情況下這類方法是不需要事務的。
比如出現如下代碼：
- @Transactional(rollbackFor=Exception.class)
- public void save(User user) {
- queryData1();
- queryData2();
- addData1();
- updateData2();
- }
可以將queryData1和queryData2兩個查詢方法放在事務外執行，將真正需要事務執行的代碼才放到事務中，比如：addData1和updateData2方法，這樣就能有效的減少事務的粒度。
如果使用TransactionTemplate的編程式事務這里就非常好修改。
- @Autowired
- private TransactionTemplate transactionTemplate;
- ...
- public void save(final User user) {
- queryData1();
- queryData2();
- transactionTemplate.execute((status) => {
- addData1();
- updateData2();
- return Boolean.TRUE;
- })
- }
但是如果你實在還是想用@Transactional注解，該怎么拆分呢?
- public void save(User user) {
- queryData1();
- queryData2();
- doSave();
- }
- @Transactional(rollbackFor=Exception.class)
- public void doSave(User user) {
- addData1();
- updateData2();
- }
這個例子是非常經典的錯誤，這種直接方法調用的做法事務不會生效，給正在坑中的朋友提個醒。因為@Transactional注解的聲明式事務是通過spring aop起作用的，而spring aop需要生成代理對象，直接方法調用使用的還是原始對象，所以事務不會生效。
有沒有辦法解決這個問題呢?
1.新加一個Service方法
這個方法非常簡單，只需要新加一個Service方法，把@Transactional注解加到新Service方法上，把需要事務執行的代碼移到新方法中。具體代碼如下：
- @Servcie
- public class ServiceA {
- @Autowired
- prvate ServiceB serviceB;
- public void save(User user) {
- queryData1();
- queryData2();
- serviceB.doSave(user);
- }
- }
- @Servcie
- public class ServiceB {
- @Transactional(rollbackFor=Exception.class)
- public void doSave(User user) {
- addData1();
- updateData2();
- }
- }
2.在該Service類中注入自己
如果不想再新加一個Service類，在該Service類中注入自己也是一種選擇。具體代碼如下：
- @Servcie
- public class ServiceA {
- @Autowired
- prvate ServiceA serviceA;
- public void save(User user) {
- queryData1();
- queryData2();
- serviceA.doSave(user);
- }
- @Transactional(rollbackFor=Exception.class)
- public void doSave(User user) {
- addData1();
- updateData2();
- }
- }
可能有些人可能會有這樣的疑問：這種做法會不會出現循環依賴問題?
其實spring ioc內部的三級緩存保證了它，不會出現循環依賴問題。如果你想進一步了解循環依賴問題，可以看看我之前文章《spring解決循環依賴為什么要用三級緩存?》。
3.在該Service類中使用AopContext.currentProxy()獲取代理對象
上面的方法2確實可以解決問題，但是代碼看起來并不直觀，還可以通過在該Service類中使用AOPProxy獲取代理對象，實現相同的功能。具體代碼如下：
- @Servcie
- public class ServiceA {
- public void save(User user) {
- queryData1();
- queryData2();
- ((ServiceA)AopContext.currentProxy()).doSave(user);
- }
- @Transactional(rollbackFor=Exception.class)
- public void doSave(User user) {
- addData1();
- updateData2();
- }
- }
事務中避免遠程調用
我們在接口中調用其他系統的接口是不能避免的，由于網絡不穩定，這種遠程調的響應時間可能比較長，如果遠程調用的代碼放在某個事物中，這個事物就可能是大事務。當然，遠程調用不僅僅是指調用接口，還有包括：發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;
- })
- }
有些朋友可能會問，遠程調用的代碼不放在事務中如何保證數據一致性呢?這就需要建立：重試+補償機制，達到數據最終一致性了。
事務中避免一次性處理太多數據
如果一個事務中需要處理的數據太多，也會造成大事務問題。比如為了操作方便，你可能會一次批量更新1000條數據，這樣會導致大量數據鎖等待，特別在高并發的系統中問題尤為明顯。
解決辦法是分頁處理，1000條數據，分50頁，一次只處理20條數據，這樣可以大大減少大事務的出現。
非事務執行
在使用事務之前，我們都應該思考一下，是不是所有的數據庫操作都需要在事務中執行?
- @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();
- }
當然大事務中要鑒別出哪些方法可以非事務執行，其實沒那么容易，需要對整個業務梳理一遍，才能找出最合理的答案。
異步處理
還有一點也非常重要，是不是事務中的所有方法都需要同步執行?我們都知道，方法同步執行需要等待方法返回，如果一個事務中同步執行的方法太多了，勢必會造成等待時間過長，出現大事務問題。
看看下面這個列子：
- @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)方法放到事務外
- 事務中避免遠程調用
- 事務中避免一次性處理太多數據
- 非事務執行
- 異步處理
