微服務(wù)·數(shù)據(jù)一致-事務(wù)與分布式事務(wù)

概述

事務(wù)是計算機科學和數(shù)據(jù)庫管理中的一個關(guān)鍵概念，用于確保數(shù)據(jù)的一致性和可靠想。事務(wù)管理是大多數(shù)應用程序和數(shù)據(jù)庫系統(tǒng)中不可或缺的一部分。分布式事務(wù)擴展了事務(wù)的概念，用于多個分布式系統(tǒng)和服務(wù)的數(shù)據(jù)一致性管理。本調(diào)查報告將深入探討事務(wù)和分布式事務(wù)的概念、特性、類型和應用，以及事務(wù)處理的最佳時間

事務(wù)

什么事事務(wù)

事務(wù)是一組數(shù)據(jù)庫操作的邏輯單元，要么全部成功執(zhí)行，要么全部失敗回滾，以保證數(shù)據(jù)的一致性和完整性。事務(wù)遵循ACID屬性，即原子性（Atomicity）、一致性（Consistency）隔離性（Isolation）和持久性（Durability）。

ACID屬性

• 原子性（Atomicity）：事務(wù)中的所有操作要么全部成功，要么全部失敗。如果發(fā)生故障或異常，事務(wù)應該會滾到起始狀態(tài)。
• 一致性（Consistency）：事務(wù)將數(shù)據(jù)從一個一致狀態(tài)轉(zhuǎn)移到另一個一致狀態(tài)。在事務(wù)結(jié)束后，所有約束和規(guī)則都應得到滿足
• 隔離性（Isolation）：事務(wù)應該在隔離的環(huán)境中執(zhí)行，即使多個事務(wù)并發(fā)執(zhí)行，也不相互干擾。數(shù)據(jù)庫管理系統(tǒng)提供不同級別的隔離度。
• 持久性（Durability）：一旦事務(wù)提交，其結(jié)果應該用具保存在數(shù)據(jù)庫中，技術(shù)發(fā)生故障也不會丟失

如何保證原子性

innodb利用undo log實現(xiàn)原子性。undo log名為回滾日志，是實現(xiàn)原子性的關(guān)鍵，當事務(wù)回滾是能夠撤銷雖有已經(jīng)執(zhí)行成功的sql語句，它需要記錄你要回滾的相應的日志信息。比如：delete一個數(shù)據(jù)的時候，就需要記錄這條數(shù)據(jù)的信息，回滾的時候insert這條舊數(shù)據(jù)。當事務(wù)執(zhí)行功能失敗或調(diào)用rallback，導致事務(wù)需要回滾，便可以利用undo log中的信息將數(shù)據(jù)回滾到修改之前的樣子。

如何保證持久性

在修改數(shù)據(jù)的時候，Mysql先把磁盤上的數(shù)據(jù)加載到內(nèi)存中，在內(nèi)存中對數(shù)據(jù)修改，再刷到磁盤中。如果在刷盤前宕機，內(nèi)存中的數(shù)據(jù)就會丟失。

• 解決思路：事務(wù)提交前直接把數(shù)據(jù)寫入磁盤中。
  引入問題：性能損耗嚴重，只修改一個頁（16k）里面的一個字節(jié)，就需要把整個頁面刷入磁盤。另外一個事務(wù)的SQL可能涉及到多個數(shù)據(jù)頁的修改，存在隨機IO的可能，速度會更慢。
• 解決思路：使用redo log
  修改數(shù)據(jù)的時候，不僅內(nèi)存中操作，還會在redo log中記錄這次操作，當事務(wù)提交的時候會將redo log日志進行刷盤。當數(shù)據(jù)庫宕機重啟的時候，會將redo log中的內(nèi)容恢復到數(shù)據(jù)庫中，再根據(jù)undo log和binlog內(nèi)容決定回滾數(shù)據(jù)還是提交數(shù)據(jù)。

一條數(shù)據(jù)的更新流程

事務(wù)并發(fā)帶來的問題及隔離級別

當事務(wù)并發(fā)的時候會帶來一下問題：

• 臟讀：一個事務(wù)訪問到另一個事務(wù)未提交的數(shù)據(jù)。
• 不可重復讀：一個事務(wù)多次讀取同一個數(shù)據(jù)的過程中，數(shù)值發(fā)生變化。
• 幻讀：一個事務(wù)多次讀取同一個數(shù)據(jù)的過程中, 全局數(shù)據(jù)(表的結(jié)構(gòu))發(fā)生了改變。

