分布式事務(wù)

背景

在微服務(wù)環(huán)境下，因?yàn)闀?huì)根據(jù)不同的業(yè)務(wù)會(huì)拆分成不同的服務(wù)，比如會(huì)員服務(wù)、訂單服務(wù)、商品服務(wù)等，讓專業(yè)的人做專業(yè)的事情，每個(gè)服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，并且是獨(dú)立運(yùn)行，互不影響。但是每個(gè)服務(wù)中都有自己獨(dú)立的數(shù)據(jù)源，即自己獨(dú)立的本地事務(wù)。兩個(gè)服務(wù)相互通訊的時(shí)候，兩個(gè)本地事務(wù)互不影響，從而出現(xiàn)分布式事務(wù)產(chǎn)生的原因。

案例說(shuō)明： 下單和扣庫(kù)存如何保持一致問(wèn)題

描述：數(shù)據(jù)庫(kù)都是獨(dú)立的，每個(gè)獨(dú)立的數(shù)據(jù)源中都有自己獨(dú)立的事務(wù)，該事務(wù)成為本地事務(wù)。本地事務(wù)有效范圍在同一個(gè)jdbc里面(同一個(gè)事務(wù)管理器 )

代碼展示:

問(wèn)題：下單失敗了，但是庫(kù)存成功了，如何去回滾？注意：下單成功，庫(kù)存失敗，不屬于分布式事務(wù)問(wèn)題。

總結(jié)： 本地?cái)?shù)據(jù)源有效范圍是 同一個(gè)jdbc連接或者同一個(gè)事務(wù)管理器。

分布式事務(wù)解決方案

剛性事務(wù) -- 關(guān)系型數(shù)據(jù)庫(kù)的ACID

關(guān)系型數(shù)據(jù)庫(kù)天生就是解決具有復(fù)雜事務(wù)場(chǎng)景的問(wèn)題，關(guān)系型數(shù)據(jù)庫(kù)完全滿足ACID的特性。滿足ACID特性

ACID對(duì)應(yīng)的含義：事務(wù)管理(ACID)

談到事務(wù)一般都是以下四點(diǎn):

原子性(Atomicity)：原子性是指事務(wù)是一個(gè)不可分割的工作單位，事務(wù)中的操作要么都發(fā)生，要么都不發(fā)生。

一致性(Consistency)：事務(wù)前后數(shù)據(jù)的完整性必須保持一致。

隔離性(Isolation)：事務(wù)的隔離性是多個(gè)用戶并發(fā)訪問(wèn)數(shù)據(jù)庫(kù)時(shí)，數(shù)據(jù)庫(kù)為每一個(gè)用戶開(kāi)啟的事務(wù)，不能被其他事務(wù)的操作數(shù)據(jù)所干擾，多個(gè)并發(fā)事務(wù)之間要相互隔離。

持久性(Durability)：持久性是指一個(gè)事務(wù)一旦被提交，它對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)的改變就是永久性的，接下來(lái)即使數(shù)據(jù)庫(kù)發(fā)生故障也不應(yīng)該對(duì)其有任何影響

柔性事務(wù) -- 遵循Base和CPA理論

CPA理論

C:Consistency, 一致性。在分布式系統(tǒng)中的所有數(shù)據(jù) 備份，在同一時(shí)刻具有同樣的值，所有節(jié)點(diǎn)在同一時(shí)刻讀取的數(shù)據(jù)都是最新的數(shù)據(jù)副本。雙方進(jìn)行通訊的時(shí)候，或者服務(wù)器集群的時(shí)候，一定要保證數(shù)據(jù)一致性問(wèn)題，不能發(fā)生臟讀等問(wèn)題。其實(shí)一般情況下可以做個(gè)取舍，可以暫時(shí)不遵循一致性，但是達(dá)到最終一致性，只要核心遵循下面的可用性和分區(qū)容忍性就可以。

A:Availability,可用性，好的響應(yīng)性能。完全的可用性指的是在任何故障模型下，服務(wù)都會(huì)在有限的時(shí)間內(nèi)處理完成并進(jìn)行響應(yīng)。比如服務(wù)器宕機(jī)情況下 還有備機(jī)

P: Partition tolerance,分區(qū)容錯(cuò)性。盡管網(wǎng)絡(luò)上有部分消息丟失，但系統(tǒng)仍然可繼續(xù)工作。

總結(jié)：

CAP原理指的是，這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。

對(duì)于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求，容錯(cuò)是肯定的，否則就失去了價(jià)值，在一致性和可用性之間取一個(gè)平衡

對(duì)于大多數(shù)web應(yīng)用，其實(shí)并不需要強(qiáng)一致性，因此犧牲一致性而換取高可用性，是目前多數(shù)分布式數(shù)據(jù)庫(kù)產(chǎn)品的方向。

通過(guò)軟狀態(tài)，可以暫時(shí)不一致，但是最終實(shí)現(xiàn)一致。通過(guò)補(bǔ)償、重試等。

犧牲一致性，只是不再要求關(guān)系型數(shù)據(jù)庫(kù)中的強(qiáng)一致性，而是只要系統(tǒng)能達(dá)到最終一致性即可

由于關(guān)系型數(shù)據(jù)庫(kù)是單節(jié)點(diǎn)無(wú)復(fù)制的，因此不具有分區(qū)容忍性，但是具有一致性和可用性，而分布式的服務(wù)化系統(tǒng)都需要滿足分區(qū)容忍性，那么我們必須在一致性和可用性之間進(jìn)行權(quán)衡

注意實(shí)際開(kāi)發(fā)中只遵循了P和A

