當前位置:聯(lián)升科技 > 技術資訊 > 開發(fā)技術 >

讓人頭痛的大事務問題到底要如何解決?

2020-11-30    作者:因為熱愛所以堅持    來源:蘇三說技術    閱讀:

本文轉載自微信公眾號「蘇三說技術」,作者因為熱愛所以堅持ing。轉載本文請聯(lián)系蘇三說技術公眾號。 
前言
最近有個網友問了我一個問題:系統(tǒng)中大事務問題要如何處理?
正好前段時間我在公司處理過這個問題,我們當時由于項目初期時間比較緊張,為了快速完成業(yè)務功能,忽略了系統(tǒng)部分性能問題。項目順利上線后,專門抽了一個迭代的時間去解決大事務問題,目前已經優(yōu)化完成,并且順利上線?,F(xiàn)給大家總結了一下,我們當時使用的一些解決辦法,以便大家被相同問題困擾時,可以參考一下。
大事務引發(fā)的問題
在分享解決辦法之前,先看看系統(tǒng)中如果出現(xiàn)大事務可能會引發(fā)哪些問題

從上圖可以看出如果系統(tǒng)中出現(xiàn)大事務時,問題還不小,所以我們在實際項目開發(fā)中應該盡量避免大事務的情況。如果我們已有系統(tǒng)中存在大事務問題,該如何解決呢?
解決辦法
少用@Transactional注解
大家在實際項目開發(fā)中,我們在業(yè)務方法加上@Transactional注解開啟事務功能,這是非常普遍的做法,它被稱為聲明式事務。
部分代碼如下:
@Transactional(rollbackFor=Exception.class) 
  public void save(User user) { 
        doSameThing... 
  } 
然而,我要說的第一條是:少用@Transactional注解。
為什么?
我們知道@Transactional注解是通過spring的aop起作用的,但是如果使用不當,事務功能可能會失效。如果恰巧你經驗不足,這種問題不太好排查。至于事務哪些情況下會失效,可以參考我之前寫的《spring事務的這10種坑,你稍不注意可能就會踩中!!!》這篇文章。
@Transactional注解一般加在某個業(yè)務方法上,會導致整個業(yè)務方法都在同一個事務中,粒度太粗,不好控制事務范圍,是出現(xiàn)大事務問題的最常見的原因。
那我們該怎么辦呢?
可以使用編程式事務,在spring項目中使用TransactionTemplate類的對象,手動執(zhí)行事務。
部分代碼如下:
@Autowired 
   private TransactionTemplate transactionTemplate; 
    
   ... 
    
   public void save(final User user) { 
         transactionTemplate.execute((status) => { 
            doSameThing... 
            return Boolean.TRUE; 
         }) 
   } 
從上面的代碼中可以看出,使用TransactionTemplate的編程式事務功能自己靈活控制事務的范圍,是避免大事務問題的首選辦法。
當然,我說少使用@Transactional注解開啟事務,并不是說一定不能用它,如果項目中有些業(yè)務邏輯比較簡單,而且不經常變動,使用@Transactional注解開啟事務開啟事務也無妨,因為它更簡單,開發(fā)效率更高,但是千萬要小心事務失效的問題。
將查詢(select)方法放到事務外
如果出現(xiàn)大事務,可以將查詢(select)方法放到事務外,也是比較常用的做法,因為一般情況下這類方法是不需要事務的。
比如出現(xiàn)如下代碼:
@Transactional(rollbackFor=Exception.class) 
   public void save(User user) { 
         queryData1(); 
         queryData2(); 
         addData1(); 
         updateData2(); 
   } 
可以將queryData1和queryData2兩個查詢方法放在事務外執(zhí)行,將真正需要事務執(zhí)行的代碼才放到事務中,比如: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方法上,把需要事務執(zhí)行的代碼移到新方法中。具體代碼如下:
@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(); 
      } 
   } 
可能有些人可能會有這樣的疑問:這種做法會不會出現(xiàn)循環(huán)依賴問題?
其實spring ioc內部的三級緩存保證了它,不會出現(xiàn)循環(huán)依賴問題。如果你想進一步了解循環(huán)依賴問題,可以看看我之前文章《spring解決循環(huán)依賴為什么要用三級緩存?》。
3.在該Service類中使用AopContext.currentProxy()獲取代理對象
上面的方法2確實可以解決問題,但是代碼看起來并不直觀,還可以通過在該Service類中使用AOPProxy獲取代理對象,實現(xiàn)相同的功能。具體代碼如下:
@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(); 
      } 
   } 
