（一）基礎概念：↓ ↓ ↓
什么是事務？舉個生活中的例子：你去小賣鋪買東西，“一手交錢，一手交貨”就是一個事務的例子，交錢和交貨必 須全部成功，
事務才算成功，任一個活動失敗，事務將撤銷所有已成功的活動。
明白上述例子，再來看事務的定義：
在計算機系統中，更多的是通過關系型數據庫來控制事務，這是利用數據庫本身的事務特性來實現的，因此叫數據 庫事務，由於應用主要靠關系數據庫來控制事務，
而數據庫通常和應用在同一個服務器，所以基於關系型數據庫的 事務又被稱為本地事務。
回顧一下數據庫事務的四大特性 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.
面對過去無怨無悔，把握現在充滿信心，備戰未來無所畏懼。保持信念，克服恐懼！一點一滴的積累，一點一滴的沉淀，學技術需要不斷的積淀！