1 基礎概念

1.1. 什么是事務

什么是事務？舉個生活的例子 ：你去小賣部買東西，“一手交錢，一手交貨“就是一個事務的例子，交錢和交貨必須全部成功，事務才算成功，任一個活動失敗，事務將撤銷所有已成功的活動，
明白上述例子，再來看事務的定義 ：
事務可以看做是一次大的活動，它由不同的小活動組成，這些活動要么全部成功，要么全部失敗，

1.2. 本地事務

在計算機系統中，更多的是通過關系型資料庫來控制事務，這里利用資料庫本身的事務特性來實作的，因此叫資料庫事務，由于應用主要靠關系資料庫來控制事務，而資料庫通常和應用在同一個服務器，所以基于關系型資料庫的事務又被稱為本地事務，
回顧一下資料庫事務的四大特性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行程，兩個微服務持有了不同的資料庫鏈接進行資料庫操作，此時產生分布式事務，

2. 分布式事務基礎理論

我們了解到分布式事務的基礎概念，與本地事務不同的是，分布式系統之所以叫分布式，是因為提供服務的各個節點分布在不同的機器上，相互之間通過網路互動，不能因為有一點網路問題就導致整個系統無法提供服務，網路因素成為了分布式事務的考量標準之一，因此分布式事務需要更進一步的理論支持，
在了解分布式事務控制解決方案之前先了解一些基礎理論，通過理論知識指導我們確定分布式事務控制的目標，從而幫助我們理解解決方案，

2.1. CAP理論

2.1.1. 理解CAP

CAP是Consistency、Availability、Parition 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是一個已經被證實的理論 ：一個分布式系統最多只能同時滿足一致性（Consistency）、可用性（Availability）和磁區容忍性（Partition tolerance）這三項中的兩項，它可以作為我們架構設計、技術選型的考量標準，對于多數大型互聯網應用的場景，節點眾多、部署分散，而且現在的集群規模越來越大，所以節點故障、網路故障是常態，而且要保證服務可用性達到N個9（99.99.%），并要達到良好的回應性能來提高用戶體驗，因此一般都會做出如下選擇 ：保證P和A，舍棄C強一致性，保證最終一致性，

2.2. BASE理論

1、理解強一致性和最終一致性
CAP理論告訴我們一個分布式系統最多只能同時滿足一致性（Consistency）、可用性（Availability）和磁區容忍性（Partition tolerance）這三項中的兩項，其中AP在實際應用中較多，AP既舍棄一致性，保證可用性和磁區容忍性，但是在實際生產中很多場景都要實作一致性，比如前邊我們舉的例子，AP即舍棄一致性，保證可用性和磁區容忍性，但是在實際產生中很多場景都要實作一致性，比如前邊我們覺得例子主資料庫向從資料庫同步資料，即使不要一致性，但是最終也要將資料同步成功來保證資料一致，這種一致性和CAP中的一致性不同，CAP中的一致性要求在任何時間查詢每個節點資料都必須一致，它強調的是強一致性，但是最終一致性是允許可以在一段時間內每個節點的資料不一致，但是經過一段時間每個節點的資料必須一致，它強調的是最終資料的一致性，
2、Base理論介紹
BASE是Basically Availbale（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫，BASE理論是對CAP中AP的一個擴展，通過犧牲強一致性來獲得可用性，當出現故障允許部分不可用但要保證核心功能可用，允許資料在一段時間內是不一致的，但最終達到一致狀態，滿足BASE理論的事務，我們稱之為“柔性事務”，

• 基本可用 ：分布式系統在出現故障時，允許損失部分可用功能，保證核心功能可用，如電商網址交易付款出現問題來，商品依然可以正常瀏覽，
• 軟狀態：由于不要求強一致性，所以BASE允許系統中存在中間狀態（也叫軟狀態），這個狀態不影響系統可用性，如訂單中的“支付中”、“資料同步中”等狀態，待資料最終一致后狀態改為“成功”狀態，
• 最終一致性：最終一致是指的經過一段時間后，所有節點資料都將會達到一致，如訂單的“支付中”狀態，最侄訓變為“支付成功”或者“支付失敗”，使訂單狀態與實際交易結果達成一致，但需要一定時間的延遲、等待，

標籤：架構設計

上一篇：重構改善既有代碼

下一篇：Nginx配置實體-負載均衡實體：平均訪問多臺服務器