您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“Spring Boot事務(wù)配置管理是什么”的有關(guān)知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠?qū)W有所成!
場景:我們在開發(fā)企業(yè)應用時,由于數(shù)據(jù)操作在順序執(zhí)行的過程中,線上可能有各種無法預知的問題,任何一步操作都有可能發(fā)生異常,異常則會導致后續(xù)的操作無法完成。此時由于業(yè)務(wù)邏輯并未正確的完成,所以在之前操作過數(shù)據(jù)庫的動作并不可靠,需要在這種情況下進行數(shù)據(jù)的回滾。
事務(wù)的作用就是為了保證用戶的每一個操作都是可靠的,事務(wù)中的每一步操作都必須成功執(zhí)行,只要有發(fā)生異常就回退到事務(wù)開始未進行操作的狀態(tài)。這很好理解,轉(zhuǎn)賬、購票等等,必須整個事件流程全部執(zhí)行完才能人為該事件執(zhí)行成功,不能轉(zhuǎn)錢轉(zhuǎn)到一半,系統(tǒng)死了,轉(zhuǎn)賬人錢沒了,收款人錢還沒到。
事務(wù)管理是 Spring Boot 框架中最為常用的功能之一,我們在實際應用開發(fā)時,基本上在 service 層處理業(yè)務(wù)邏輯的時候都要加上事務(wù),當然了,有時候可能由于場景需要,也不用加事務(wù)(比如我們就要往一個表里插數(shù)據(jù),相互沒有影響,插多少是多少,不能因為某個數(shù)據(jù)掛了,把之前插的全部回滾)。
在 Spring Boot 中使用事務(wù),需要導入 mysql 依賴:
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>1.3.2</version>
</dependency>
導入了 mysql 依賴后,Spring Boot 會自動注入 DataSourceTransactionManager,我們不需要任何其他的配置就可以用 @Transactional
注解進行事務(wù)的使用。關(guān)于 mybatis 的配置,在上一節(jié)課中已經(jīng)說明了,這里還是使用上一節(jié)課中的 mybatis 配置即可。
我們首先在數(shù)據(jù)庫表中插入一條數(shù)據(jù):
id | user_name | password |
---|---|---|
1 | 倪升武 | 123456 |
然后我們寫一個插入的 mapper:
public interface UserMapper {
@Insert("insert into user (user_name, password) values (#{username}, #{password})")
Integer insertUser(User user);
}
OK,接下來我們來測試一下 Spring Boot 中的事務(wù)處理,在 service 層,我們手動拋出個異常來模擬實際中出現(xiàn)的異常,然后觀察一下事務(wù)有沒有回滾,如果數(shù)據(jù)庫中沒有新的記錄,則說明事務(wù)回滾成功。
@Service
public class UserServiceImpl implements UserService {
@Resource
private UserMapper userMapper;
@Override
@Transactional
public void isertUser(User user) {
// 插入用戶信息
userMapper.insertUser(user);
// 手動拋出異常
throw new RuntimeException();
}
}
我們來測試一下:
@RestController
public class TestController {
@Resource
private UserService userService;
@PostMapping("/adduser")
public String addUser(@RequestBody User user) throws Exception {
if (null != user) {
userService.isertUser(user);
return "success";
} else {
return "false";
}
}
}
我們使用 postman 調(diào)用一下該接口,因為在程序中拋出了個異常,會造成事務(wù)回滾,我們刷新一下數(shù)據(jù)庫,并沒有增加一條記錄,說明事務(wù)生效了。事務(wù)很簡單,我們平時在使用的時候,一般不會有多少問題,但是并不僅僅如此……
從上面的內(nèi)容中可以看出,Spring Boot 中使用事務(wù)非常簡單,@Transactional
注解即可解決問題,說是這么說,但是在實際項目中,是有很多小坑在等著我們,這些小坑是我們在寫代碼的時候沒有注意到,而且正常情況下不容易發(fā)現(xiàn)這些小坑,等項目寫大了,某一天突然出問題了,排查問題非常困難,到時候肯定是抓瞎,需要費很大的精力去排查問題。
這一小節(jié),我專門針對實際項目中經(jīng)常出現(xiàn)的,和事務(wù)相關(guān)的細節(jié)做一下總結(jié),希望讀者在讀完之后,能夠落實到自己的項目中,能有所受益。
首先要說的,就是異常并沒有被 ”捕獲“ 到,導致事務(wù)并沒有回滾。我們在業(yè)務(wù)層代碼中,也許已經(jīng)考慮到了異常的存在,或者編輯器已經(jīng)提示我們需要拋出異常,但是這里面有個需要注意的地方:并不是說我們把異常拋出來了,有異常了事務(wù)就會回滾,我們來看一個例子:
@Service
public class UserServiceImpl implements UserService {
@Resource
private UserMapper userMapper;
@Override
@Transactional
public void isertUser2(User user) throws Exception {
// 插入用戶信息
userMapper.insertUser(user);
// 手動拋出異常
throw new SQLException("數(shù)據(jù)庫異常");
}
}
我們看上面這個代碼,其實并沒有什么問題,手動拋出一個 SQLException
來模擬實際中操作數(shù)據(jù)庫發(fā)生的異常,在這個方法中,既然拋出了異常,那么事務(wù)應該回滾,實際卻不如此,讀者可以使用我源碼中 controller 的接口,通過 postman 測試一下,就會發(fā)現(xiàn),仍然是可以插入一條用戶數(shù)據(jù)的。
那么問題出在哪呢?因為 Spring Boot 默認的事務(wù)規(guī)則是遇到運行異常(RuntimeException)和程序錯誤(Error)才會回滾。比如上面我們的例子中拋出的 RuntimeException 就沒有問題,但是拋出 SQLException 就無法回滾了。針對非檢測異常,如果要進行事務(wù)回滾的話,可以在 @Transactional
注解中使用 rollbackFor
屬性來指定異常,比如 @Transactional(rollbackFor = Exception.class)
,這樣就沒有問題了,所以在實際項目中,一定要指定異常。
這個標題很搞笑,異常怎么會被吃掉呢?還是回歸到現(xiàn)實項目中去,我們在處理異常時,有兩種方式,要么拋出去,讓上一層來捕獲處理;要么把異常 try catch 掉,在異常出現(xiàn)的地方給處理掉。就因為有這中 try...catch,所以導致異常被 ”吃“ 掉,事務(wù)無法回滾。我們還是看上面那個例子,只不過簡單修改一下代碼:
@Service
public class UserServiceImpl implements UserService {
@Resource
private UserMapper userMapper;
@Override
@Transactional(rollbackFor = Exception.class)
public void isertUser3(User user) {
try {
// 插入用戶信息
userMapper.insertUser(user);
// 手動拋出異常
throw new SQLException("數(shù)據(jù)庫異常");
} catch (Exception e) {
// 異常處理邏輯
}
}
}
讀者可以使用我源碼中 controller 的接口,通過 postman 測試一下,就會發(fā)現(xiàn),仍然是可以插入一條用戶數(shù)據(jù),說明事務(wù)并沒有因為拋出異常而回滾。這個細節(jié)往往比上面那個坑更難以發(fā)現(xiàn),因為我們的思維很容易導致 try...catch 代碼的產(chǎn)生,一旦出現(xiàn)這種問題,往往排查起來比較費勁,所以我們平時在寫代碼時,一定要多思考,多注意這種細節(jié),盡量避免給自己埋坑。
那這種怎么解決呢?直接往上拋,給上一層來處理即可,千萬不要在事務(wù)中把異常自己 ”吃“ 掉。
事務(wù)范圍這個東西比上面兩個坑埋的更深!我之所以把這個也寫上,是因為這是我之前在實際項目中遇到的,該場景在這個課程中我就不模擬了,我寫一個 demo 讓大家看一下,把這個坑記住即可,以后在寫代碼時,遇到并發(fā)問題,就會注意這個坑了,那么這節(jié)課也就有價值了。
我來寫個 demo:
@Service
public class UserServiceImpl implements UserService {
@Resource
private UserMapper userMapper;
@Override
@Transactional(rollbackFor = Exception.class)
public synchronized void isertUser4(User user) {
// 實際中的具體業(yè)務(wù)……
userMapper.insertUser(user);
}
}
可以看到,因為要考慮并發(fā)問題,我在業(yè)務(wù)層代碼的方法上加了個 synchronized 關(guān)鍵字。我舉個實際的場景,比如一個數(shù)據(jù)庫中,針對某個用戶,只有一條記錄,下一個插入動作過來,會先判斷該數(shù)據(jù)庫中有沒有相同的用戶,如果有就不插入,就更新,沒有才插入,所以理論上,數(shù)據(jù)庫中永遠就一條同一用戶信息,不會出現(xiàn)同一數(shù)據(jù)庫中插入了兩條相同用戶的信息。
但是在壓測時,就會出現(xiàn)上面的問題,數(shù)據(jù)庫中確實有兩條同一用戶的信息,分析其原因,在于事務(wù)的范圍和鎖的范圍問題。
從上面方法中可以看到,方法上是加了事務(wù)的,那么也就是說,在執(zhí)行該方法開始時,事務(wù)啟動,執(zhí)行完了后,事務(wù)關(guān)閉。但是 synchronized 沒有起作用,其實根本原因是因為事務(wù)的范圍比鎖的范圍大。也就是說,在加鎖的那部分代碼執(zhí)行完之后,鎖釋放掉了,但是事務(wù)還沒結(jié)束,此時另一個線程進來了,事務(wù)沒結(jié)束的話,第二個線程進來時,數(shù)據(jù)庫的狀態(tài)和第一個線程剛進來是一樣的。即由于mysql Innodb引擎的默認隔離級別是可重復讀(在同一個事務(wù)里,SELECT的結(jié)果是事務(wù)開始時時間點的狀態(tài)),線程二事務(wù)開始的時候,線程一還沒提交完成,導致讀取的數(shù)據(jù)還沒更新。第二個線程也做了插入動作,導致了臟數(shù)據(jù)。
這個問題可以避免,第一,把事務(wù)去掉即可(不推薦);第二,在調(diào)用該 service 的地方加鎖,保證鎖的范圍比事務(wù)的范圍大即可。
本章主要總結(jié)了 Spring Boot 中如何使用事務(wù),只要使用 @Transactional
注解即可使用,非常簡單方便。除此之外,重點總結(jié)了三個在實際項目中可能遇到的坑點,這非常有意義,因為事務(wù)這東西不出問題還好,出了問題比較難以排查,所以總結(jié)的這三點注意事項,希望能幫助到開發(fā)中的朋友。
“Spring Boot事務(wù)配置管理是什么”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。