## 前言 最近有個網友問了我一個問題：系統中大事務問題要如何處理？ 正好前段時間我在公司處理過這個問題，我們當時由於專案初期時間比較緊張，為了快速完成業務功能，忽略了系統部分效能問題。專案順利上線後，專門抽了一個迭代的時間去解決大事務問題，目前已經優化完成，並且順利上線。現給大家總結了一下，我們當時使用的一些解決辦法，以便大家被相同問題困擾時，可以參考一下。 ## 大事務引發的問題 在分享解決辦法之前，先看看系統中如果出現大事務可能會引發哪些問題  從上圖可以看出如果系統中出現大事務時，問題還不小，所以我們在實際專案開發中應該儘量避免大事務的情況。如果我們已有系統中存在大事務問題，該如何解決呢？ ## 解決辦法 ### 1.少用@Transactional註解 大家在實際專案開發中，我們在業務方法加上@Transactional註解開啟事務功能，這是非常普遍的做法，它被稱為宣告式事務。 部分程式碼如下： ```java @Transactional(rollbackFor=Exception.class) public void save(User user) { doSameThing... } ``` 然而，我要說的第一條是：少用@Transactional註解。 為什麼？ 我們知道@Transactional註解是通過spring的aop起作用的，但是如果使用不當，事務功能可能會失效。如果恰巧你經驗不足，這種問題不太好排查。至於事務哪些情況下會失效，可以參考我之前寫的《spring事務的這10種坑，你稍不注意可能就會踩中！！！》這篇文章。 @Transactional註解一般加在某個業務方法上，會導致整個業務方法都在同一個事務中，粒度太粗，不好控制事務範圍，是出現大事務問題的最常見的原因。 那我們該怎麼辦呢？ 可以使用程式設計式事務，在spring專案中使用TransactionTemplate類的物件，手動執行事務。 部分程式碼如下： ```java @Autowired private TransactionTemplate transactionTemplate; ... public void save(final User user) { transactionTemplate.execute((status) => { doSameThing... return Boolean.TRUE; }) } ``` 從上面的程式碼中可以看出，使用TransactionTemplate的程式設計式事務功能自己靈活控制事務的範圍，是避免大事務問題的首選辦法。 當然，我說少使用@Transactional註解開啟事務，並不是說一定不能用它，如果專案中有些業務邏輯比較簡單，而且不經常變動，使用@Transactional註解開啟事務開啟事務也無妨，因為它更簡單，開發效率更高，但是千萬要小心事務失效的問題。 ### 2.將查詢(select)方法放到事務外 如果出現大事務，可以將查詢(select)方法放到事務外，也是比較常用的做法，因為一般情況下這類方法是不需要事務的。 比如出現如下程式碼： ```java @Transactional(rollbackFor=Exception.class) public void save(User user) { queryData1(); queryData2(); addData1(); updateData2(); } ``` 可以將queryData1和queryData2兩個查詢方法放在事務外執行，將真正需要事務執行的程式碼才放到事務中，比如：addData1和updateData2方法，這樣就能有效的減少事務的粒度。 如果使用TransactionTemplate的程式設計式事務這裡就非常好修改。 ```java @Autowired private TransactionTemplate transactionTemplate; ... public void save(final User user) { queryData1(); queryData2(); transactionTemplate.execute((status) => { addData1(); updateData2(); return Boolean.TRUE; }) } ``` 但是如果你實在還是想用@Transactional註解，該怎麼拆分呢？ ```java 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方法上，把需要事務執行的程式碼移到新方法中。具體程式碼如下： ```java @Servcie publicclass ServiceA { @Autowired prvate ServiceB serviceB; public void save(User user) { queryData1(); queryData2(); serviceB.doSave(user); } } @Servcie publicclass ServiceB { @Transactional(rollbackFor=Exception.class) public void doSave(User user) { addData1(); updateData2(); } } ``` 2.在該Service類中注入自己 如果不想再新加一個Service類，在該Service類中注入自己也是一種選擇。具體程式碼如下： ```java @Servcie publicclass 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獲取代理物件，實現相同的功能。具體程式碼如下： ```java @Servcie publicclass ServiceA { public void save(User user) { queryData1(); queryData2(); ((ServiceA)AopContext.currentProxy()).doSave(user); } @Transactional(rollbackFor=Exception.class) public void doSave(User user) { addData1(); updateData2(); } } ``` ### 3.事務中避免遠端呼叫 我們在介面中呼叫其他系統的介面是不能避免的，由於網路不穩定，這種遠端調的響應時間可能比較長，如果遠端呼叫的程式碼放在某個事物中，這個事物就可能是大事務。當然，遠端呼叫不僅僅是指呼叫介面，還有包括：發MQ訊息，或者連線redis、mongodb儲存資料等。 ```java @Transactional(rollbackFor=Exception.class) public void save(User user) { callRemoteApi(); addData1(); } ``` 遠端呼叫的程式碼可能耗時較長，切記一定要放在事務之外。 ```java @Autowired private TransactionTemplate transactionTemplate; ... public void save(final User user) { callRemoteApi(); transactionTemplate.execute((status) => { addData1(); return Boolean.TRUE; }) } ``` 有些朋友可能會問，遠端呼叫的程式碼不放在事務中如何保證資料一致性呢？這就需要建立：重試+補償機制，達到資料最終一致性了。 ### 4.事務中避免一次性處理太多資料 如果一個事務中需要處理的資料太多，也會造成大事務問題。比如為了操作方便，你可能會一次批量更新1000條資料，這樣會導致大量資料鎖等待，特別在高併發的系統中問題尤為明顯。 解決辦法是分頁處理，1000條資料，分50頁，一次只處理20條資料，這樣可以大大減少大事務的出現。 ### 5.非事務執行 在使用事務之前，我們都應該思考一下，是不是所有的資料庫操作都需要在事務中執行？ ```java @Autowired private TransactionTemplate transactionTemplate; ... public void save(final User user) { transactionTemplate.execute((status) => { addData(); addLog(); updateCount(); return Boolean.TRUE; }) } ``` 上面的例子中，其實addLog增加操作日誌方法 和 updateCount更新統計數量方法，是可以不在事務中執行的，因為操作日誌和統計數量這種業務允許少量資料不一致的情況。 ```java @Autowired private TransactionTemplate transactionTemplate; ... public void save(final User user) { transactionTemplate.execute((status) => { addData(); return Boolean.TRUE; }) addLog(); updateCount(); } ``` 當然大事務中要鑑別出哪些方法可以非事務執行，其實沒那麼容易，需要對整個業務梳理一遍，才能找出最合理的答案。 ### 6.非同步處理 還有一點也非常重要，是不是事務中的所有方法都需要同步執行？我們都知道，方法同步執行需要等待方法返回，如果一個事務中同步執行的方法太多了，勢必會造成等待時間過長，出現大事務問題。 看看下面這個列子： ```java @Autowired private TransactionTemplate transactionTemplate; ... public void save(final User user) { transactionTemplate.execute((status) => { order(); delivery(); return Boolean.TRUE; }) } ``` order方法用於下單，delivery方法用於發貨，是不是下單後就一定要馬上發貨呢？ 答案是否定的。 這裡發貨功能其實可以走mq非同步處理邏輯。 ```java @Autowired private TransactionTemplate transactionTemplate; ... public void save(final User user) { transactionTemplate.execute((status) => { order(); return Boolean.TRUE; }) sendMq(); } ``` ### 總結 本人從網友的一個問題出發，結合自己實際的工作經驗分享了處理大事務的6種辦法： - 少用@Transactional註解 - 將查詢(select)方法放到事務外 - 事務中避免遠端呼叫 - 事務中避免一次性處理太多資料 - 非事務執行 - 非同步處理 ## 最後說一句 如果這篇文章對您有所幫助，或者有所啟發的話，幫忙掃描下發二維碼關注一下，或者點贊、轉發、在看。在公眾號中回覆：面試、程式碼神器、開發手冊、時間管理有超讚的粉絲福利，另外回覆：加群，可以跟很多大廠的前輩交流和學習。 ![](https://img2020.cnblogs.com/blog/2238006/202101/2238006-20210102131023742-13230695