事物特性(acid)
原子性（A）
所謂的原子性就是說，在整個事務中的所有操作，要麼全部完成，要麼全部不做，沒有中間狀態。對於事務在執行中發生錯誤，所有的操作都會被回滾，整個事務就像從沒被執行過一樣。
一致性（C）
事務的執行必須保證系統的一致性，就拿轉賬爲例，A有500元，B有300元，如果在一個事務裏A成功轉給B50元，那麼不管併發多少，不管發生什麼，只要事務執行成功了，那麼最後A賬戶一定是450元，B賬戶一定是350元。
隔離性（I）
所謂的隔離性就是說，事務與事務之間不會互相影響，一個事務的中間狀態不會被其他事務感知。
持久性（D）
所謂的持久性，就是說一單事務完成了，那麼事務對數據所做的變更就完全保存在了數據庫中，即使發生停電，系統宕機也是如此。
事物隔離級別
髒讀：事務T1讀取到事務T2修改了但是還未提交的數據，之後事務T2又回滾其更新操作，導致事務T1讀到的是髒數據。
不可重複讀：事務T1讀取某個數據後，事務T2對其做了修改，當事務T1再次讀該數據時得到與前一次不同的值。
幻讀：事務T1讀取在讀取某範圍數據時，事務T2又插入一條數據，當事務T1再次數據這個範圍數據時發現不一樣了，出現了一些“幻影行”。
不可重複讀和髒讀的區別：髒讀是某一事務讀取了另一個事務未提交的髒數據，而不可重複讀則是讀取了前一事務提交的數據。
幻讀和不可重複讀的異同：都是讀取了另一條已經提交的事務（這點就髒讀不同），所不同的是不可重複讀查詢的都是同一個數據項，而幻讀針對的是一批數據整體（比如數據的個數）。
分佈式項目落地問題：
1.單體應用拆分爲分佈式系統後，進程間的通訊機制和故障處理措施變的更加複雜。
2.系統微服務化後，一個看似簡單的功能，內部可能需要調用多個服務並操作多個數據庫實現，服務調用的分佈式事務問題變的非常突出。
3.微服務數量衆多，其測試、部署、監控等都變的更加困難。
分佈式事物解決方案：
基於XA協議的兩階段提交方案
交易中間件與數據庫通過 XA 接口規範，使用兩階段提交來完成一個全局事務， XA 規範的基礎是兩階段提交協議。
第一階段是表決階段，所有參與者都將本事務能否成功的信息反饋發給協調者；第二階段是執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交或者回滾。
兩階段提交協議可以很好得解決分佈式事務問題，它可以使用 XA 來實現，XA 它包含兩個部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，比如 Oracle、DB2 這些商業數據庫都實現了 XA 接口，而事務管理器作爲全局的協調者，負責各個本地資源的提交和回滾。
消息中間件：消息中間件也可稱作消息系統 (MQ)，它本質上是一個暫存轉發消息的一箇中間件。在分佈式應用當中，我們可以把一個業務操作轉換成一個消息，比如支付寶的餘額轉如餘額寶操作，支付寶系統執行減少餘額操作之後向消息系統發一個消息，餘額寶系統訂閱這條消息然後進行增加賬戶金額操作。
RocketMQ第一階段發送Prepared消息時，會拿到消息的地址，第二階段執行本地事物，第三階段通過第一階段拿到的地址去訪問消息，並修改消息的狀態。
細心的你可能又發現問題了，如果確認消息發送失敗了怎麼辦？RocketMQ會定期掃描消息集羣中的事物消息，如果發現了Prepared消息，它會向消息發送端(生產者)確認，Bob的錢到底是減了還是沒減呢？如果減了是回滾還是繼續發送確認消息呢？RocketMQ會根據發送端設置的策略來決定是回滾還是繼續發送確認消息。這樣就保證了消息發送與本地事務同時成功或同時失敗。
兩階段提交方案應用非常廣泛，幾乎所有商業OLTP數據庫都支持XA協議。但是兩階段提交方案鎖定資源時間長，對性能影響很大，基本不適合解決微服務事務問題。
TCC方案
TCC方案在電商、金融領域落地較多。TCC方案其實是兩階段提交的一種改進。其將整個業務邏輯的每個分支顯式的分成了Try、Confirm、Cancel三個操作。Try部分完成業務的準備工作，confirm部分完成業務的提交，cancel部分完成事務的回滾。基本原理如下圖所示。
事務開始時，業務應用會向事務協調器註冊啓動事務。之後業務應用會調用所有服務的try接口，完成一階段準備。之後事務協調器會根據try接口返回情況，決定調用confirm接口或者cancel接口。如果接口調用失敗，會進行重試。
TCC方案讓應用自己定義數據庫操作的粒度，使得降低鎖衝突、提高吞吐量成爲可能。 當然TCC方案也有不足之處，集中表現在以下兩個方面：
對應用的侵入性強：業務邏輯的每個分支都需要實現try、confirm、cancel三個操作，應用侵入性較強，改造成本高。
**實現難度較大：**需要按照網絡狀態、系統故障等不同的失敗原因實現不同的回滾策略。爲了滿足一致性的要求，confirm和cancel接口必須實現冪等。
基於消息的最終一致性方案
消息一致性方案是通過消息中間件保證上、下游應用數據操作的一致性。基本思路是將本地操作和發送消息放在一個事務中，保證本地操作和消息發送要麼兩者都成功或者都失敗。下游應用向消息系統訂閱該消息，收到消息後執行相應操作。
消息方案從本質上講是將分佈式事務轉換爲兩個本地事務，然後依靠下游業務的重試機制達到最終一致性。基於消息的最終一致性方案對應用侵入性也很高，應用需要進行大量業務改造，成本較高
GTS–分佈式事務解決方案
GTS的核心優勢
1.性能超強
GTS通過大量創新，解決了事務ACID特性與高性能、高可用、低侵入不可兼得的問題。單事務分支的平均響應時間在2ms左右，3臺服務器組成的集羣可以支撐3萬TPS以上的分佈式事務請求。
2.應用侵入性極低
GTS對業務低侵入，業務代碼最少只需要添加一行註解（@TxcTransaction）聲明事務即可。業務與事務分離，將微服務從事務中解放出來，微服務關注於業務本身，不再需要考慮反向接口、冪等、回滾策略等複雜問題，極大降低了微服務開發的難度與工作量。
3.完整解決方案
GTS支持多種主流的服務框架，包括EDAS，Dubbo，Spring Cloud等。
有些情況下，應用需要調用第三方系統的接口，而第三方系統沒有接入GTS。此時需要用到GTS的MT模式。GTS的MT模式可以等價於TCC模式，用戶可以根據自身業務需求自定義每個事務階段的具體行爲。MT模式提供了更多的靈活性，可能性，以達到特殊場景下的自定義優化及特殊功能的實現。
4.容錯能力強
GTS解決了XA事務協調器單點問題，實現真正的高可用，可以保證各種異常情況下的嚴格數據一致。