為了解決并發(fā)事務(wù)帶來的問題，提供了事務(wù)的隔離級別：

• 讀未提交：允許讀取未提交的內(nèi)容，這種級別下查詢不會加鎖，存在臟讀、幻讀、不可重復的問題。
• 讀已提交：只允許讀取已提交的內(nèi)容，但是仍然會存在幻讀、不可重復度的問題。
• 可重復讀：用行級鎖來保證一個事務(wù)在相同查詢條件下兩次查詢結(jié)果一致 , 可以避免臟讀, 不可重復讀, 但無法避免幻讀。（Innodb解決了幻讀問題）
• 串行化：用表級鎖來保證所有事務(wù)串行化, 可以防止所有的異常情況, 但犧牲了數(shù)據(jù)庫的并發(fā)性。

事務(wù)隔離級別實現(xiàn)的原理

• 讀未提交：
  • 事務(wù)對當前讀的數(shù)據(jù)不加鎖，都是當前讀。
  • 事務(wù)在更新數(shù)據(jù)的瞬間，必須先對其加行級共享鎖，直到事務(wù)結(jié)束才釋放。
• 讀已提交：
  • 事務(wù)對當前讀的數(shù)據(jù)不加鎖，是快照讀。
  • 事務(wù)在更新數(shù)據(jù)的瞬間，必須先對其加行級排他鎖（record）直到事務(wù)結(jié)束才釋放。
• 可重復讀：
  • 事務(wù)對當前讀的數(shù)據(jù)不加鎖，且是快照讀。
  • 事務(wù)在更新數(shù)據(jù)的瞬間，必須對其加行級排他鎖（record、gap、nest-key），直到事務(wù)結(jié)束才釋放
• 串行化：
  • 事務(wù)在讀數(shù)據(jù)時，必須先對其加表級共享鎖，直到數(shù)據(jù)結(jié)束才釋放，都是當前讀。
  • 事務(wù)在更新數(shù)據(jù)是，必須先對其加表級排他鎖，直到事務(wù)結(jié)束才釋放。

Spring中的事務(wù)管理

事務(wù)的傳播行為

• PROPAGATION_REQUIRED：默認的事務(wù)事務(wù)傳播行為，如果存在當前事務(wù)，則加入當前事務(wù)，如果不存在，則創(chuàng)建一個新的。
  • 如果外部方法沒有開啟事務(wù)，PROPAGATION_REQUIRED修飾的內(nèi)部方法會開啟自己的事務(wù)，且開啟的事務(wù)相互獨立，互不干擾。
  • 如果外部方法開啟了事務(wù)，且是PROPAGATION_REQUIRED，則外部和內(nèi)部方法屬于一個事務(wù)，只要一個方法回滾，整個事務(wù)都需要回滾，即A（外部方法）影響B(tài)（內(nèi)部方法），B影響A。
• PROPAGATION_REQUIRED_NEW：創(chuàng)建一個新的事務(wù)，如果當前存在事務(wù)，則把當前事務(wù)掛起。
  • 不管外部方法是否開啟事務(wù)，PROPAGATION_REQUIRED_NEW修飾的方法都會開啟自己的事務(wù)。外部方法的事務(wù)與內(nèi)部方法的事務(wù)相互獨立，互不干擾。即A不影響B(tài)，B不影響A。
• PROPAGATION_SUPPORTS：如果當前存在事務(wù)，則加入該事務(wù)，否則以非事務(wù)方式運行。
• PROPAGATION_NOT_SUPPORTS：以非事務(wù)方式運行，如果當前存在事務(wù)，則把當前事務(wù)掛起。
• PROPAGATION_MANDATORY：如果當前存在事務(wù)，則加入該事務(wù)；如果當前沒有事務(wù)，則拋出異常。
• PROPAGATION_NEVER：以非事務(wù)方式運行，如果當前存在事務(wù)，則拋出異常。
• PROPAGATION_NESTED：如果當前存在事務(wù)，就在當前事務(wù)內(nèi)執(zhí)行。否則就執(zhí)行與PROPAGATION_REQUIRED類似的操作
  • A影響B(tài)，B不影響A。

事務(wù)失效的幾種情況

• 拋出事務(wù)不支持的異常
  Spring事務(wù)默認支持RuntimeException，如果拋出的異常為RuntimeException及其子類異常，事務(wù)均可生效。如果是拋出的Exception異常，則失效。解決方案：指定Spring事務(wù)異常捕獲類型@Transactional(rollbackFor = Exception.class)或拋出spring事務(wù)支持的異常類型。
