分布式事務(wù)

• 事務(wù)的概念，我們第一想到的應(yīng)該是數(shù)據(jù)庫的事務(wù)。所謂數(shù)據(jù)庫事務(wù)就是只作為單個邏輯工作單元執(zhí)行多個數(shù)據(jù)庫操作的時候，數(shù)據(jù)庫需要保證要么都成功，要么都失敗，它必須滿足ACID特性，即：

  • 原子性（Atomicity）：事務(wù)必須是原子工作單元，不可繼續(xù)分割，要么全部成功，要么全部是吧
  • 一致性（Consistency）：事務(wù)完成時候，所有數(shù)據(jù)都必須保持一致
  • 隔離性（Isolation）：由并發(fā)事務(wù)所做的修改必須與任何其他并發(fā)事務(wù)所做的修改隔離
  • 持久性（Durability）：事務(wù)執(zhí)行完成后，他對于系統(tǒng)的影響必須是永久代

• 上面幾點是針對單個數(shù)據(jù)庫需要滿足的特性。在微服務(wù)架構(gòu)下，隨著業(yè)務(wù)服務(wù)的拆分以及數(shù)據(jù)庫的拆分，會存在以下這種場景，訂單表與庫存是在兩個微服務(wù)下獨(dú)立的數(shù)據(jù)庫，當(dāng)客戶端發(fā)起一個訂單的時候，需要在的那個的服務(wù)對數(shù)據(jù)庫進(jìn)行創(chuàng)建訂單，同時庫存也需要修改，這兩個修改都是通過RPC通信調(diào)用。如下圖：

• 在以上場景中，原本單庫的操作變成多個數(shù)據(jù)庫結(jié)合的事務(wù)操作，由于每個數(shù)據(jù)庫事務(wù)執(zhí)行情況只有本數(shù)據(jù)庫知道，這樣會導(dǎo)致訂單庫存數(shù)據(jù)與訂單數(shù)據(jù)不一致的問題，比如創(chuàng)建訂單成功但是扣減庫存失敗，會導(dǎo)致超賣商品的問題，這就是所謂的分布式事務(wù)問題 。

分布式事務(wù)理論模型

• 分布式事務(wù)問題也就是保證分布式數(shù)據(jù)庫數(shù)據(jù)一致性問題，簡單說我們應(yīng)該如何在分布式的場景下保證多個節(jié)點的數(shù)據(jù)一致性。分布式事務(wù)產(chǎn)生的核心原因在于存儲資源的分布性，比如我們微服務(wù)情況下的分庫分表，或者多存儲媒介mySql，Redis等數(shù)據(jù)庫的數(shù)據(jù)一致性，實際應(yīng)用中，但是應(yīng)該盡可能從設(shè)計層面避免分布式事務(wù)問題，因為任何一種解決方案都會增加系統(tǒng)復(fù)雜性。

X/Open分布式事務(wù)模型

• X/Open DTP（X/Open Distributed Transaction Processing Reference Model）是X/Open這個組織定義的一套分布式事務(wù)的標(biāo)準(zhǔn)。這個標(biāo)準(zhǔn)提出了使用兩階段提交（2PC，Two-Phase-Commit）來保證分布式事務(wù)的完整性。如下圖X/Open包含如下幾個角色：
  • AP：application 表應(yīng)用程序
  • RM：Resource Manager 資源管理器，比如數(shù)據(jù)庫
  • TM：Transaction Manager 表示事務(wù)管理器，一般指事務(wù)協(xié)調(diào)者，負(fù)責(zé)協(xié)調(diào)和管理事務(wù)，提供AP編程接口或管理RM，可以理解為Spring中提供的Transaction Manager。

