国产亚洲精品福利在线无卡一,国产精久久一区二区三区,亚洲精品无码国模,精品久久久久久无码专区不卡

當(dāng)前位置: 首頁(yè) > news >正文

免費(fèi)的外鏈網(wǎng)站青島自動(dòng)seo

免費(fèi)的外鏈網(wǎng)站,青島自動(dòng)seo,wordpress淘寶客主題制作,有什么好的網(wǎng)站做推廣的微服務(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ù)一致性管…

微服務(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

http://m.aloenet.com.cn/news/43289.html

相關(guān)文章:

  • web前端開(kāi)發(fā)環(huán)境有哪些做抖音seo排名軟件是否合法
  • 網(wǎng)站打開(kāi)是404什么是電商?電商怎么做
  • 做物流網(wǎng)站費(fèi)用多少產(chǎn)品宣傳推廣策劃
  • 鄭州做網(wǎng)站推廣的公司天津百度seo代理
  • 常州市建設(shè)局網(wǎng)站qq營(yíng)銷(xiāo)
  • 網(wǎng)站搭建報(bào)價(jià)百度一下官網(wǎng)首頁(yè)百度一下
  • 深圳網(wǎng)站建設(shè)hi0755seo怎么發(fā)外鏈的
  • 互聯(lián)網(wǎng)網(wǎng)站建設(shè)公司百度新站關(guān)鍵詞排名
  • 網(wǎng)站備案要關(guān)站嗎google網(wǎng)頁(yè)搜索
  • 汽車(chē)網(wǎng)站建設(shè)規(guī)劃書(shū)百度首頁(yè)優(yōu)化排名
  • 網(wǎng)易游戲官網(wǎng)seo網(wǎng)站推廣如何做
  • 電子商務(wù)代運(yùn)營(yíng)百度筆記排名優(yōu)化
  • 上蔡專(zhuān)業(yè)網(wǎng)站建設(shè)突發(fā)大事震驚全國(guó)
  • 南寧哪里做網(wǎng)站輸入關(guān)鍵詞進(jìn)行搜索
  • 網(wǎng)站權(quán)重劃分seo 是什么
  • 用pc做網(wǎng)站服務(wù)器為什么不如云主機(jī)百度輸入法下載
  • 長(zhǎng)沙免費(fèi)網(wǎng)站排名seo觀察網(wǎng)
  • 做o2o平臺(tái)網(wǎng)站需要多少錢(qián)chrome 谷歌瀏覽器
  • 個(gè)性個(gè)人網(wǎng)站模板建網(wǎng)站建設(shè)
  • 化妝品可做的團(tuán)購(gòu)網(wǎng)站有哪些seo排名優(yōu)化教程
  • php網(wǎng)站開(kāi)發(fā)什么外貿(mào)推廣代理
  • 潤(rùn)東電子科技 網(wǎng)站建設(shè)全網(wǎng)營(yíng)銷(xiāo)推廣方案外包
  • 濟(jì)南網(wǎng)站APP如何做好百度推廣
  • 二手房網(wǎng)站怎么做最常見(jiàn)企業(yè)網(wǎng)站公司有哪些
  • 云主機(jī)做網(wǎng)站域名打不開(kāi)線上營(yíng)銷(xiāo)活動(dòng)有哪些
  • 外貿(mào)公司的網(wǎng)站建設(shè)杭州seo專(zhuān)員
  • 我要建個(gè)網(wǎng)站做微商如何引流推廣怎么找客源
  • wordpress Ins同步百度seo關(guān)鍵詞排名 s
  • 有找獵聘網(wǎng)站做簡(jiǎn)歷優(yōu)化的南寧關(guān)鍵詞排名公司
  • 龍巖網(wǎng)站設(shè)計(jì)培訓(xùn)軟文營(yíng)銷(xiāo)的步驟