1、ACID，事務的四個特性
1）原子性，原子性是指事務是一個不可分割的工作單位，事務中的操作要麼都發生，要麼都不發生。
2）一致性，如果事務執行之前數據庫是一個完整性的狀態,那麼事務結束後,無論事務是否執行成功,數據庫仍然是一個完整性狀態。
數據庫的完整性狀態：當一個數據庫中的所有的數據都符合數據庫中所定義的所有的約束,此時可以稱數據庫是一個完整性狀態。
3）隔離性:事務的隔離性是指多個用戶併發訪問數據庫時，一個用戶的事務不能被其它用戶的事務所幹擾，多個併發事務之間事務要隔離。
4）持久性:持久性是指一個事務一旦被提交，它對數據庫中數據的改變就是永久性的，接下來即使數據庫發生故障也不應該對其有任何影響。
2、數據庫事務隔離級別
數據庫事務的隔離級別有4個，由低到高依次爲Read uncommitted（讀未提交） 、Read committed （讀提交）、Repeatable read （重複讀）、Serializable （序列化）
1） Read UnCommitted(讀未提交)
最低的隔離級別。一個事務可以讀取另一個事務並未提交的更新結果。
2）Read Committed(讀提交)
大部分數據庫採用的默認隔離級別。一個事務的更新操作結果只有在該事務提交之後，另一個事務纔可以的讀取到同一筆數據更新後的結果。
3） Repeatable Read(重複讀)
mysql的默認級別。整個事務過程中，對同一筆數據的讀取結果是相同的，不管其他事務是否在對共享數據進行更新，也不管更新提交與否。
4）Serializable(序列化)
最高隔離級別。所有事務操作依次順序執行。注意這會導致併發度下降，性能最差。通常會用其他併發級別加上相應的併發鎖機制來取代它。
https://blog.csdn.net/qq_36897901/article/details/80454504
3、髒讀、幻讀、不可重複讀
1.髒讀：
髒讀就是指當一個事務正在訪問數據，並且對數據進行了修改，而這種修改還沒有提交到數據庫中，這時，另外一個事務也訪問這個數據，然後使用了這個數據。
2.不可重複讀：
是指在一個事務內，多次讀同一數據。在這個事務還沒有結束時，另外一個事務也訪問該同一數據。那麼，在第一個事務中的兩次讀數據之間，由於第二個事務的修改，那麼第一個事務兩次讀到的的數據可能是不一樣的。這樣就發生了在一個事務內兩次讀到的數據是不一樣的，因此稱爲是不可重複讀。（即不能讀到相同的數據內容）
例如，一個編輯人員兩次讀取同一文檔，但在兩次讀取之間，作者重寫了該文檔。當編輯人員第二次讀取文檔時，文檔已更改。原始讀取不可重複。如果只有在作者全部完成編寫後編輯人員纔可以讀取文檔，則可以避免該問題。
3.幻讀:
是指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的數據進行了修改，這種修改涉及到表中的全部數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那麼，以後就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺一樣。
例如，一個編輯人員更改作者提交的文檔，但當生產部門將其更改內容合併到該文檔的主複本時，發現作者已將未編輯的新材料添加到該文檔中。如果在編輯人員和生產部門完成對原始文檔的處理之前，任何人都不能將新材料添加到文檔中，則可以避免該問題。
4、丟失更新：
一個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如：用戶A把值從6改爲2，用戶B把值從2改爲6，則用戶A丟失了他的更新。
4.事務隔離五種級別：
TRANSACTION_NONE 不使用事務。
TRANSACTION_READ_UNCOMMITTED 允許髒讀。
TRANSACTION_READ_COMMITTED 防止髒讀，最常用的隔離級別,並且是大多數數據庫的默認隔離級別
TRANSACTION_REPEATABLE_READ 可以防止髒讀和不可重複讀，
TRANSACTION_SERIALIZABLE 可以防止髒讀，不可重複讀取和幻讀，（事務串行化）會降低數據庫的效率
5.Spring中的事務回滾
1）代碼中事務控制的3種方式
編程式事務：就是直接在代碼裏手動開啓事務，手動提交，手動回滾。優點就是可以靈活控制，缺點就是太麻煩了，太多重複的代碼了。
聲明式事務：就是使用SpringAop配置事務，這種方式大大的簡化了編碼。需要注意的是切入點表達式一定要寫正確。
註解事務：直接在Service層的方法上面加上@Transactional註解，現在咱們框架用這種方式。
2）事務不回滾的原因
事務不回滾的都是採用的聲明式事務或者是註解事務；編程式事務都是自己寫代碼手動回滾的，因此是不會出現不回滾的現象。
再說下聲明式事務和註解事務回滾的原理：當被切面切中或者是加了註解的方法中拋出了RuntimeException異常時，Spring會進行事務回滾。默認情況下是捕獲到方法的RuntimeException異常，也就是說拋出只要屬於運行時的異常（即RuntimeException及其子類）都能回滾；但當拋出一個不屬於運行時異常時，事務是不會回滾的。
3）下面說說我經常見到的3種事務不回滾的產生原因：
聲明式事務配置切入點表達式寫錯了，沒切中Service中的方法
Service方法中，把異常給try catch了，但catch裏面只是打印了異常信息，沒有手動拋出RuntimeException異常
Service方法中，拋出的異常不屬於運行時異常（如IO異常），因爲Spring默認情況下是捕獲到運行時異常就回滾
4）如何保證事務回滾
正常情況下，按照正確的編碼是不會出現事務回滾失敗的。下面說幾點保證事務能回滾的方法
（1）如果採用編程式事務，一定要確保切入點表達式書寫正確
（2）如果Service層會拋出不屬於運行時異常也要能回滾，那麼可以將Spring默認的回滾時的異常修改爲Exception，這樣就可以保證碰到什麼異常都可以回滾。具體的設置方式也說下：
① 聲明式事務，在配置裏面添加一個rollback-for，代碼如下
<tx:method name="update*" propagation="REQUIRED" rollback-for="java.lang.Exception"/>
② 註解事務，直接在註解上面指定，代碼如下
@Transactional(rollbackFor=Exception.class)
（3）只有非只讀事務才能回滾的，只讀事務是不會回滾的
（4）如果在Service層用了try catch，在catch裏面再拋出一個 RuntimeException異常，這樣出了異常纔會回滾
（5）如果你不喜歡（4）的方式，你還可以直接在catch後面寫一句回滾代碼（TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();）來實現回滾，這樣的話，就可以在拋異常後也能return 返回值；比較適合需要拿到Service層的返回值的場景。具體的用法可以參見考下面的僞代碼
/** TransactionAspectSupport手動回滾事務：*/
@Transactional(rollbackFor = { Exception.class })
public boolean test() {
try {
doDbSomeThing();
} catch (Exception e) {
e.printStackTrace();
//就是這一句了, 加上之後拋了異常就能回滾（有這句代碼就不需要再手動拋出運行時異常了）
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
return false;
}
return true;
}
6.分佈式事務管理
1）Spring中事務針對的的是同一數據庫中的操作，所以分佈式分庫操作不能擁有同一事務
2）解決方案：TCC編程模式
所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業務邏輯分爲三塊：Try、Confirm和Cancel三個操作。以在線下單爲例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存。