• 使用了try-catch
  異常被try-catch捕獲，導致事務(wù)失效。解決方案：在catch中拋出Spring事務(wù)支持的異常。
• 事務(wù)方法為私有方法
  Spring聲明式事務(wù)是基于動態(tài)代理實現(xiàn)的，private方法不能被代理，事務(wù)不生效。此外static方法屬于類，不屬于任何對象，也不會被代理，事務(wù)不生效。final方法無法被重寫，也不能被代理，事務(wù)不生效。
• 未被Spring管理的類
  Spring實現(xiàn)對象的動態(tài)代理，首先這個對象要交給Spring管理
• 一個方法調(diào)用本類的另一個方法
  @Transactional基于AOP實現(xiàn)，而AOP又是基于動態(tài)代理實現(xiàn)，直接調(diào)用本類方法或使用this調(diào)用本類方法，均不是Spring的代理對象，無法實現(xiàn)動態(tài)代理，事務(wù)也就不會生效。
• 數(shù)據(jù)表不支持事務(wù)
• Spring事務(wù)傳播級別設(shè)置為不支持事務(wù)

分布式事務(wù)

什么是分布式事務(wù)

分布式事務(wù)是在分布式系統(tǒng)中維護數(shù)據(jù)一致性的方式。它擴展了ACID事務(wù)的概念，以跨越多個分布式服務(wù)、數(shù)據(jù)庫和資源的范圍來保證數(shù)據(jù)的一致性。

分布式事務(wù)面臨的挑戰(zhàn)

• 網(wǎng)絡(luò)延遲：跨網(wǎng)絡(luò)執(zhí)行事務(wù)可能導致較高的延遲，影響性能。
• 故障處理：分布式系統(tǒng)中的節(jié)點故障可能導致事務(wù)的不一致狀態(tài)，需要復雜的故障處理機制。
• 并發(fā)控制：多個事務(wù)同時訪問和修改共享數(shù)據(jù)需要有效的并發(fā)控制機制。

分布式事務(wù)的歷史與發(fā)展

分布式事務(wù)的歷史和發(fā)展經(jīng)歷了多個階段，從早期的兩階段提交到最近的新興分布式數(shù)據(jù)庫和NoSQL解決發(fā)方案。

• 兩階段提交（2PC）：
  • 1980年代末到1990年代初，提出了兩階段提交。兩階段提交通過協(xié)調(diào)者和參與者的協(xié)作，確保在多個分布式數(shù)據(jù)庫之間的事務(wù)具有原子性和一致性。
  • 2PC的問題在于它可能導致性能瓶頸和阻塞，因為在第二階段需要等待所有參與者的確認。
• 三階段提交（3PC）
  • 為了階段2PC的一些問題，提出了三階段提交。3PC引入了一個預提交節(jié)點，以減少阻塞問題，然而它仍然存在某些情況下無法解決的問題。
• XA事務(wù)
  • XA（eXtended Architecture）是一種用于分布式事務(wù)的標準，由X/Open組織制定。XA事務(wù)使用了分布式管理器（TransactionManager）來協(xié)調(diào)多個資源管理器（Resource Manager）的事務(wù)。
  • XA事務(wù)提供了分布式事務(wù)的一些標準化機制，但它在性能可伸縮性方面仍然有限制
• Sage模式
  • Sage是一種分布式事務(wù)模型，將長事務(wù)拆分成一系列小事務(wù)，并使用補償事務(wù)來處理部分失敗。Sage模式在微服務(wù)架構(gòu)中得到廣泛應用，以提高系統(tǒng)的可伸縮性和可恢復性。
• NoSQL數(shù)據(jù)庫
  • 隨著分布式計算和大數(shù)據(jù)的興起，出現(xiàn)了各種新興的NoSQL數(shù)據(jù)庫，如Cassandra、MongoDB和Couchbase。這些數(shù)據(jù)庫通過采用了最終一致性的模型，提高性能和可用性。
  • NoSQL數(shù)據(jù)庫的出現(xiàn)使得開發(fā)人員需要重新考慮分布式事務(wù)的模型，并引用了新的解決方案，如CRDTs（Confict-Free Replicated Data Types）。
• 新興分布式數(shù)據(jù)庫
  • 近年來，出現(xiàn)了一些性能的分布式數(shù)據(jù)庫系統(tǒng)，如Google的Spanner和CockroachDB，它們旨在提供全球分布式事務(wù)的支持。這些系統(tǒng)使用全球分布式的時間同步和意義性協(xié)議來實現(xiàn)強一致性的分布式事務(wù)。