• 如上的角色與關(guān)系與本地事務(wù)的原理基本一樣，唯一的不同在于，如果RM代表數(shù)據(jù)庫，那么TM需要能夠管理多個數(shù)據(jù)庫的事務(wù)，如下：

  • 配置TM，將多個RM注冊到TM上，相當(dāng)于TM注冊RM作為數(shù)據(jù)源。
  • AP從TM管理的RM中獲取連接，如果RM是數(shù)據(jù)庫則獲取JDBC連接
  • AP向TM發(fā)起一個全局事務(wù)，生成全局事務(wù)ID（XID），XID會通知各個RM
  • AP通過第二步獲得的連接直接操作RM完成數(shù)據(jù)庫操作。這時候，AP的每次操作會吧XID傳遞給RM
  • AP結(jié)束全局事務(wù)，TM會通知各個RM全局事務(wù)結(jié)束
  • 根據(jù)各個RM的事務(wù)執(zhí)行結(jié)果，執(zhí)行提交或者回滾操作。

• 我們用如下流程圖來解釋，實際上這里涉及全局事務(wù)概念。也就是說在原本單機(jī)事務(wù)下，會存在跨數(shù)據(jù)庫事務(wù)的可見性問題，導(dǎo)致無法實現(xiàn)多借點事務(wù)的全局可控。而TM就是一個全局事務(wù)管理器，他可以管理多個資源管理器的事務(wù)。TM最終會根據(jù)各個分支事務(wù)的執(zhí)行結(jié)果進(jìn)行提交或者回滾。

• 如上圖所示，我們需要注意的是，TM和多個RM之間的事務(wù)控制，是基于XA協(xié)議（XA Speification）來完成的，XA協(xié)議是X/Open踢出的分布式事務(wù)處理規(guī)范，也是分布式事務(wù)處理的工業(yè)標(biāo)準(zhǔn)，定義了xa_ 和 ax_系列的函數(shù)原型以及功能描述，約束等。現(xiàn)在的主流數(shù)據(jù)庫Oracle，MySql，DB2都實現(xiàn)了XA接口，所以他們都可以作為RM。

兩階段提交協(xié)議

• 我們上面實現(xiàn)中RM實現(xiàn)了多個RM的事務(wù)管理，實際上會涉及到兩個階段的提交，第一節(jié)點，事務(wù)的準(zhǔn)備階段，第二階段是事務(wù)的提交或者回滾階段。這兩個階段都是由事務(wù)管理器發(fā)起的。兩個階段提交協(xié)議的流程如下。
  • 準(zhǔn)備階段：事務(wù)管理器（TM）通知資源管理器（RM）準(zhǔn)備分支事務(wù)，記錄事務(wù)日志，并告知事務(wù)管理器的準(zhǔn)備結(jié)果。
  • 提交/回滾階段：如果所有資源管理器（RM）在準(zhǔn)備階段都明確返回成功，則事務(wù)管理器（TM）向所有資源管理器（RM）發(fā)起事務(wù)提交指令完成數(shù)據(jù)變更。反之，如果任何一個資源管理器（RM）明確返回失敗，則事務(wù)管理器（TM）會向所有資源管理器（RM）發(fā)送事務(wù)回滾指令。完整的執(zhí)行流程如下圖。

• 兩階段提交將一個事務(wù)的處理過程分離兩個過程，優(yōu)點在于充分考慮到分布式系統(tǒng)的不可靠因素，并且采用非常簡單的方式（兩階段提交）就把由于系統(tǒng)不可靠而導(dǎo)致的事務(wù)提交失敗的概率降低到最小。當(dāng)然也并不是完美，有如下缺陷：
  • 同步阻塞：從上圖流程，所有參與者RM都必須是事務(wù)阻斷類型的，對應(yīng)任何一次指令都必須有明確的響應(yīng)才可以進(jìn)行下一步，期間其他的請求都會被阻塞，占用的資源會被鎖定。
  • 過于保守：任何節(jié)點失敗都會導(dǎo)致數(shù)據(jù)回滾。
  • 事務(wù)協(xié)調(diào)者的單點故障：如果協(xié)調(diào)者在第二階段出現(xiàn)故障，那么其他的參與者RM，會一直處于鎖定狀態(tài)。
  • 腦裂，導(dǎo)致數(shù)據(jù)不一致問題：在第二階段中，事務(wù)協(xié)調(diào)者向所有參與者RM發(fā)送commit請求后，發(fā)送局部網(wǎng)絡(luò)異常導(dǎo)致只有一部分參與者RM接受到了commit請求，這部分參與者會發(fā)起commit，但是沒有收到commit請求的節(jié)點由于事務(wù)無法提交，導(dǎo)致數(shù)據(jù)出現(xiàn)不一致問題。

