1 關于分布式系統(tǒng)

1.1 介紹

我們常見的單體結構的集中式系統(tǒng)，一般整個項目就是一個獨立的應用，所有的模塊都聚合在一起。明顯的弊端就是不易擴展、發(fā)布冗重、服務治理不好做。

所以我們把整個系統(tǒng)拆分成若干個具備獨立運行能力的計算服務的集合，而從用戶的角度看，是一個完整的系統(tǒng)，但實際上，它是一個分布式服務的集合。

分布式系統(tǒng)主要從以下幾個方面進行裂變：

• 應用可以從業(yè)務領域拆分成多個module，每個module還可以再按項目結構分成接口層、業(yè)務層、數(shù)據(jù)訪問層；當然也可以按訪問入口進行拆分，如移動、桌面、Web端訪問的是不同的類型接口服務；
• 數(shù)據(jù)庫可以按業(yè)務類型拆分成多個實例，還可以對單庫或單表進行分庫分表；參考我的這篇《Mysql數(shù)據(jù)庫分庫分表全面瓦解》
• 增加一些中間件，來保證分布式系統(tǒng)的高可用，如分布式緩存、搜索服務、文件服務、消息隊列、非關系型數(shù)據(jù)庫等中間件；

1.2 優(yōu)勢和不足

分布式系統(tǒng)可以解決集中式不便擴展的弊端，提供了便捷的擴展性、獨立的服務治理，并提高了安全可靠性。隨著微服務技術（Spring Cloud、Dubbo） 以及容器技術（Kubernetes、Docker）的大熱，分布式技術發(fā)展非常迅速。

不足的地方：分布式系統(tǒng)雖好，也帶來了系統(tǒng)的復雜性，如分布式事務、分布式鎖、分布式session、數(shù)據(jù)一致性等都是現(xiàn)在分布式系統(tǒng)中需要解決的難題，雖然已經有很多成熟的方案，但都不完美。

分布式系統(tǒng)的便利，其實是犧牲了一些開發(fā)、測試、運維 成本的，讓工作量增加了，所以分布式系統(tǒng)管理不好反而會變成一種負擔。

2 分布式事務

分布式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。

分布式場景下一次完整的操作由不同的action組成，這些actions可能分布在不同的服務器上，且屬于不同的應用，分布式事務需要保證這些action要么全部成功，要么全部失敗。保證單個完整操作的原子性。

本質上來說，分布式事務就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

2.1 CAP理論

CAP 定理（也稱為 Brewer 定理），指的是在分布式計算環(huán)境下，有3個核心的需求：

1、一致性（Consistency）：再分布，所有實例節(jié)點同一時間看到是相同的數(shù)據(jù)

2、可用性（Availability）：不管是否成功，確保每一個請求都能接收到響應

3、分區(qū)容錯性（Partition Tolerance）：系統(tǒng)任意分區(qū)后，在網絡故障時，仍能操作

CAP理論告訴我們，分布式系統(tǒng)不可能同時滿足以下三種。最多只能同時滿足其中的兩項，因為很多時候P是必須的, 因此往往選擇就在CP或者AP中

2.2 CAP的組合情況

CA: 放棄分區(qū)容錯性。非分布式架構，比如關系數(shù)據(jù)庫，因為沒有分區(qū)，但是在分布式系統(tǒng)下，CA組合就不建議了。

AP: 放棄強一致性。追求最終一致性，類似的場景比如轉賬，可以接受兩小時后到賬，Eureka的注冊也是類似的做法。 

CP: 放棄可用性。zookeeper在leader宕機后，選舉期間是不提供服務的。類似的場景比如支付完成之后出訂單，必須一進一出都完成才行。 

結論：在分布式系統(tǒng)中AP運用的最多，因為他放棄的是強一致性，追求的是最終一致性，性價比最高

2.3 數(shù)據(jù)一致性模型

分布式系統(tǒng)通過同步數(shù)據(jù)的副本來提高系統(tǒng)的可靠性和容錯性，而且數(shù)據(jù)的不同的副本，合理會存在不同的機器或集群上。

強一致性：當用戶的操作完成之后，會立馬被同步到不同的數(shù)據(jù)副本中，后續(xù)其他任意請求都會獲得更新過的值。這種對用戶的可見性是最友好的，能始終保證讀到正確的值。根據(jù) CAP 理論，這種實現(xiàn)需要犧牲可用性。

弱一致性：系統(tǒng)并不保證所有請求的訪問都會獲得最新值。數(shù)據(jù)寫入成功之后，不承諾立即可以讀，也不承諾具體多久之后可以讀到，甚至讀不到。在請求獲得數(shù)據(jù)更新的這段時間，我i們稱之為“不一致性窗口”。

最終一致性：是弱一致性的一種。系統(tǒng)保證在沒有后續(xù)更新的前提下，系統(tǒng)最終返回上一次更新操作的值。在沒有故障發(fā)生的前提下，不一致窗口的時間主要受通信延遲，系統(tǒng)負載和復制副本的個數(shù)影響。

常見的事務處理機制： 

1、Master-Slave 復制：寫請求由 Master 負責，寫入 Master 后，由 Master 同步到 Slave 上。

異步同步，所以是弱/最終一致性。

2、Master-Master 主主復制

異步同步，最終的一致性，多個節(jié)點間需要序列化協(xié)議。