• 區(qū)塊鏈技術(shù)
  • 區(qū)塊鏈技術(shù)引入了一種分布式賬本的概念，其中的交易具有強一致性和不可變性。這使得區(qū)塊稱為一種分布式事務(wù)的潛在選擇，尤其是金融和合同領(lǐng)域。

分布式事務(wù)處理方法

2PC

兩階段提交是一種強一致性設(shè)計，它引入一個事務(wù)協(xié)調(diào)者的角色協(xié)調(diào)管理各個參與者的提交和回滾。

• 準備階段（Phase1 - Prepare Phase）
  • 協(xié)調(diào)者向所有參與者發(fā)送事務(wù)準備請求
  • 參與者收到請求后，會執(zhí)行事務(wù)的準備操作，并準備好事務(wù)的狀態(tài)（提交或回滾）保存到本地
  • 參與者在準備完成后向協(xié)調(diào)者發(fā)送準備完成的通知，同時將本地準備狀態(tài)持久化
• 提交階段（Phase2 - Commit Phase）
  • 協(xié)調(diào)者在收到所有參與者的準備完成通知后，如果所有參與者都準備就緒，將向所有參與者發(fā)送事務(wù)提交請求。
  • 參與者接受到提交請求后，會執(zhí)行事務(wù)的提交操作，將事務(wù)永久性的應用到系統(tǒng)中并釋放之前的資源。
  • 參與者在完成提交后發(fā)送提交完成的通知。
• 回滾階段（Phase2 - Rollback Phase）
  • 如果在準備階段任何參與者沒有準備好，或者有參與者在提交階段失敗，協(xié)調(diào)者將會向所有參與者發(fā)送事務(wù)回滾請求。
  • 參與者接受到回滾請求后，會執(zhí)行事務(wù)回滾操縱，將之前的操作撤銷，并釋放資源。
  • 參與者在完成回滾后向協(xié)調(diào)者發(fā)送回滾完成的通知。

2PC存在的問題

• 同步阻塞：所有的參數(shù)者都是事務(wù)同步阻塞型的，當參與者占有公共資源時，其他三方訪問公共資源不得不處于阻塞狀態(tài)。
• 單點故障：一旦協(xié)調(diào)者發(fā)生故障，系統(tǒng)不可用。
• 數(shù)據(jù)不一致：當協(xié)調(diào)者發(fā)送commit之后，有的參與者收到commit消息，事務(wù)執(zhí)行成功，有的沒有收到，處于阻塞狀態(tài)，這段時間會產(chǎn)生數(shù)據(jù)不一致情況。
• 不確定性：當協(xié)調(diào)者發(fā)送commit后，并且此時只有一個參與者收到commit，那么當該參與者與協(xié)調(diào)器同時宕機后，重新選舉的協(xié)調(diào)者無法確定該消失是否提交成功。

2PC的優(yōu)勢在于對業(yè)務(wù)沒有侵入，可以利用數(shù)據(jù)庫自身機制急性事務(wù)的提交和回滾。常見的機遇2PC的具體落地方案有JTA（XA規(guī)范）和Seata（AT模式）

3PC

三階段提交是二階段提交的改進版本，在協(xié)調(diào)者和參與者都引入了超時機制，在2PC中的準備階段和提交階段增加了一個預提交階段。

