事務的基本特征（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 { @Autowired private 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") @Transactional public 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》書中有更詳細的例子
返回頂部