（一）基礎概念：↓ ↓ ↓
什麼是事務？舉個生活中的例子：你去小賣鋪買東西，“一手交錢，一手交貨”就是一個事務的例子，交錢和交貨必 須全部成功，
事務才算成功，任一個活動失敗，事務將撤銷所有已成功的活動。
明白上述例子，再來看事務的定義：
在計算機系統中，更多的是通過關係型資料庫來控制事務，這是利用資料庫本身的事務特性來實現的，因此叫資料 庫事務，由於應用主要靠關聯式資料庫來控制事務，
而資料庫通常和應用在同一個伺服器，所以基於關係型資料庫的 事務又被稱為本地事務。
回顧一下資料庫事務的四大特性 ACID：
A ：（Atomic）：原子性，構成事務的所有操作，要麼都執行完成，要麼全部不執行，不可能出現部分成功部分失 敗的情況。
C ：（Consistency）：一致性，在事務執行前後，資料庫的一致性約束沒有被破壞。比如：張三向李四轉100元， 轉賬前和轉賬後的資料是正確狀態這叫一致性，
如果出現張三轉出100元，李四賬戶沒有增加100元這就出現了數 據錯誤，就沒有達到一致性。
I ：（Isolation）：隔離性，資料庫中的事務一般都是併發的，隔離性是指併發的兩個事務的執行互不干擾，一個事 務不能看到其他事務執行過程的中間狀態。通過配置事務隔離級別可以避髒讀、重複讀等問題。
D ：（Durability）：永續性，事務完成之後，該事務對資料的更改會被持久化到資料庫，且不會被回滾。
資料庫事務在實現時會將一次事務涉及的所有操作全部納入到一個不可分割的執行單元，該執行單元中的所有操作 要麼都成功，要麼都失敗，只要其中任一操作執行失敗，都將導致整個事務的回滾
1.3、分散式事務
隨著網際網路的快速發展，軟體系統由原來的單體應用轉變為分散式應用，下圖描述了單體應用向微服務的演變
分散式系統會把一個應用系統拆分為可獨立部署的多個服務，因此需要服務與服務之間遠端協作才能完成事務操 作，
這種分散式系統環境下由不同的服務之間通過網路遠端協作完成事務稱之為分散式事務，
例如使用者註冊送積分 事務、建立訂單減庫存事務，銀行轉賬事務等都是分散式事務。
我們知道本地事務依賴資料庫本身提供的事務特性來實現，因此以下邏輯可以控制本地事務：
begin transaction；
//1.本地資料庫操作：張三減少金額
//2.本地資料庫操作：李四增加金額
commit transation;
begin transaction；
//1.本地資料庫操作：張三減少金額
//2.遠端呼叫：讓李四增加金額
commit transation;
可以設想，當遠端呼叫讓李四增加金額成功了，由於網路問題遠端呼叫並沒有返回，此時本地事務提交失敗就回滾 了張三減少金額的操作，此時張三和李四的資料就不一致了。
因此在分散式架構的基礎上，傳統資料庫事務就無法使用了，張三和李四的賬戶不在一個資料庫中甚至不在一個應 用系統裡，實現轉賬事務需要通過遠端呼叫，由於網路問題就會導致分散式事務問題。
1.4、 分散式事務產生的場景
1）：典型的場景就是微服務架構 微服務之間通過遠端呼叫完成事務操作。
比如：訂單微服務和庫存微服務，下單的 同時訂單微服務請求庫存微服務減庫存。
簡言之：跨JVM程式產生分散式事務。
2）：單體系統訪問多個資料庫例項 當單體系統需要訪問多個資料庫（例項）時就會產生分散式事務。
比如：使用者信 息和訂單資訊分別在兩個MySQL例項儲存，使用者管理系統刪除使用者資訊，需要分別刪除使用者資訊及使用者的訂單信 息，
由於資料分佈在不同的資料例項，需要通過不同的資料庫連結去運算元據，此時產生分散式事務。
簡言之：跨 資料庫例項產生分散式事務。
3）：多服務訪問同一個資料庫例項 比如：
訂單微服務和庫存微服務即使訪問同一個資料庫也會產生分散式事務，原 因就是跨JVM程式，兩個微服務持有了不同的資料庫連結進行資料庫操作，此時產生分散式事務。
=========================== 華麗分割線 ==========================
（二）分散式事務基礎理論：↓ ↓ ↓
通過前面的學習，我們瞭解到了分散式事務的基礎概念。
與本地事務不同的是，分散式系統之所以叫分散式，是因 為提供服務的各個節點分佈在不同機器上，相互之間通過網路互動。
不能因為有一點網路問題就導致整個系統無法 提供服務，網路因素成為了分散式事務的考量標準之一。
因此，分散式事務需要更進一步的理論支援，接下來，我 們先來學習一下分散式事務的CAP理論。↓ ↓ ↓
在講解分散式事務控制解決方案之前需要先學習一些基礎理論，通過理論知識指導我們確定分散式事務控制的目 標，從而幫助我們理解每個解決方案。
2.1）：CAP理論
2.1.1）：理解CAP
CAP是 Consistency、Availability、Partition tolerance 三個詞語的縮寫，分別表示一致性、可用性、分割槽容忍 性。
下邊我們分別來解釋： 為了方便對CAP理論的理解，我們結合電商系統中的一些業務場景來理解CAP。
如下圖，是商品資訊管理的執行流程 ↓ ↓ ↓
整體執行流程如下：
1、商品服務請求主資料庫寫入商品資訊（新增商品、修改商品、刪除商品）
2、主資料庫向商品服務響應寫入成功。
3、商品服務請求從資料庫讀取商品資訊。
C - Consistency：
一致性是指寫操作後的讀操作可以讀取到最新的資料狀態，當資料分佈在多個節點上，從任意結點讀取到的資料都 是最新的狀態。
上圖中，商品資訊的讀寫要滿足一致性就是要實現如下目標：
1、商品服務寫入主資料庫成功，則向從資料庫查詢新資料也成功。
2、商品服務寫入主資料庫失敗，則向從資料庫查詢新資料也失敗。
如何實現一致性？
1、寫入主資料庫後要將資料同步到從資料庫。
2、寫入主資料庫後，在向從資料庫同步期間要將從資料庫鎖定，待同步完成後再釋放鎖，以免在新資料寫入成功 後，向從資料庫查詢到舊的資料。
分散式系統一致性的特點：
1、由於存在資料同步的過程，寫操作的響應會有一定的延遲。
2、為了保證資料一致性會對資源暫時鎖定，待資料同步完成釋放鎖定資源。
3、如果請求資料同步失敗的結點則會返回錯誤資訊，一定不會返回舊資料。
A - Availability ：
可用性是指任何事務操作都可以得到響應結果，且不會出現響應超時或響應錯誤。
上圖中，商品資訊讀取滿足可用性就是要實現如下目標：
1、從資料庫接收到資料查詢的請求則立即能夠響應資料查詢結果。
2、從資料庫不允許出現響應超時或響應錯誤。
如何實現可用性？
1、寫入主資料庫後要將資料同步到從資料庫。
2、由於要保證從資料庫的可用性，不可將從資料庫中的資源進行鎖定。
3、即時資料還沒有同步過來，從資料庫也要返回要查詢的資料，哪怕是舊資料，如果連舊資料也沒有則可以按照 約定返回一個預設資訊，但不能返回錯誤或響應超時。
分散式系統可用性的特點：
1、 所有請求都有響應，且不會出現響應超時或響應錯誤。
P - Partition tolerance ：
通常分散式系統的各各結點部署在不同的子網，這就是網路分割槽，不可避免的會出現由於網路問題而導致結點之間 通訊失敗，此時仍可對外提供服務，這叫分割槽容忍性。
上圖中，商品資訊讀寫滿足分割槽容忍性就是要實現如下目標：
1、主資料庫向從資料庫同步資料失敗不影響讀寫操作。
2、其一個結點掛掉不影響另一個結點對外提供服務。
如何實現分割槽容忍性？
1、儘量使用非同步取代同步操作，例如使用非同步方式將資料從主資料庫同步到從資料，這樣結點之間能有效的實現 鬆耦合。
2、新增從資料庫結點，其中一個從結點掛掉其它從結點提供服務。
分散式分割槽容忍性的特點：
1、分割槽容忍性分是布式系統具備的基本能力。
2.1.2）：CAP組合方式
1、上邊商品管理的例子是否同時具備 CAP呢？
在所有分散式事務場景中不會同時具備CAP三個特性，因為在具備了P的前提下C和A是不能共存的。
比如： 下圖滿足了P即表示實現分割槽容忍：
本圖分割槽容忍的含義是：
1）主資料庫通過網路向從資料同步資料，可以認為主從資料庫部署在不同的分割槽，通過網路進行互動。
2）當主資料庫和從資料庫之間的網路出現問題不影響主資料庫和從資料庫對外提供服務。
3）其一個結點掛掉不影響另一個結點對外提供服務。
如果要實現C則必須保證資料一致性，在資料同步的時候為防止向從資料庫查詢不一致的資料則需要將從資料庫數 據鎖定，待同步完成後解鎖，
如果同步失敗從資料庫要返回錯誤資訊或超時資訊。 如果要實現A則必須保證資料可用性，不管任何時候都可以向從資料查詢資料，則不會響應超時或返回錯誤資訊。
通過分析發現在滿足P的前提下C和A存在矛盾性。
2、CAP有哪些組合方式呢？
所以在生產中對分散式事務處理時要根據需求來確定滿足CAP的哪兩個方面。
1）AP：
放棄一致性，追求分割槽容忍性和可用性。這是很多分散式系統設計時的選擇。
例如： 上邊的商品管理，完全可以實現AP，前提是隻要使用者可以接受所查詢的到資料在一定時間內不是最新的即可。
通常實現AP都會保證最終一致性，後面講的BASE理論就是根據AP來擴充套件的，一些業務場景，
比如：訂單退款，今 日退款成功，明日賬戶到賬，只要使用者可以接受在一定時間內到賬即可。
2）CP：
放棄可用性，追求一致性和分割槽容錯性，我們的zookeeper其實就是追求的強一致，又比如跨行轉賬，一次轉賬請 求要等待雙方銀行系統都完成整個事務才算完成。
3）CA：
放棄分割槽容忍性，即不進行分割槽，不考慮由於網路不通或結點掛掉的問題，則可以實現一致性和可用性。
那麼系統 將不是一個標準的分散式系統，我們最常用的關係型資料就滿足了CA。
上邊的商品管理，如果要實現CA則架構如下：↓ ↓ ↓
主資料庫和從資料庫中間不再進行資料同步，資料庫可以響應每次的查詢請求，通過事務隔離級別實現每個查詢請 求都可以返回最新的資料。
2.1.3 ）：總結
通過上面我們已經學習了CAP理論的相關知識，CAP是一個已經被證實的理論：
一個分散式系統最多隻能同時滿足 一致性（Consistency）、可用性（Availability）和分割槽容忍性（Partition tolerance）這三項中的兩項。
它可以作 為我們進行架構設計、技術選型的考量標準。對於多數大型網際網路應用的場景，結點眾多、部署分散，而且現在的 叢集規模越來越大，所以節點故障、網路故障是常態，而且要保證服務可用性達到N個9（99.99..%），並要達到良 好的響應效能來提高使用者體驗，因此一般都會做出如下選擇：保證P和A，捨棄C強一致，保證最終一致性。
2.2）：BASE 理論
1、理解強一致性和最終一致性
CAP理論告訴我們一個分散式系統最多隻能同時滿足一致性（Consistency）、可用性（Availability）和分割槽容忍 性（Partition tolerance）這三項中的兩項，其中AP在實際應用中較多，AP即捨棄一致性，保證可用性和分割槽容忍 性，但是在實際生產中很多場景都要實現一致性，比如前邊我們舉的例子主資料庫向從資料庫同步資料，即使不要 一致性，但是最終也要將資料同步成功來保證資料一致，這種一致性和CAP中的一致性不同，CAP中的一致性要求 在任何時間查詢每個結點資料都必須一致，它強調的是強一致性，但是最終一致性是允許可以在一段時間內每個結 點的資料不一致，但是經過一段時間每個結點的資料必須一致，它強調的是最終資料的一致性。
2、Base理論介紹
BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮 寫。
BASE理論是對CAP中AP的一個擴充套件，通過犧牲強一致性來獲得可用性，當出現故障允許部分不可用但要保證 核心功能可用，允許資料在一段時間內是不一致的，但最終達到一致狀態。滿足BASE理論的事務，我們稱之為“柔 性事務”。
~ 基本可用:分散式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。如，電商網站交易付款出 現問題了，商品依然可以正常瀏覽。
~ 軟狀態:由於不要求強一致性，所以BASE允許系統中存在中間狀態（也叫軟狀態），這個狀態不影響系統可用 性，如訂單的"支付中"、“資料同步中”等狀態，
待資料最終一致後狀態改為“成功”狀態。
~ 最終一致:最終一致是指經過一段時間後，所有節點資料都將會達到一致。
如訂單的"支付中"狀態，最終會變 為“支付成功”或者"支付失敗"，使訂單狀態與實際交易結果達成一致，但需要一定時間的延遲、等待。
=========================== 華麗分割線 ==========================
（三）分散式事務解決方案之2PC(兩階段提交) ：↓ ↓ ↓
前面已經學習了分散式事務的基礎理論，以理論為基礎，針對不同的分散式場景業界常見的解決方案有2PC、 TCC、可靠訊息最終一致性、最大努力通知這幾種。
3.1）：什麼是2PC
2PC即兩階段提交協議，是將整個事務流程分為兩個階段，準備階段（Prepare phase）、提交階段（commit phase），2是指兩個階段，P是指準備階段，C是指提交階段。
舉例：張三和李四好久不見，老友約起聚餐，飯店老闆要求先買單，才能出票。這時張三和李四分別抱怨近況不如 意，囊中羞澀，都不願意請客，這時只能AA。只有張三和李四都付款，老闆才能出票安排就餐。但由於張三和李四 都是鐵公雞，形成了尷尬的一幕：
· 準備階段：老闆要求張三付款，張三付款。老闆要求李四付款，李四付款。
· 提交階段：老闆出票，兩人拿票紛紛落座就餐。
例子中形成了一個事務，若張三或李四其中一人拒絕付款，或錢不夠，店老闆都不會給出票，並且會把已收款退 回。
整個事務過程由事務管理器和參與者組成，店老闆就是事務管理器，張三、李四就是事務參與者，事務管理器負責 決策整個分散式事務的提交和回滾，事務參與者負責自己本地事務的提交和回滾。
在計算機中部分關聯式資料庫如Oracle、MySQL支援兩階段提交協議，如下圖：↓ ↓ ↓
1. 準備階段（Prepare phase）：事務管理器給每個參與者傳送Prepare訊息，每個資料庫參與者在本地執行事 務，並寫本地的Undo/Redo日誌，此時事務沒有提交。
（Undo日誌是記錄修改前的資料，用於資料庫回滾，Redo日誌是記錄修改後的資料，用於提交事務後寫入數 據檔案）
2. 提交階段（commit phase）：如果事務管理器收到了參與者的執行失敗或者超時訊息時，直接給每個參與者 傳送回滾(Rollback)訊息；
否則，傳送提交(Commit)訊息；參與者根據事務管理器的指令執行提交或者回滾操 作，並釋放事務處理過程中使用的鎖資源。注意:必須在最後階段釋放鎖資源。
下圖展示了2PC的兩個階段，分成功和失敗兩個情況說明： 成功情況：
Face your past without regret. Handle your present with confidence.Prepare for future without fear. keep the faith and drop the fear.
面對過去無怨無悔，把握現在充滿信心，備戰未來無所畏懼。保持信念，克服恐懼！一點一滴的積累，一點一滴的沉澱，學技術需要不斷的積澱！