1-1 什麼是分佈式事務
隨着互聯網的快速發展，軟件系統由原來的單體應用轉變爲分佈式應用，下圖描述了單體應用向微服務的演變：
分佈式系統會把一個應用系統拆分爲可獨立部署的多個服務，因此需要服務與服務之間遠程協作才能完成事務操作，這種分佈式系統環境下由不同的服務之間通過網絡遠程協作完成事務稱之爲分佈式事務，例如用戶註冊送積分事務、創建訂單減庫存事務，銀行轉賬事務等都是分佈式事務。
我們知道本地事務依賴數據庫本身提供的事務特性來實現，因此以下邏輯可以控制本地事務：
begin transaction；
//1.本地數據庫操作：張三減少金額
//2.本地數據庫操作：李四增加金額
commit transation;
但是在分佈式環境下，會變成下邊這樣：
begin transaction；
//1.本地數據庫操作：張三減少金額
//2.遠程調用：讓李四增加金額
commit transation;
可以設想，當遠程調用讓李四增加金額成功了，由於網絡問題遠程調用並沒有返回，此時本地事務提交失敗就回滾了張三減少金額的操作，此時張三和李四的數據就不一致了。
因此在分佈式架構的基礎上，傳統數據庫事務就無法使用了，張三和李四的賬戶不在一個數據庫中甚至不在一個應用系統裏，實現轉賬事務需要通過遠程調用，由於網絡問題就會導致分佈式事務問題。
1-2 分佈式事務產生的場景
1、典型的場景就是微服務架構微服務之間通過遠程調用完成事務操作。 比如：訂單微服務和庫存微服務，下單的同時訂單微服務請求庫存微服務減庫存。 簡言之：跨JVM進程產生分佈式事務。
2、單體系統訪問多個數據庫實例當單體系統需要訪問多個數據庫（實例）時就會產生分佈式事務。 比如：用戶信息和訂單信息分別在兩個MySQL實例存儲，用戶管理系統刪除用戶信息，需要分別刪除用戶信息及用戶的訂單信息，由於數據分佈在不同的數據實例，需要通過不同的數據庫鏈接去操作數據，此時產生分佈式事務。 簡言之：跨數據庫實例產生分佈式事務。
3、多服務訪問同一個數據庫實例 比如：訂單微服務和庫存微服務即使訪問同一個數據庫也會產生分佈式事務，原因就是跨JVM進程，兩個微服務持有了不同的數據庫鏈接進行數據庫操作，此時產生分佈式事務。
1-3 分佈式事務基礎理論CAP
分佈式系統之所以叫分佈式，是因爲提供服務的各個節點分佈在不同機器上，相互之間通過網絡交互。不能因爲有一點網絡問題就導致整個系統無法提供服務，網絡因素成爲了分佈式事務的考量標準之一。因此，分佈式事務需要更進一步的理論支持，接下來，我們先來學習一下分佈式事務的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、分區容忍性分是布式系統具備的基本能力。
1-4 CAP組合方式
在所有分佈式事務場景中不會同時具備CAP三個特性，因爲在具備了P的前提下C和A是不能共存的。
1）AP：
放棄一致性，追求分區容忍性和可用性。這是很多分佈式系統設計時的選擇, 我們的Eruka其實就是追求的高可用。
2）CP：
放棄可用性，追求一致性和分區容錯性，我們的zookeeper其實就是追求的強一致，又比如跨行轉賬，一次轉賬請求要等待雙方銀行系統都完成整個事務纔算完成。
3）CA：
放棄分區容忍性，即不進行分區，不考慮由於網絡不通或結點掛掉的問題，則可以實現一致性和可用性。那麼系統將不是一個標準的分佈式系統，我們最常用的關係型數據就滿足了CA。
1-1 什麼是分佈式事務
隨着互聯網的快速發展，軟件系統由原來的單體應用轉變爲分佈式應用，下圖描述了單體應用向微服務的演變：
分佈式系統會把一個應用系統拆分爲可獨立部署的多個服務，因此需要服務與服務之間遠程協作才能完成事務操作，這種分佈式系統環境下由不同的服務之間通過網絡遠程協作完成事務稱之爲分佈式事務，例如用戶註冊送積分事務、創建訂單減庫存事務，銀行轉賬事務等都是分佈式事務。
我們知道本地事務依賴數據庫本身提供的事務特性來實現，因此以下邏輯可以控制本地事務：
begin transaction；
//1.本地數據庫操作：張三減少金額
//2.本地數據庫操作：李四增加金額
commit transation;
但是在分佈式環境下，會變成下邊這樣：
begin transaction；
//1.本地數據庫操作：張三減少金額
//2.遠程調用：讓李四增加金額
commit transation;
可以設想，當遠程調用讓李四增加金額成功了，由於網絡問題遠程調用並沒有返回，此時本地事務提交失敗就回滾了張三減少金額的操作，此時張三和李四的數據就不一致了。
因此在分佈式架構的基礎上，傳統數據庫事務就無法使用了，張三和李四的賬戶不在一個數據庫中甚至不在一個應用系統裏，實現轉賬事務需要通過遠程調用，由於網絡問題就會導致分佈式事務問題。
1-2 分佈式事務產生的場景
1、典型的場景就是微服務架構微服務之間通過遠程調用完成事務操作。 比如：訂單微服務和庫存微服務，下單的同時訂單微服務請求庫存微服務減庫存。 簡言之：跨JVM進程產生分佈式事務。
2、單體系統訪問多個數據庫實例當單體系統需要訪問多個數據庫（實例）時就會產生分佈式事務。 比如：用戶信息和訂單信息分別在兩個MySQL實例存儲，用戶管理系統刪除用戶信息，需要分別刪除用戶信息及用戶的訂單信息，由於數據分佈在不同的數據實例，需要通過不同的數據庫鏈接去操作數據，此時產生分佈式事務。 簡言之：跨數據庫實例產生分佈式事務。
3、多服務訪問同一個數據庫實例 比如：訂單微服務和庫存微服務即使訪問同一個數據庫也會產生分佈式事務，原因就是跨JVM進程，兩個微服務持有了不同的數據庫鏈接進行數據庫操作，此時產生分佈式事務。
1-3 分佈式事務基礎理論CAP
分佈式系統之所以叫分佈式，是因爲提供服務的各個節點分佈在不同機器上，相互之間通過網絡交互。不能因爲有一點網絡問題就導致整個系統無法提供服務，網絡因素成爲了分佈式事務的考量標準之一。因此，分佈式事務需要更進一步的理論支持，接下來，我們先來學習一下分佈式事務的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、分區容忍性分是布式系統具備的基本能力。
1-4 CAP組合方式
在所有分佈式事務場景中不會同時具備CAP三個特性，因爲在具備了P的前提下C和A是不能共存的。
1）AP：
放棄一致性，追求分區容忍性和可用性。這是很多分佈式系統設計時的選擇, 我們的Eruka其實就是追求的高可用。
2）CP：
放棄可用性，追求一致性和分區容錯性，我們的zookeeper其實就是追求的強一致，又比如跨行轉賬，一次轉賬請求要等待雙方銀行系統都完成整個事務纔算完成。
3）CA：
放棄分區容忍性，即不進行分區，不考慮由於網絡不通或結點掛掉的問題，則可以實現一致性和可用性。那麼系統將不是一個標準的分佈式系統，我們最常用的關係型數據就滿足了CA。