2.4 分布式事務應用場景

2.4.1 典型支付場景

這是最經典的場景。支付過程，要先對買家賬戶進行扣款，同時對賣家賬戶進行付款，

像這類的操作，必須在一個事務中執(zhí)行，保證原子性，要么都成功，要么都不成功。但是往往買家的支付平臺和賣家的支付平臺不一致，即使都在一個平臺下，所屬的業(yè)務服務和數(shù)據(jù)服務

（歸屬不同表甚至不同庫，比如賣家中心庫、賣家中心庫）也不是同一個。針對于不同的業(yè)務平臺、不同的數(shù)據(jù)庫做操作必然要引入分布式事務。

2.4.2 在線下單

同理，買家在電商平臺下單，往往會涉及到兩個動作，一個是扣庫存，第二個是更新訂單狀態(tài)，庫存和訂單一般屬于不同的數(shù)據(jù)庫，需要使用分布式事務保證數(shù)據(jù)一致性。

2.4.3 跨行轉賬

跨行轉賬問題也是一個典型的分布式事務，用戶A同學向B同學的賬戶轉賬500，要先進行A同學的賬戶-500，然后B同學的賬戶+500，既然是不同的銀行，

涉及不同的業(yè)務平臺，為了保證這兩個操作步驟的一致，分布式事務必然要被引入。

2.5 常見分布式一致性保障（分布式事務解決方案）

2.5.1 XA 兩階段提交協(xié)議

兩階段提交協(xié)議（Two-phase commit protocol），簡稱2PC，過程涉及到協(xié)調者和參與者。

它是一種強一致性設計，引入一個事務協(xié)調者的角色來協(xié)調管理各參與者的提交和回滾，二階段分別指的是準備（投票）和提交兩個階段。

第一階段（準備階段）

為事務協(xié)調者的節(jié)點會首先向所有的參與者節(jié)點發(fā)送Prepare請求。

在接到Prepare請求之后，每一個參與者節(jié)點會各自執(zhí)行與事務有關的數(shù)據(jù)更新，寫入Undo Log（撤銷）和 Redo Log（重做）。

如果參與者執(zhí)行成功，暫時不提交事務，而是向事務協(xié)調節(jié)點返回“完成”消息。當事務協(xié)調者接到了所有參與者的返回消息，整個分布式事務將會進入第二階段。

假如在第一階段有一個參與者返回失敗，那么協(xié)調者就會向所有參與者發(fā)送回滾事務的請求，即分布式事務執(zhí)行失敗。如下圖:

第二階段（提交階段）

如果事務協(xié)調節(jié)點在之前所收到都是正向返回，那么它將會向所有事務參與者發(fā)出Commit請求。

接到Commit請求之后，事務參與者節(jié)點會各自進行本地的事務提交，并釋放鎖資源。當本地事務完成提交后，將會向事務協(xié)調者返回“完成”消息。

當事務協(xié)調者接收到所有事務參與者的“完成”反饋，整個分布式事務完成。

當有一個Commit 不成功，那其他的應該也是提交不成功的。

2.5.2 XA三階段提交

三階段提交：CanCommit 階段、PreCommit 階段、DoCommit 階段，簡稱3PC

三階段提交協(xié)議（Three-phase commit protocol，3PC），是二階段提交（2PC）的改進版本。與兩階段提交不同的是，三階段提交有兩個改動點：

引入超時機制。同時在協(xié)調者和參與者中都引入超時機制。

在第一階段和第二階段中插入一個準備階段。保證了在最后提交階段之前各參與節(jié)點的狀態(tài)是一致的。

即 3PC 把 2PC 的準備階段再次一分為二，這樣三階段提交就有 CanCommit、PreCommit、DoCommit 三個階段。當 CanCommit、PreCommit、DoCommit

的任意一個步驟失敗或者等待超時，執(zhí)行RollBack。

2.5.3 MQ事務

利用消息中間件來異步完成事務的后半部分更新，實現(xiàn)系統(tǒng)的最終一致性。這個方式避免了像XA協(xié)議那樣的性能問題。

下面的圖中，使用MQ完成事務在分布式的另外一個子系統(tǒng)上的操作，保證了動作一致性。

2.5.4 TCC事務

TCC事務是Try、Confirm、Cancel三種指令的縮寫，其邏輯模式類似于XA兩階段提交，但是實現(xiàn)方式是在代碼層面人為實現(xiàn)。2PC 和 3PC 都是數(shù)據(jù)庫層面的，而 TCC 是業(yè)務層面的分布式事務。

分布式事務除了上面提到的數(shù)據(jù)庫層面的操作外，還包括發(fā)送短信、郵件這種業(yè)務操作等，這時候 TCC 就有用武之地了！

圖中就是一個典型的分布式系統(tǒng)的原子性操作，涉及A、B、C三個服務的執(zhí)行。如果有一個服務 try 出問題，整個事務管理器就執(zhí)行calcel，如果三個try都成功，才執(zhí)行confirm做正式提交。

2.5.5 最終補償機制，同于MQ事務

最后使用補償機制做最后的一致性保障，MQ方案盡量使用補償機制進行保障。

以上就是分布式事務CAP兩階段提交及三階段提交詳解的詳細內容，更多關于分布式事務CAP及兩階三階段提交的資料請關注腳本之家其它相關文章！

最新評論