三階段提交

• 三階段提交協(xié)議是兩階段提交協(xié)議的改進(jìn)版本，他利用超時機(jī)制解決了同步阻塞問題。三階段提交協(xié)議的具體描述如下。
  • CanCommit（詢問階段）：事務(wù)協(xié)調(diào)者向參與者發(fā)送事務(wù)執(zhí)行請求，詢問是否可以完成指令，參與者只需要回答是或者否，不需要真正做事務(wù)的操作，這個階段會有超時終止機(jī)制。
  • PreCommit（準(zhǔn)備階段）：事務(wù)協(xié)調(diào)者根據(jù)參與者的反饋結(jié)果決定是否繼續(xù)執(zhí)行，如果在詢問階段所有參與者都放回可以執(zhí)行操作，則事務(wù)協(xié)調(diào)者會向所有參與者發(fā)送PreCommit請求，參與者收到請求后寫redo和undo日志，執(zhí)行事務(wù)操作，但是不提交事務(wù)，然后返回ACK響應(yīng)等待事務(wù)協(xié)調(diào)者下一步通知，如果在詢問階段任意參與者返回不能執(zhí)行操作的結(jié)果，那么事務(wù)協(xié)調(diào)者會向所有參與者發(fā)送事務(wù)中斷請求。
  • DoCommit（提交或回滾階段）：這個階段也會存在兩種結(jié)果，任然根據(jù)上一步的執(zhí)行結(jié)果來決定DoCommit執(zhí)行方式。如果每個參與者在PreCommit都返回成功，那么事務(wù)協(xié)調(diào)者會向所有參與者發(fā)起事務(wù)提交指令，反正，如果參與者中任意參與者返回失敗，那么事務(wù)協(xié)調(diào)者會發(fā)起終止指令來回滾事務(wù)。
• 用如下圖說明：

• 三階段提交與兩階段提交不同點：
  • 增加了一個CanCommit階段，用于詢問所有參與者是否可以執(zhí)行事務(wù)操作并響應(yīng)，他的好處是，可以盡早發(fā)現(xiàn)無法執(zhí)行操作而中止后續(xù)的行為。
  • 在準(zhǔn)備階段后，事務(wù)協(xié)調(diào)者和參與者都引入超時機(jī)制，一旦超時，事務(wù)協(xié)調(diào)者和參與者都會繼續(xù)提交事務(wù)，并且認(rèn)為處于成功狀態(tài)，因為這種情況下事務(wù)默認(rèn)為成功的可能性較大。
• 實際上一旦超時，在三階段提交協(xié)議下仍然可能出現(xiàn)數(shù)據(jù)不一致的情況，當(dāng)然概率比較小的。另外，比兩階段提交好的地方是基于超時機(jī)制來避免資源永久鎖定。

CAP理論和BASE理論

• 前面提到的兩階段提交和三階段提交是XA協(xié)議解決分布式數(shù)據(jù)一致性問題的基本原理，但是這這兩種方案為了保證數(shù)據(jù)的強(qiáng)一致性，降低了可用性，因為需要多數(shù)據(jù)庫進(jìn)行加鎖，期間其他事務(wù)需要等待，也就是其他請求會被阻塞。實際上這里涉及分布式事務(wù)的兩個理論模型。

CAP定理

• CAP理論，又叫布爾理論，簡單說他是指在分布式系統(tǒng)中不可能同時滿足一致性（C：Consistency），可用性（A:Availability），分區(qū)容錯性（P：Parition Tolerance）這三個基本需求，做多滿足兩個。

  • C：數(shù)據(jù)在多個副本中要保持強(qiáng)一致性，比如簽名說的分布式數(shù)據(jù)一致性問題
  • A：系統(tǒng)對外提供的服務(wù)必須一致處于可用狀態(tài)，在任何故障下，客戶端都可能在合理的時間內(nèi)獲得服務(wù)端的非錯誤響應(yīng)。
  • P：在分布式系統(tǒng)中遇到任何網(wǎng)絡(luò)分區(qū)故障，系統(tǒng)仍然能夠?qū)ν馓峁┓?wù)。

