1、數據庫事務
數據庫事務是由一組SQL語句組成的，所有的SQL語句執行成功則事務整體成功，任一條SQL語句失敗則事務整體失敗，數據恢復到事務之前的狀態。數據操作的最小單元就是事務，而不是SQL語句！
2、SQL事務操作
1、開啟事務（start transaction / begin）：事務開始之后，對數據的增刪改查操作不會直接修改數據庫，而是被記錄在日志文件中
2、提交事務（commit）：將日志中記錄的操作，永久保存到數據庫中，並清空日志文件
3、回滾事務（rollback）：直接清空日志文件
3、事務四大特性
原子性：事務中的操作要么全部成功，要么全部失敗
一致性：事務操作執行前后狀態一致
持久性：事務提交之后，數據永久保存到數據庫中
隔離性：一個事務的執行不能被其他事務干擾
4、數據庫並發訪問沖突問題
4.1、臟讀：讀取到其他事務未提交的數據
4.2、不可重復讀：多次讀取同一數據，得到的結果不同
4.3、幻讀：讀取到已經被刪除的數據/讀取不到新插入的數據
5、MySQL的四種事務隔離級別
讀未提交（READ-UNCOMMITTED）
讀已提交（READ-COMMITTED）
可重復讀（REPEATABLE-READ）MySQL的默認隔離級別
串行化（SERIALIZABLE）
6、分布式事務
在微服務系統中，每個微服務應用都可能會有自己的數據庫，它們首先需要控制自己的本地事務。
一項業務操作可能會調用執行多個微服務。如何保證多個服務執行的多個數據庫的操作整體成功或整體失敗？這就是分布式事務要解決的問題。
7、CAP原則和BASE
CAP原則 C：一致性 A：可用性 P：分區容錯性
在分布式事務中
如果保證CP，就意味着要讓所有子系統的數據操作要么全部成功，要么全部失敗，不允許有不一致的情況發生。但是強一致性會造成性能下降。
如果保證AP，就意味着可以犧牲一定的一致性，允許在各個子系統中存在有的數據操作成功，有的數據操作失敗的情況，只要通過后續處理，能夠達到最終一致即可。
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個單詞的簡寫
8、分布式事務方案
XA、TCC、Seata框架AT事務、SAGA、可靠消息最終一致性、最大努力通知等。
8.1、Seata 的 AT 模式（Automatic Transaction）是一種無侵入的分布式事務解決方案。
Seata AT 事務分兩個階段來管理全局事務：
第一階段： 執行各分支事務
TC事務協調器：協調各個服務的運行狀態
TM事務管理器：
RM資源管理器：
XID全局事務ID：
微服務系統中，各服務之間無法相互感知事務是否執行成功，這時就需要一個專門的服務，來協調各個服務的運行狀態。這個服務稱為 TC（Transaction Coordinator），事務協調器。
訂單系統開始執行保存訂單之前，首先啟動TM，由TM向TC申請開啟一個全局事務，這時TC會產生一個全局事務ID（XID），並傳回給TM，這樣子就開啟了全局事務。
全局事務開啟后，開始執行創建訂單的業務。首先執行保存訂單，這時會先啟動一個 RM（Resource Manager，資源管理器），並將 XID 傳遞給 RM。
RM 負責對分支事務（即微服務的本地事務）進行管理，並與 TC 通信，上報分支事務的執行狀態、接收全局事務的提交或回滾指令。RM 首先會使用 XID 向 TC 注冊分支事務，將分支事務納入對應的全局事務管轄。
現在可以執行保存訂單的分支事務了。一旦分支事務執行成功，RM 會上報事務狀態；TC 收到后，會將該狀態信息傳遞到 TM；到此，保存訂單過程結束。下面是調用庫存服務，減少商品庫存，與訂單的執行過程相同。
第二階段： 控制全局事務最終提交或回滾
TM（全局事務管理器）收集齊了全部分支事務的成功狀態，它會進行決策，確定全局事務成功，向 TC 發送全局事務的提交請
然后，TC 會向所有 RM 發送提交操作指令，RM 會完成最終提交操作
總結：TC（事務協調器）統一協調所有的各個服務的運行狀態，並將結果匯報給到TM（事務管理器），進行的訂單服務，執行的操作，都需要向TC匯報，然后TC統一匯報給TM，TM向TC發起全局事務處理請求，TC會向所有RM（資源管理器）發送請求指令，完成事務操作。
Seata的具體工作機制（以訂單為例）：
第一階段：執行分支事務
減少庫存操作：在執行修改操作之前，先取出舊數據，然后修改庫存，將更新后的庫存數據取出，和舊數據合並，保存到一個事務回滾日志表：undo_log表，至此，第一階段分支事務完成，將狀態上報給TC。
第二階段：控制全局事務最終回滾
假如全局事務失敗，那么第一階段已提交的分支事務就要進行回滾操作
首先會收到TC的全局事務回滾指令，根據事務回滾日志表（undo_log表）的記錄，將數據恢復為舊的庫存數據，然后刪除事務日志，完成第二階段的回滾操作。
第二階段：控制全局事務最終提交
首先收到TC的全局事務提交指令，接着刪除事務日志，就完成了第二階段提交操作。
詳細博客講解：
https://blog.csdn.net/weixin_38305440/article/details/107583229
8.2、TCC
TCC 與 Seata AT 事務一樣都是兩階段事務，它與 AT 事務的主要區別為：
TCC 對業務代碼侵入嚴重：每個階段的數據操作都要自己進行編碼來實現，事務框架無法自動處理。
TCC 效率更高：不必對數據加全局鎖，允許多個事務同時操作數據。
以金額扣減為例
第一階段Try（預留業務資源/凍結）:
假如用戶購買100元商品，要扣減100元，TCC事務首先對這100元的扣減金額進行預留，或者說凍結這100元。
第二階段 Confirm（業務提交）:
如果第一階段能夠順利完成，那么說明“扣減金額”業務（分支事務）最終肯定是可以成功的。當全局事務提交時， TC會控制當前分支事務進行提交，如果提交失敗，TC 會反復嘗試，直到提交成功為止。
當全局事務提交時，就可以使用凍結的金額來最終實現業務數據操作：
第二階段 Cancel（業務回滾）:
如果全局事務回滾，就把凍結的金額進行解凍，恢復到以前的狀態，TC 會控制當前分支事務回滾，如果回滾失敗，TC 會反復嘗試，直到回滾完成為止。