作為后端開發的程序員,我們常常會的一些相對比較復雜的邏輯,比如我們需要給前端寫一個調用的接口,這個接口需要進行相對比較復雜的業務邏輯操作,比如會進行,查詢、遠程接口或本地接口調用、更新、插入、計算等一些邏輯,將最終接口的返回結果給到前端,而經過這么一系列的業務邏輯操作,接口對DB的操作、對代碼業務邏輯判斷、進行接口調用這些都是需要時間的,而只要這是一個事務操作,每次對數據庫進行的交互都會產生一條事務記錄。
那么這樣就會對我們接口返回的效率產生影響,而且這個影響是隨著數據量的增長而增長的,這時候我們就需要對一整個大事務進行拆分,從而提升整體接口的效率。
就拿我最近開發寫的一個接口來說吧,大致是這么一個邏輯,我需要根據頁面的提交的數據生成一個收款單,整體接口處理的業務如下,我把它們寫在了一個接口里,可以理解為這是一個大事物,這個接口執行的時間是相對比較長的,而且將這些邏輯全部寫在一個接口里面,本身來說也是不太合理的。
圖片
不加鎖的情況下,由于種種原因第一次接口的調用還沒執行完,還在等待第三方的調用回寫數據,第二次調用又進來對數據進行了更改,第二次調用先執行完,這時候第一次接口調用拿到了第三方接口的返回,去回寫狀態發現已經被更新,導致無效操作。
加鎖的情況下, 不會出現數據不一致情況,但是由于大事物執行時間較長,容易造成鎖超時失效,鎖定太多的數據造成阻塞,嚴重影響效率。
容易造成Undo logo日志數據量很大,降低了日志的查詢性能,包括對事務的回滾效率也會降低。
并發量達到一定程度,會對數據庫讀寫造成不小的壓力,會堆積大量等待線程。
首先事務里面進行遠程的接口調用,如果不采用分布式事務框架,本身就會存在事務不一致的情況,無法進行數據的回滾操作,并發情況下遠程服務響應不及時,會出現接口返回不一致問題,當然必須采用異步調用,后面會提到。
聲明式事務只需要加在方法頭加@Transactional注解即可開啟事務,但是還是不太靈活,意味著整個方法所進行對數據庫操作都要加進事務,當然一次查詢也要進入事務,這并不是我們想要的,我們在update、insert操作上進行事務操作,方便進行回滾。
public Boolean transactionCommit(String userName) { //查詢用戶 SysUser sysUser = userMapper.selectUserByUserName(userName,null); transactionTemplate.execute(new TransactionCallbackWithoutResult() { @Override protected void doInTransactionWithoutResult(TransactionStatus transactionStatus) { try { if (null != sysUser) { //用戶信息狀態更新 status更新為1 userMapper.updateStatus(userName); } } catch (Exception e){ //回滾 transactionStatus.setRollbackOnly(); } } }); //再次查詢 SysUser sysUser1 = userMapper.selectUserByUserName(userName,"1"); /log/.info("狀態為1的用戶信息"+JSON./toJSONString/(sysUser1)); return true;}
編程式事務的靈活點在于可以控制事務執行方法,運用transactionTemplate類進行事務操作,查詢操作可以寫在外面,這樣查詢獲取數據的操作就不會進入mysql事務表。
對于事務的更新或者插入,前端可能會有批量操作,大規模數據的批量更新、插入也會對事務接口產生影響,一旦其中有更新或插入失敗,為了保證事務的一致性,整個操作都要進行回滾;
List<List<ReceivableFeeSaveDTO>> partition = Lists.partition(receivableFeeSaveDTOList, 50);
可以將一個事務接口,拆分成多個事務接口,并且每個事務接口只做一件事,比如上面的收款單生成接口,金額回寫、第三方接口調用、調用后的結果回寫都可以抽成一個哥小事務接口。
就好比做一件很復雜的事情,咋一眼看上去很復雜,但是我們把這復雜的步驟,進行多個步驟的拆分,每個階段完成每個階段的事情,就可以將整個過程簡化,看起來就沒那么復雜了。
重中之重,事務里如果無法避免遠程調用,那么肯定是需要進行異步調用,因為無法保證遠程接口的及時響應性,CompletableFuture異步編排特性可以用到,task1和task2任務結束后,執行task3。
CompletableFuture<Object> task1 =CompletableFuture.supplyAsync(() -> { System.out.println("單號check線程" + Thread.currentThread().getId()); //單號check接口 校驗失敗拋出異常 return "賬單實體信息";}, executor);CompletableFuture<Object> task2 = CompletableFuture.supplyAsync(() -> { System.out.println("收款單生成線程" + Thread.currentThread().getId()); try { //收款單生成 return “賬單編號”; Thread.sleep(3000); System.out.println("任務2結束:"); } catch (InterruptedException e) { e.printStackTrace(); }}, executor); //task1、task2 執行完執行task3 ,需要感知task1和task2的執行結果CompletableFuture<Boolean> future = task1.thenCombineAsync(task2, (t1, t2) -> { System.out.println("賬單金額回寫線程" + Thread.currentThread().getId()); // t1 、t2返回判斷 //回寫返回結果 return ture;}, executor);
可見大事務是我們接口效率低下的罪魁禍首,有時候我們為了快速實現功能,可能會忽略一些關乎于性能的東西,而這些東西是我們能力提升的一個契機。
本文鏈接:http://www.www897cc.com/showinfo-26-35873-0.html接口中的大事務,該如何進行優化?
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com