Base 理論

BA:(Basically Available)，基本可用。指分布式系統(tǒng)在出現(xiàn)故障的時(shí)候，保證核心可用。比如：網(wǎng)頁(yè)訪問(wèn)過(guò)大時(shí)，部分用戶提供降級(jí)服務(wù)。

S:(Soft State)，軟狀態(tài)，狀態(tài)可以在一段時(shí)間內(nèi)不同步。

E:(Eventually Consistent)，最終一致，在一定的時(shí)間內(nèi)，最終數(shù)據(jù)達(dá)成一致即可。

總結(jié)：BASE 思想與 ACID 原理截然不同，它滿足CAP原理，通過(guò)犧牲強(qiáng)一致性獲得可用性， 一般應(yīng)用于服務(wù)化系統(tǒng)的應(yīng)用層或者大數(shù)據(jù)處理系統(tǒng)中，通過(guò)達(dá)到最終一致性來(lái)盡量滿足業(yè)務(wù)的絕大多數(shù)需求。

支付案例

流程如下：

toov5 調(diào)用支付寶時(shí)候 會(huì)傳遞兩個(gè)參數(shù) 同步回調(diào)地址 和 異步回調(diào)地址

同步回調(diào)地址：支付完成后，支付寶采用瀏覽器方式重定向回調(diào)方

異步回調(diào)地址：支付完成后，采用后臺(tái)也就是HttpClient進(jìn)行調(diào)用toov5接口通知支付接口

當(dāng)通知接口出現(xiàn)延遲或者異常情況下，支付寶會(huì)發(fā)生自動(dòng)重試。短暫的不一致情況

柔性事務(wù)分為：

兩階段型

補(bǔ)償型

異步確保型

最大努力通知型

關(guān)于兩階段、三階段

1. 兩階段： 交易中間件與數(shù)據(jù)庫(kù)通過(guò) XA 接口規(guī)范，使用兩階段提交來(lái)完成一個(gè)全局事務(wù)， XA規(guī)范的基礎(chǔ)是兩階段提交協(xié)議。

準(zhǔn)備階段：協(xié)調(diào)者向參與者發(fā)起指令，參與者評(píng)估自己的狀態(tài)，如果參與者評(píng)估指令可以完成，則會(huì)寫(xiě)redo或者undo日志(提交日志和回滾日志)，然后鎖定資源，執(zhí)行操作，但并不提交。

提交階段：協(xié)調(diào)者會(huì)向參與者發(fā)送一個(gè)指令，如果參與者收到指令后，會(huì)把該業(yè)務(wù)邏輯是否執(zhí)行成功結(jié)果返回給協(xié)調(diào)者。如果參與者都返回執(zhí)行成功，協(xié)調(diào)者在第二階段發(fā)送提交事務(wù)通知，如果有一方執(zhí)行失敗，就會(huì)終止提交。

缺點(diǎn)：

如果協(xié)調(diào)者發(fā)生宕機(jī)，整個(gè)就沒(méi)法指揮協(xié)調(diào)了。庫(kù)存服務(wù)和訂單服務(wù)會(huì)一直等待。

兩階段提交方案鎖定資源時(shí)間長(zhǎng)，對(duì)性能影響很大，基本不適合解決微服務(wù)事務(wù)問(wèn)題。

技術(shù)落地:

Jta+Atomikos 屬于兩階段提交協(xié)議。底層是基于XA協(xié)議，主流數(shù)據(jù)庫(kù)MySQL等都支持XA協(xié)議。這個(gè)協(xié)議規(guī)范就是協(xié)調(diào)者把指令發(fā)送給參與者的過(guò)程。MySQL是參與者，Atomikos:Atomikos TransactionsEssentials是一個(gè)為Java平臺(tái)提供增值服務(wù)的并且開(kāi)源類事務(wù)管理器，底層就是遵循了XA協(xié)議的規(guī)范。

Jta+Atomikos 代碼案例

1. 三階段提交協(xié)議 --- 兩階段準(zhǔn)備階段再加了一個(gè)詢問(wèn)階段

詢問(wèn)階段：協(xié)調(diào)者詢問(wèn)參與者是否可以完成指令，協(xié)調(diào)者只需要回答是還是不是，而不需要做真正的操作，這個(gè)階段超時(shí)導(dǎo)致中止。協(xié)調(diào)者和參與者執(zhí)行的任務(wù)中都增加了超時(shí)，一旦超時(shí)，協(xié)調(diào)者和參與者都繼續(xù)提交事務(wù)，默認(rèn)為成功，這也是根據(jù)概率統(tǒng)計(jì)上超時(shí)后默認(rèn)成功的正確性最大。

優(yōu)點(diǎn)：至少不會(huì)阻塞和永遠(yuǎn)鎖定資源。

結(jié)合非關(guān)系型數(shù)據(jù)庫(kù)

但當(dāng)數(shù)據(jù)庫(kù)要開(kāi)始滿足橫向擴(kuò)展、高可用、模式自由等需求時(shí)，需要對(duì)ACID理論進(jìn)行取舍，不能嚴(yán)格遵循ACID。以CAP理論和BASE理論為基礎(chǔ)的NoSQL數(shù)據(jù)庫(kù)開(kāi)始出現(xiàn)。

由于NoSQL的基本需求就是支持分布式存儲(chǔ)，嚴(yán)格一致性與可用性需要互相取舍，由此延伸出了CAP理論來(lái)定義分布式存儲(chǔ)遇到的問(wèn)題。

總結(jié)

以上是生活随笔為你收集整理的18c分布式事务 oracle_分布式事务的现象及理解的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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