2020年是比較難過的一年，IT行業也不例外。平時多學習學習，保持核心競争力。我始終相信：隻要方向對了，努力堅持，該來的始終會來的。
今天來聊聊面試的必聊話題：事務。先抛出幾個問題：
- 什麼是事務。
- spring是怎麼實作事務的。
- 什麼是分布式事務。
- 分布式事務的實作方式。
什麼是事務？
事務是指一個業務邏輯中的一系列操作作為一個整體，這些操作要麼全部成功，要麼全部失敗復原。
事務四大特性：原子性，隔離性，持久性，一緻性。
原子性是基礎，隔離性，持久性是手段，一緻性是目的。一系列操作作為一個原子，不可再分割，通過事務間隔離，互不影響，執行結果持久化，達到最終的目的資料一緻性。
spring事務實作
在說spring事務實作前，看下JDBC的事務是怎麼實作的。
JDBC事務
核心是設定Connection手動送出，根據業務邏輯執行情況送出或復原操作。
使用過XML配置spring工程的都知道，需在XML配置事務管理器bean，事務通知和代理管理配置。
如：Hibernate，事務管理器為HibernateTransactionManager
還是聲明式事務
@Transactional
public void transactionBusiness() {
//業務邏輯
}
其原理都是底層建立在 AOP 的基礎之上的。其本質是對方法前後進行攔截，然後在目标方法開始之前建立或者加入一個事務，在執行完目标方法之後根據執行情況送出或者復原事務。
通過TransactionInterceptor 來定義相關的事務規則，其中一個核心屬性transactionManager，用來指定一個事務管理器，并将具體事務相關的操作委托給它。
在建立事務時createTransactionIfNecessary()調用tm.getTransaction(txAttr);擷取并開啟事務，設定autoCommit為false
分布式事務
分布式事務是指業務的一系列操作分布在不同的應用或不同的管理資源的原子性操作。既然是事務，也是要滿足傳統事務的四大特性。但由于分布在不同的應用，接口調用必然會存在着各種各樣的問題，如網絡分區。
分布式系統的兩大定理：
CAP
CAP原則又稱CAP定理，指的是在一個分布式系統中，一緻性(Consistency)、可用性(Availability)、分區容忍性(Partition tolerance)。CAP 原則指的是，這三個要素最多隻能同時實作兩點，不可能三者兼顧。
· 一緻性：在分布式系統中的所有資料備份，在同一時刻是否同樣的值。
· 可用性：在叢集中一部分節點故障後，叢集整體是否還能響應用戶端的讀寫請求。
· 分區容忍性：以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限内達成資料一緻性，就意味着發生了分區的情況，必須就目前操作在C和A之間做出選擇。
BASE理論
BASE理論是對CAP中的一緻性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一緻，但每個應用都可以根據自身的業務特點，采用适當的方式來使系統達到最終一緻性。
· Basically Available(基本可用)
· Soft state(軟狀态)
Eventually consistent(最終一緻性)
分布式事務解決方案：
類似于PlatformTransactionManager事務管理器，分布式事務引入了第三者充當管理器，統一排程各事務分支送出或復原。
兩階段送出(2PC)
階段一
a) 協調者向所有參與者發送事務内容，詢問是否可以送出事務，并等待答複。
b) 各參與者執行事務操作，将 undo 和 redo 資訊記入事務日志中(但不送出事務)。
c) 如參與者執行成功，給協調者回報 yes，否則回報 no。
階段二
如果協調者收到了參與者的失敗消息或者逾時，直接給每個參與者發送復原(rollback)消息；否則，發送送出(commit)消息。兩種情況處理如下：
情況1：當所有參與者均回報 yes，送出事務
a) 協調者向所有參與者發出正式送出事務的請求(即 commit 請求)。
b) 參與者執行 commit 請求，并釋放整個事務期間占用的資源。
c) 各參與者向協調者回報 ack(應答)完成的消息。
d) 協調者收到所有參與者回報的 ack 消息後，即完成事務送出。
情況2：當有一個參與者回報 no，復原事務
a) 協調者向所有參與者發出復原請求(即 rollback 請求)。
b) 參與者使用階段 1 中的 undo 資訊執行復原操作，并釋放整個事務期間占用的資源。
c) 各參與者向協調者回報 ack 完成的消息。
d) 協調者收到所有參與者回報的 ack 消息後，即完成事務。
三階段送出(3PC)
三階段送出是在二階段送出上的改進版本，3PC最關鍵要解決的就是協調者和參與者同時挂掉的問題，是以3PC把2PC的準備階段再次一分為二，這樣三階段送出。
無論2PC還是3PC，都依賴于資料庫的XA協定，且事務期間都一直占用着資源，高并發下性能有所影響。
補償事務(TCC)
TCC 是服務化的二階段程式設計模型，采用的補償機制
處理流程：
a) Try 階段主要是對業務系統做檢測及資源預留。
這個階段主要完成：
完成所有業務檢查( 一緻性 ) 。
預留必須業務資源( 準隔離性 ) 。
Try 嘗試執行業務。
b) Confirm 階段主要是對業務系統做确認送出。
Try階段執行成功并開始執行 Confirm階段時，預設 Confirm階段是不會出錯的。即：隻要Try成功，Confirm一定成功。
c) Cancel 階段主要是在業務執行錯誤，需要復原的狀态下執行的業務取消，預留資源釋放。
MQ事務消息(最終一緻性)
基于消息中間件的支援事務特性，如：rocketMQ。
處理流程：
- 消費者向MQ發送half消息。
- MQ Server将消息持久化後，向發送方ack确認消息發送成功。
- 消費者開始執行事務邏輯。
- 消費者根據本地事務執行結果向MQ Server送出二次确認或者復原。
- MQ Server收到commit狀态則将half消息标記可投遞狀态。
- 服務提供者收到該消息，執行本地業務邏輯。傳回處理結果。
終極大招：阿裡的seata。
Seata 是一款開源的分布式事務解決方案，緻力于提供高性能和簡單易用的分布式事務服務。Seata 将為使用者提供了 AT、TCC、SAGA 和 XA 事務模式，為使用者打造一站式的分布式解決方案。
最大特點是：各分支事務記錄業務資料和復原日記在本地事務後立即送出，釋放本地資源。追求對代碼無侵入。
個人看好seata，後面有時間學習一下再寫seata各種模式的具體實作。
以上是個人對事務的一些了解，不對的地方歡迎留言指出，不勝感謝。