目錄

• 事務的基本特征
• 隔離級別
• 傳播行為
• @Transcation

事務的基本特征（ACID）

Atomic（原子性）

　　事務中包含的操作被看作一個整體的業務單元，這個業務單元中的操作要么全部成功，要么全部失敗，不會出現部分失敗和部分成功的場景

Consistency（一致性）

　　事務在完成時，必須使所有的數據都保持一直狀態，在數據庫中所有的修改都基于事務，保證了數據的完整性

Isolation（隔離性）

　　多個應用程序線程同時訪問統一數據，這樣數據庫同樣的數據就會在各個不同的事務中被訪問，這樣會產生丟失更新，為了壓制丟失更新的產生，數據庫定義了隔離級別的概念，通過它的選擇，可以在不同程度上壓制丟失更新的產生。因為互聯網的應用常常面對高并發的場景，所以隔離性是需要掌握的重點內容

Durability（持久性）

　　事務結束后，所有的數據都會固化到一個地方，如保存磁盤當中，即時斷電重啟后也可以提供應用程序訪問

---

　　為了壓制丟失更新，數據庫提出了隔離級別，在不同程度上壓制更新

　　也許會有一個疑問，都全部消除丟失更新不就好了嗎，為什么只是在不同的程度.上壓制丟失更新呢?

　　其實這個問題是從兩個角度去看的，一個是數據的一致性，另一個是性能。數據庫現有的技術完全可以避免丟失更新，但是這樣做的代價，就是付出鎖的代價，在互聯網中，系統不單單要考慮數據的-致性，還要考慮系統的性能。試想，在互聯網中使用過多的鎖，--旦出現商品搶購這樣的場景，必然會導致大量的線程被掛起和恢復，因為使用了鎖之后，一個時刻只能有一個線程訪問數據，這樣整個系統就會十分緩慢，當系統被數千甚至數萬用戶同時訪問時，過多的鎖就會引發宕機，大部分用戶線程被掛起，等待持有鎖事務的完成，這樣用戶體驗就會十分糟糕。因為用戶等待的時間會十分漫長，一般而言，互聯網系統響應超過5秒，就會讓用戶覺得很不友好，進而引發用戶忠誠度下降的問題。所以選擇隔離級別的時候，既需要考慮數據的一致性避免臟數據，又要考慮系統性能的問題。因此數據庫的規范就提出了4種隔離級別來在不同的程度上壓制丟失更新。

隔離級別

未提交讀

　　最低的隔離級別，含義是允許一個事務讀取另外一個事務沒有提交的數據。未提交讀是一種危險的隔離級別，實際開發中應用不廣

• 優點：并發能力高。適合那些對數據一致性沒有要求而追求高并發的場景
• 缺點：出現臟讀

讀寫提交

　　指一個事務只能讀取一個事務已經提交的數據，不能讀取未提交的數據

• 優點：克服臟讀
• 缺點：出現不可重復讀

可重復讀

　　可重復讀的目標是克服讀寫提交中出現的不可重復讀的現象，因為在讀寫提交的時候，可能出現一些值的變化，影響當前事務的執行

• 優點：克服不可重復讀
• 缺點：出現幻讀

串行化

　　數據庫最高的隔離級別，它會要求所有的SQL都會按照順序執行，這樣就可以克服上訴隔離級別出現的各種問題，所以它能完全保證數據的一致性

---

　　追求更高的隔離級別，它能更好地保證數據的一致性，但是也要付出鎖的代價。有了鎖，就意味著性能的丟失，而且隔離級別越高，性能越是直線下降。

　　所以在選擇隔離級別時，要考慮的不單單是數據一致性問題，還要考慮系統的性能問題

　　一般而言，選擇隔離級別會以讀寫提交為主，它能防止臟讀，而不能避免不可重復讀和幻讀，為了克服數據不一致性和性能問題，程序開發者還設計了樂觀鎖，甚至不再使用數據庫而使用其他手段

　　對于隔離級別，不同的數據庫支持也是不一樣的

• Oracle只支持讀寫提交和串行化，默認隔離級別為讀寫提交
• MySQL能支持4種，默認隔離級別為可重復讀

傳播行為

　　在Spring中，當一個方法調用另外一個方法，可以讓事務采取不同的策略工作，如新建事務或掛起當前事務

?????

　　在一個批量任務執行的過程中，調用多個交易時，如果有一些交易發生異常，只是回滾出現異常的交易，而不是里整個批量任務，這樣就能夠是的那些沒有問題的交易可以吮吸完成，而有問題的交易則不做任何事情

---

@Transcation

　　對于聲明式事務，使用@Transaction進行標注，可標注在類活著方法上，當它標注在類上時，代表這個類所有公共（public）非靜態的方法都將啟用事務功能

　　默認配置下 Spring 只會回滾運行時、未檢查異常（繼承自 RuntimeException 的異常）或者 Error。

• 捕獲RuntimeException
• 捕獲Error
• 并不捕獲Checked Exception

有了@Transcation,Spring就會知道從哪啟動事務，約定流程：

當上下文開始調用被@Transcation標注的類或者方法時，Spring就會產生AOP的功能。請注意事務的底層需要啟動AOP功能，這就是Spring事務的底層實現

如有一個保存用戶的方法，加入 @Transactional 注解，使用默認配置，拋出異常之后，事務會自動回滾，數據不會插入到數據庫。

@RestController public class HouseController {@Autowiredprivate HouseRepository houseRepository;@GetMapping("/test1")public String test1(){houseRepository.save(new House("house1", "100平方米"));houseRepository.save(new House("house2", "100平方米"));houseRepository.save(new House("house3", "100平方米"));houseRepository.save(new House("house444444444", "100平方米"));houseRepository.save(new House("house5", "100平方米"));return "success";}@GetMapping("/test2")@Transactionalpublic String test2(){houseRepository.save(new House("house6", "100平方米"));houseRepository.save(new House("house7", "100平方米"));houseRepository.save(new House("house8", "100平方米"));houseRepository.save(new House("house999999999", "100平方米"));houseRepository.save(new House("house10", "100平方米"));return "success";} }

test1方法沒有加入事務，test2方法加入了事務注解。

　　test1：當輸入http://localhost:8888/test1

　　

數據庫中插入了三條數據

因為第四條數據太長，所以插入失敗，導致第五條正常數據插入失敗，這并不是我們想要的，要么全成功，要么全失敗

　　test2：輸入http://localhost:8888/test2

數據庫中數據不變依然是三條數據，插入失敗，所以全部回滾

---

本文借鑒：《深入淺出Spring Boot 2.x》書中有更詳細的例子

返回頂部

轉載于:https://www.cnblogs.com/echola/p/10999052.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的SpringBoot声明式事务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。