注：本節内容來自“小白不想上班” https://www.jianshu.com/p/0f50adfc9992
14.1. 基礎概念
14.1.1 什麼是事務
事務可以看作是一次大的活動，它由不同的小活動組成，這些活動要麼全部成功，要麼全部失敗。
14.1.2 本地事務
在計算機系統中，更多的是通過關系型資料庫來控制事務，這是利用資料庫本身的事務特性來實作的，是以叫資料庫事務，由于應用主要靠關系資料庫來控制事務，而資料庫通常和應用在同一個伺服器，是以基于關系型資料庫的事務又被稱為本地事務。
資料庫事務的四大特性：ACID
（1）A（Atomic）原子性：
構成事務的所有操作，要麼都執行完成，要麼全部不執行，不可能出現部分成功部分失敗的情況。
（2）C（Consistency）一緻性：
在事務執行前後，資料庫的一緻性限制沒有被破壞。比如：張三向李四轉 100 元，轉賬前和轉賬後的資料是正确狀态這叫一緻性，如果出現張三轉出 100 元，李四賬戶沒有增加 100 元這就出現了資料錯誤，就沒有達到一緻性。
（3）I（Isolation）隔離性：
資料庫中的事務一般都是并發的，隔離性是指并發的兩個事務的執行互不幹擾，一個事務不能看到其他事務的運作過程的中間狀态。通過配置事務隔離級别可以比避免髒讀、重複讀問題。
（4）D（Durability）持久性：
事務完成之後，該事務對資料的更改會持久到資料庫，且不會被復原。
資料庫事務在實作時會将一次事務的所有操作全部納入到一個不可分割的執行單元，該執行單元的所有操作要麼都成功，要麼都失敗，隻要其中任一操作執行失敗，都将導緻整個事務的復原。
14.1.3 分布式事務
随着網際網路的快速發展，軟體系統由原來的單體應用轉變為分布式應用，下圖描述了單體應用向微服務的演變：
分布式系統會把一個應用系統拆分為可獨立部署的多個服務，是以需要服務與服務之間遠端協作才能完成事務操作，這種分布式系統環境下由不同的服務之間通過網絡遠端協作完成事務稱之為分布式事務，例如使用者注冊送積分事務、建立訂單減庫存事務，銀行轉賬事務等都是分布式事務。
我們知道本地事務依賴資料庫本身提供的事務特性來實作，是以以下邏輯可以控制本地事務：
begin transaction；
//1.本地資料庫操作：張三減少金額
//2.本地資料庫操作：李四增加金額
commit transation;
但是在分布式環境下，會變成下邊這樣：
begin transaction
//1.本地資料庫操作：張三減少金額
//2.遠端調用：讓李四增加金額
commit transation
可以設想，當遠端調用讓李四增加金額成功了，由于網絡問題遠端調用并沒有傳回，此時本地事務送出失敗就復原了張三減少金額的操作，此時張三和李四的資料就不一緻了。
是以在分布式架構的基礎上，傳統資料庫事務就無法使用了，張三和李四的賬戶不在一個資料庫中甚至不在一個應用系統裡，實作轉賬事務需要通過遠端調用，由于網絡問題就會導緻分布式事務問題。
14.1.4 分布式事務産生的情景
1、跨JVM程序産生分布式事務
典型的場景就是微服務架構：微服務之間通過遠端調用完成事務操作。比如：訂單微服務和庫存微服務，下單的同時訂單微服務請求庫存微服務減少庫存。
2、跨資料庫執行個體産生分布式事務
單體系統通路多個資料庫執行個體當單體系統需要通路多個資料庫（執行個體）時就會産生分布式事務。比如：使用者資訊和訂單資訊分别在兩個MySQL執行個體存儲，使用者管理系統删除使用者資訊，需要分别删除使用者資訊及使用者的訂單資訊，由于資料分布在不同的資料執行個體，需要通過不同的資料庫連結去操作資料，此時産生分布式事務。
3、多服務通路同一個資料庫執行個體
訂單微服務和庫存微服務即使通路同一個資料庫也會産生分布式事務，原因就是跨JVM程序，兩個微服務持有了不同的資料庫連結進行資料庫操作，此時産生分布式事務。
14.2. 分布式事務基礎理論
通過前面的學習，我們了解到了分布式事務的基礎概念。與本地事務不同的是，分布式系統之是以叫分布式，是因為提供服務的各個節點分布在不同機器上，互相之間通過網絡互動。不能因為有一點網絡問題就導緻整個系統無法提供服務，網絡因素成為了分布式事務的考量标準之一。是以，分布式事務需要更進一步的理論支援，接下來，我們先來學習一下分布式事務的CAP理論。
14.2.1 CAP理論
14.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）即時資料還沒有同步過來，從資料庫也要傳回要查詢的資料，哪怕是舊資料，如果連舊資料也沒有則可以按照約定傳回一個預設資訊，但不能傳回錯誤或響應逾時。
分布式系統可用性的特點：
所有請求都有響應，且不會出現響應逾時或響應錯誤
P - Partition tolerance：
通常分布式系統的各結點部署在不同的子網，這就是網絡分區，不可避免的會出現由于網絡問題而導緻結點之間通信失敗，此時仍可對外提供服務，這叫分區容忍性。
上圖中，商品資訊讀寫滿足分區容忍性就是要實作如下目标：
（1）主資料庫向從資料庫同步資料失敗不影響讀寫操作。
（2）其中一個結點挂掉不影響另一個結點對外提供服務。
如何實作分區容忍性？
（1）盡量使用異步取代同步操作，例如使用異步方式将資料從主資料庫同步到從資料，這樣結點之間能有效的實作松耦合。
（2）添加從資料庫結點，其中一個從結點挂掉其它從結點提供服務。
分布式分區容忍性的特點：
分區容忍性分是布式系統具備的基本能力
14.2.1.2 CAP組合方式
上邊商品管理的例子是否同時具備 CAP 呢？
在所有分布式事務場景中不會同時具備 CAP 三個特性，因為在具備了P的前提下C和A是不能共存的。
比如，下圖滿足了P即表示實作分區容忍：
本圖分區容忍的含義是：
（1）主資料庫通過網絡向從資料庫同步資料，可以認為主從資料庫部署在不同的分區，通過網絡進行互動。
（2）當主資料庫和從資料庫之間的網絡出現問題不影響主資料庫和從資料庫對外提供服務。
（3）其中一個節點挂掉不影響另一個節點對外提供服務。
如果要實作 C 則必須保證資料一緻性，在資料同步的時候為防止向從資料庫查詢不一緻的資料則需要将從資料庫資料鎖定，待同步完成後解鎖，如果同步失敗從資料庫要傳回錯誤資訊或逾時資訊。
如果要實作 A 則必須保證資料可用性，不管任何時候都可以向從資料查詢資料，則不會響應逾時或傳回錯誤資訊。通過分析發現在滿足P的前提下 C 和 A 存在沖突性。
CAP的組合方式
是以在生産中對分布式事務處理時要根據需求來确定滿足 CAP 的哪兩個方面。
AP（可用性&分區容忍性）：
放棄一緻性，追求分區容忍性和可用性。這是很多分布式系統設計時的選擇。
例如：上邊的商品管理，完全可以實作 AP，前提是隻要使用者可以接受所查詢到的資料在一定時間内不是最新的即可。
通常實作 AP 都會保證最終一緻性，後面将的 BASE 理論就是根據 AP 來擴充的，一些業務場景比如：訂單退款，今日退款成功，明日賬戶到賬，隻要使用者可以接受在一定的時間内到賬即可。
CP（一緻性&分區容忍性）：
放棄可用性，追求一緻性和分區容錯性，Zookeeper 其實就是追求的強一緻，又比如跨行轉賬，一次轉賬請求要等待雙方銀行系統都完成整個事務才算完成。
CA（一緻性&可用性）：
放棄分區容忍性，即不進行分區，不考慮由于網絡不通或結點挂掉的問題，則可以實作一緻性和可用性。那麼系統将不是一個标準的分布式系統，最常用的關系型資料就滿足了 CA。
上邊的商品管理，如果要實作 CA 則架構如下：
主資料庫和從資料庫中間不在進行資料同步，資料庫可以響應每次的查詢請求，通過事務隔離級别實作每個查詢請求都可以傳回最新的資料。
14.2.1.3 總結
CAP 是一個已經被證明的理論，一個分布式系統最多隻能同時滿足：一緻性（Consistency）、可用性（Availability）和分區容忍性（Partition tolerance）這三項中的兩項。它可以作為我們進行架構設計、技術選型的考量标準。對于多數大型網際網路應用的場景，結點衆多、部署分散，而且現在的叢集規模越來越大，是以節點故障、網絡故障是常态，而且要保證服務可用性達到 N 個 9（99.99..%），并要達到良好的響應性能來提高使用者體驗，是以一般都會做出如下選擇：保證 P 和 A ，舍棄 C 強一緻，保證最終一緻性。
14.2.2 BASE 理論
14.2.2.1 強一緻性和最終一緻性
CAP 理論告訴我們一個分布式系統最多隻能同時滿足一緻性（Consistency）、可用性（Availability）和分區容忍性（Partition tolerance）這三項中的兩項，其中AP在實際應用中較多，AP 即舍棄一緻性，保證可用性和分區容忍性，但是在實際生産中很多場景都要實作一緻性，比如前邊我們舉的例子主資料庫向從資料庫同步資料，即使不要一緻性，但是最終也要将資料同步成功來保證資料一緻，這種一緻性和 CAP 中的一緻性不同，CAP 中的一緻性要求在任何時間查詢每個結點資料都必須一緻，它強調的是強一緻性，但是最終一緻性是允許可以在一段時間内每個結點的資料不一緻，但是經過一段時間每個結點的資料必須一緻，它強調的是最終資料的一緻性。
14.2.2.2 Base 理論介紹
BASE 是 Basically Available（基本可用）、Soft state（軟狀态）和 Eventually consistent （最終一緻性）三個短語的縮寫。BASE 理論是對 CAP 中 AP 的一個擴充，通過犧牲強一緻性來獲得可用性，當出現故障允許部分不可用但要保證核心功能可用，允許資料在一段時間内是不一緻的，但最終達到一緻狀态。滿足BASE理論的事務，我們稱之為“柔性事務”。
基本可用：
分布式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。如電商網站交易付款出現問題了，商品依然可以正常浏覽。
軟狀态：
由于不要求強一緻性，是以BASE允許系統中存在中間狀态（也叫軟狀态），這個狀态不影響系統可用性，如訂單的"支付中"、“資料同步中”等狀态，待資料最終一緻後狀态改為“成功”狀态。
最終一緻：
最終一緻是指經過一段時間後，所有節點資料都将會達到一緻。如訂單的"支付中"狀态，最終會變 為“支付成功”或者"支付失敗"，使訂單狀态與實際交易結果達成一緻，但需要一定時間的延遲、等待。