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

概述

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

事務(wù)

什么事事務(wù)

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

ACID屬性

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

如何保證原子性

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

如何保證持久性

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

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

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

事務(wù)并發(fā)帶來(lái)的問(wèn)題及隔離級(jí)別

當(dāng)事務(wù)并發(fā)的時(shí)候會(huì)帶來(lái)一下問(wèn)題：

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

為了解決并發(fā)事務(wù)帶來(lái)的問(wèn)題，提供了事務(wù)的隔離級(jí)別：

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

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

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

Spring中的事務(wù)管理

事務(wù)的傳播行為

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

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

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

分布式事務(wù)

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

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

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

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

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

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

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

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

2PC

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

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

2PC存在的問(wèn)題

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

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

3PC

三階段提交是二階段提交的改進(jìn)版本，在協(xié)調(diào)者和參與者都引入了超時(shí)機(jī)制，在2PC中的準(zhǔn)備階段和提交階段增加了一個(gè)預(yù)提交階段。

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

TCC

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

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

TCC要注意的幾個(gè)問(wèn)題

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

可靠消息最終一致性方案

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

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

應(yīng)用場(chǎng)景

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

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

結(jié)論

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

引用

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