事務中避免遠程調用
我們在接口中調用其他系統(tǒng)的接口是不能避免的,由于網絡不穩(wěn)定,這種遠程調的響應時間可能比較長,如果遠程調用的代碼放在某個事物中,這個事物就可能是大事務。當然,遠程調用不僅僅是指調用接口,還有包括:發(fā)MQ消息,或者連接redis、mongodb保存數(shù)據等。
@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; 
         }) 
   } 
有些朋友可能會問,遠程調用的代碼不放在事務中如何保證數(shù)據一致性呢?這就需要建立:重試+補償機制,達到數(shù)據最終一致性了。
事務中避免一次性處理太多數(shù)據
如果一個事務中需要處理的數(shù)據太多,也會造成大事務問題。比如為了操作方便,你可能會一次批量更新1000條數(shù)據,這樣會導致大量數(shù)據鎖等待,特別在高并發(fā)的系統(tǒng)中問題尤為明顯。
解決辦法是分頁處理,1000條數(shù)據,分50頁,一次只處理20條數(shù)據,這樣可以大大減少大事務的出現(xiàn)。
非事務執(zhí)行
在使用事務之前,我們都應該思考一下,是不是所有的數(shù)據庫操作都需要在事務中執(zhí)行?
@Autowired 
   private TransactionTemplate transactionTemplate; 
    
   ... 
    
   public void save(final User user) { 
         transactionTemplate.execute((status) => { 
            addData(); 
            addLog(); 
            updateCount(); 
            return Boolean.TRUE; 
         }) 
   } 
上面的例子中,其實addLog增加操作日志方法 和 updateCount更新統(tǒng)計數(shù)量方法,是可以不在事務中執(zhí)行的,因為操作日志和統(tǒng)計數(shù)量這種業(yè)務允許少量數(shù)據不一致的情況。
@Autowired 
   private TransactionTemplate transactionTemplate; 
    
   ... 
    
   public void save(final User user) { 
         transactionTemplate.execute((status) => { 
            addData();            
            return Boolean.TRUE; 
         }) 
         addLog(); 
         updateCount(); 
   } 
當然大事務中要鑒別出哪些方法可以非事務執(zhí)行,其實沒那么容易,需要對整個業(yè)務梳理一遍,才能找出最合理的答案。
異步處理
還有一點也非常重要,是不是事務中的所有方法都需要同步執(zhí)行?我們都知道,方法同步執(zhí)行需要等待方法返回,如果一個事務中同步執(zhí)行的方法太多了,勢必會造成等待時間過長,出現(xiàn)大事務問題。
看看下面這個列子:
@Autowired 
   private TransactionTemplate transactionTemplate; 
    
   ... 
    
   public void save(final User user) { 
         transactionTemplate.execute((status) => { 
            order(); 
            delivery(); 
            return Boolean.TRUE; 
         }) 
   } 
order方法用于下單,delivery方法用于發(fā)貨,是不是下單后就一定要馬上發(fā)貨呢?
答案是否定的。
這里發(fā)貨功能其實可以走mq異步處理邏輯。
@Autowired 
   private TransactionTemplate transactionTemplate; 
    
   ... 
    
   public void save(final User user) { 
         transactionTemplate.execute((status) => { 
            order(); 
            return Boolean.TRUE; 
         }) 
         sendMq(); 
   } 
總結
本人從網友的一個問題出發(fā),結合自己實際的工作經驗分享了處理大事務的6種辦法:
少用@Transactional注解
將查詢(select)方法放到事務外
事務中避免遠程調用
事務中避免一次性處理太多數(shù)據
非事務執(zhí)行
異步處理


相關文章

我們很樂意傾聽您的聲音!
即刻與我們取得聯(lián)絡
成為日后肩并肩合作的伙伴。

行業(yè)資訊

聯(lián)系我們

13387904606

地址:新余市仙女湖區(qū)仙女湖大道萬商紅A2棟

手機:13755589003
QQ:122322500
微信號:13755589003

江西新余網站設計_小程序制作_OA系統(tǒng)開發(fā)_企業(yè)ERP管理系統(tǒng)_app開發(fā)-新余聯(lián)升網絡科技有限公司 贛ICP備19013599號-1   贛公網安備 36050202000267號   

微信二維碼