• 準備階段（CanCommit）：協(xié)調(diào)者向各個參與者發(fā)送請求，詢問是否可以執(zhí)行事務(wù)，但并不是執(zhí)行事務(wù)。
• 預提交階段（PreCommit）：如果從協(xié)調(diào)者得到反饋是滿足執(zhí)行條件，那么就發(fā)送預提交請求，并開始執(zhí)行事務(wù)；如果從協(xié)調(diào)者得到返回時不滿足執(zhí)行條件或者超時，則發(fā)送事務(wù)中斷請求。
• 提交階段（DoCommit）：如果預提交階段發(fā)送的是預提交請求，那么正常提交事務(wù)；如果預提交階段發(fā)送的是事務(wù)中斷請求，那么直接中斷事務(wù)。
  相對于 2PC，3PC 主要解決的單點故障問題，并減少阻塞，因為一旦參與者無法及時收到來自協(xié)調(diào)者的信息之后，他會默認執(zhí)行 commit。而不會一直持有事務(wù)資源并處于阻塞狀態(tài)。但是這種機制也會導致數(shù)據(jù)一致性問題，因為，由于網(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的中斷響應沒有及時被參與者接收到，那么參與者在等待超時之后執(zhí)行了 commit 操作。這樣就和其他接到中斷命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。而且 3PC 整體的交互過程更長，性能也會有所下降。
  3PC 目前似乎只存在于理論，還沒有具體落地方案。

TCC

2PC和3PC都是依賴于數(shù)據(jù)庫的事務(wù)提交和回滾，但是有時候很多業(yè)務(wù)并不知涉及到數(shù)據(jù)庫，可能會發(fā)送短信、消息等，而TCC就是屬于業(yè)務(wù)層面的分布式應用。
TCC方案分為Try-Confirm-Cancel三個階段，屬于補償性分布式事務(wù)。

• Try階段：完成所有業(yè)務(wù)檢查（一致性），預留業(yè)務(wù)資源（隔離性）
• Confirm階段：確認執(zhí)行業(yè)務(wù)操作，不再做任何業(yè)務(wù)檢查，只使用Try階段預留的業(yè)務(wù)資源。
• Cancel階段：取消Try階段預留的業(yè)務(wù)資源。
  
  Try階段失敗了會執(zhí)行Cancel，Confirm階段失敗會不斷進行重試，或者進行人工干預。
  TCC需要根據(jù)每個場景和業(yè)務(wù)邏輯來設(shè)計相應的操作，所以很大程度增加了業(yè)務(wù)代碼的復雜度，對業(yè)務(wù)有很大的侵入。但是沒有資源阻塞，每一個方法都是直接提交事務(wù)的，如果出錯是通過業(yè)務(wù)層面的Cancel來進行補償，所以也稱補償事務(wù)方法。

TCC要注意的幾個問題

• 冪等問題：因為網(wǎng)絡(luò)調(diào)用無法保證請求一定能到達，所以都會有重試機制，因此對于Try、Confirm、Cancel三個方法都需要冪等實現(xiàn)，避免重復執(zhí)行產(chǎn)生錯誤。
• 空回滾問題：指的是Try方法由于網(wǎng)絡(luò)問題沒有收到超時了，此時事務(wù)管理器就會發(fā)出Cancel命令，那么需要支持Cancel在沒有執(zhí)行Try的情況下能正常Cancel。
• 懸掛問題：這個問題也是指Try方法由于網(wǎng)絡(luò)阻塞超時出發(fā)了事務(wù)管理器發(fā)出了Cannel命令，但是執(zhí)行了Cancel命令之后，Try請求到了。所以空回滾之后還得記錄一下，防止Try的再調(diào)用。

可靠消息最終一致性方案

RocketMQ4.3之后的版本正式支持事務(wù)消息。

• 服務(wù)A（生產(chǎn)者）向Broker（消息中間件）發(fā)送一個HalfMessage（半消息：消息發(fā)送到Broker端，但是消息的狀態(tài)被標記為“不能投遞”，即消費者看不到）
• 半消息發(fā)送成功后，服務(wù)A執(zhí)行本地事務(wù)。
• 事務(wù)執(zhí)行成功，向Broker發(fā)送Commit命令，此時半消息就變成了可以被消費的消息；如果失敗，則發(fā)送一個RollBack命令，該消息會被刪除。
• 服務(wù)B（消費者）收到消息后消費該消息即可。
• 在RocketMQ沒有收到服務(wù)A確認狀態(tài)的消息，那么半消息會自宋定時輪詢毀掉接口，詢問這個處理的處理情況。
• 服務(wù)B在執(zhí)行的過程中也可能會失敗，這時需要重試，一直執(zhí)行不成功也需要人工介入，同時也需要保證服務(wù)B方法的冪等性。

應用場景

分布式事務(wù)適用于需要數(shù)據(jù)一致性的多個應用場景，包括：

• 電子商務(wù)：確保訂單處理、支付和庫存管理等操作的一致性。
• 金融服務(wù)：跨銀行交易、交易清算和資金階段的一致性管理。
• 物流和供應鏈：跨多個倉庫、配送中心和供應商的庫存和訂單管理。
• 在線游戲：多玩家游戲中的虛擬經(jīng)濟和資源管理。

結(jié)論

事務(wù)和分布式事務(wù)是分布式系統(tǒng)和數(shù)據(jù)庫管理中的關(guān)鍵概念，了解了它們的原則、屬性和實現(xiàn)方式對于構(gòu)建高可用、高性能和數(shù)據(jù)一致性的應用程序至關(guān)重要。在選擇分布式事務(wù)方案是，需要根據(jù)應用的的要求權(quán)衡性能、復雜度和一致性。

引用

https://www.cnblogs.com/chengxy-nds/p/14046856.html