• 網(wǎng)絡(luò)分區(qū)概念：不同節(jié)點分布在不同子網(wǎng)絡(luò)中時候，在內(nèi)部網(wǎng)絡(luò)正常的情況下，由于某些原因?qū)е逻@些子節(jié)點之間出現(xiàn)網(wǎng)絡(luò)不同的情況，導(dǎo)致整個系統(tǒng)切分成若干獨(dú)立的區(qū)域，這就是網(wǎng)絡(luò)分區(qū)。

• CAP定理證明，在分布式系統(tǒng)中，要么滿足CP，要么滿足AP，不可能CAP，或者CA。

  • 原因在于網(wǎng)絡(luò)通信不是絕對可靠，比如網(wǎng)絡(luò)延遲，網(wǎng)絡(luò)異常都會導(dǎo)致系統(tǒng)故障。而分布式系統(tǒng)技術(shù)出現(xiàn)網(wǎng)絡(luò)故障也需要保證系統(tǒng)仍然能夠正常多外服務(wù)，所以在分布式系統(tǒng)中，Parition Tolerance（分區(qū)容錯）是必然的，也就是需要滿足分區(qū)容錯性，就沒有強(qiáng)一致性了。
  • 如果是CA或者CAP這種情況，相當(dāng)于網(wǎng)絡(luò)100%可靠，否則出現(xiàn)網(wǎng)絡(luò)分區(qū)情況時候，為保證數(shù)據(jù)一致性，必須拒絕客戶請求，但是如果拒絕客戶請求，就不滿足A，所以，分布式系統(tǒng)更不可能選擇CA，因此，只有AP或者CP兩種。
  • AP：放棄強(qiáng)一致性，實現(xiàn)最終一致性，很多互聯(lián)網(wǎng)公司解決分布式數(shù)據(jù)一致性問題的主要選擇
  • CP，放棄高可用，實現(xiàn)強(qiáng)一致性，簽名提到的兩階段提交，三階段提交，可能導(dǎo)致的問題是用戶完成一個操作會等待較長時間。

Base理論

• Base理論是有CAp中一致性和可用性不可兼得衍生出來的一種新思想。

• Base理論核心思想是通過犧牲數(shù)據(jù)強(qiáng)一致性獲得高可用。他有如下三個特性

  • Basically Availiable（基本可用）：分布式系統(tǒng)出現(xiàn)故障，允許損失一部分可用性保證核心功能
  • Soft State（軟狀態(tài)）：允許系統(tǒng)中數(shù)據(jù)存在中間狀態(tài)。這個狀態(tài)不影響系統(tǒng)可用性，也就是允許系統(tǒng)中不同階段數(shù)據(jù)副本之間同步存在延遲
  • Eventually Consistent（最終一致性）：中介狀態(tài)的數(shù)據(jù)進(jìn)過一段時間后，會達(dá)到一個最終的數(shù)據(jù)一致性。

• Base理論并沒有要求數(shù)據(jù)強(qiáng)一致性，而是允許數(shù)據(jù)在一段時間內(nèi)不一致，但是數(shù)據(jù)最終會在某個點實現(xiàn)一致，互聯(lián)網(wǎng)產(chǎn)品中可用性相對來說重要一點，數(shù)據(jù)都是可以補(bǔ)充的，不會錯就行。

• 案例：在支付流程中，用戶發(fā)起一個訂單支付，不需要同步等待執(zhí)行結(jié)果，系統(tǒng)會返回一個支付處理中的中間狀態(tài)，對于用戶來說，可以從訂單列表中看到支付的處理結(jié)果。而對系統(tǒng)來說，第三方支付處理成功，在回調(diào)我們系統(tǒng)修改訂單狀態(tài)即可。這個場景中，雖然訂單的支付狀態(tài)與第三方支付狀態(tài)不一致，當(dāng)體驗更好。

上一篇：SpringCloud Alibaba 框架下公司架構(gòu)圖
下一篇：分布式事務(wù)解決方案

總結(jié)

以上是生活随笔為你收集整理的分布式事务理论模型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。