欧美三级高清在线,日韩一区二区精品视频,翔田千里珍藏版无码,思思网站,亚洲天堂三级片,漂亮女大学一级毛片视频,欧美在线视频导航,www黄色网址

在微服務(wù)架構(gòu)盛行的情況下，在分布式的多個(gè)服務(wù)中保證業(yè)務(wù)的一致性，即分布式事務(wù)就顯得尤為重要。本文將講述分布式事務(wù)及其解決方案，有XA協(xié)議、TCC和Saga事務(wù)模型、本地消息表、事務(wù)消息和阿里開源的Seata。

分布式事務(wù)

聊什么是分布式事務(wù)前，先聊一下我們熟悉的單機(jī)事務(wù)。所謂單機(jī)事務(wù)是相對分布式事務(wù)來說的，即數(shù)據(jù)庫事務(wù)。大家都知道數(shù)據(jù)庫事務(wù)有ACID這四個(gè)特性：

A（Atomicity）：指單個(gè)事務(wù)中的操作要不都執(zhí)行，要不都不執(zhí)行
C（Consistency）：指事務(wù)前后數(shù)據(jù)的完整性必須保持一致
I（Isolation）：指多個(gè)事務(wù)對數(shù)據(jù)可見性的規(guī)則
D（Durability）：指事務(wù)提交后，就會被永久存儲下來

既然數(shù)據(jù)庫事務(wù)有這四個(gè)特性的，那么分布式事務(wù)也不例外，應(yīng)該具備這四個(gè)特性。

在微服務(wù)架構(gòu)下，服務(wù)之間通過RPC遠(yuǎn)程調(diào)用，相對單機(jī)事務(wù)來說，多了“網(wǎng)絡(luò)通信”這一不確定因素，使得本來服務(wù)的調(diào)用只有“成功”和“失敗”這兩種返回結(jié)果，變?yōu)椤俺晒Α薄ⅰ笆　焙汀拔粗比N返回結(jié)果。系統(tǒng)之間的通信可靠性從單一系統(tǒng)中的可靠變成了微服務(wù)架構(gòu)之間的不可靠，分布式事務(wù)其實(shí)就是在不可靠的通信下實(shí)現(xiàn)事務(wù)的特性。一般因?yàn)榫W(wǎng)絡(luò)導(dǎo)致的異?？赡苡袡C(jī)器宕機(jī)、網(wǎng)絡(luò)異常、消息丟失、消息亂序、數(shù)據(jù)錯(cuò)誤、不可靠的TCP、存儲數(shù)據(jù)丟失、其他異常等等。

分布式事務(wù)方案

2PC/3PC

2PC即二階段提交：

二階段提交（英語：Two-phase Commit）是指在計(jì)算機(jī)網(wǎng)絡(luò)以及數(shù)據(jù)庫領(lǐng)域內(nèi)，為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點(diǎn)在進(jìn)行事務(wù)提交時(shí)保持一致性而設(shè)計(jì)的一種算法。通常，二階段提交也被稱為是一種協(xié)議（Protocol）。

2PC是一種協(xié)議，它的作用保證在分布式系統(tǒng)中每個(gè)節(jié)點(diǎn)要不都提交事務(wù)，要么都取消事務(wù)。這個(gè)跟ACID中的A原子性的定義很像。

2PC引入一個(gè)第三方的節(jié)點(diǎn)協(xié)調(diào)者，即Coordinator，其他參與事務(wù)的節(jié)點(diǎn)為參與者，即Participants。協(xié)調(diào)者統(tǒng)籌整個(gè)事務(wù)行為，負(fù)責(zé)通知參與者進(jìn)行Commit還是Rollback操作。

2PC的過程比較簡單，分為兩個(gè)階段：

準(zhǔn)備階段，協(xié)調(diào)者分別給每個(gè)參與者發(fā)送Prepare消息，每個(gè)參與者收到消息后，進(jìn)行“預(yù)提交”操作（不是實(shí)際的提交操作），把操作的結(jié)果（成功或失敗）返回給協(xié)調(diào)者。
提交階段，協(xié)調(diào)者根據(jù)準(zhǔn)備階段收到的參與者的返回結(jié)果進(jìn)行判斷，如果所有的參與者都返回成功，那么分別給每個(gè)參與者發(fā)送Commit消息，否則發(fā)送Rollback消息。

2PC是一個(gè)強(qiáng)一致性協(xié)議，同時(shí)它在實(shí)際應(yīng)用中還存在幾個(gè)問題：

同步阻塞，2PC的兩個(gè)階段中，協(xié)調(diào)者和參與者的通信都是同步的，這會導(dǎo)致整個(gè)事務(wù)的長時(shí)間阻塞
Coordinator的單點(diǎn)問題
數(shù)據(jù)不一致，在Commit階段，可能存在只有部分參與者收到Commit消息（或處理成功）的情況

3PC

3PC即三階段提交，它比2PC多了一個(gè)階段，即把原來2PC的準(zhǔn)備階段拆分成CanCommit和PreCommit兩個(gè)階段，同時(shí)引入超時(shí)機(jī)制來解決2PC的同步阻塞問題。

但是在我看來3PC并沒有解決2PC的根本問題，它只是在2PC的基礎(chǔ)上做了一些優(yōu)化，它增加了一個(gè)階段（也增加了1個(gè)RTT）來提高對方可用性的概率，這本質(zhì)跟TCP的三次握手一樣，同樣也改為四次握手，五次握手等等。

XA是一種基于2PC協(xié)議實(shí)現(xiàn)的規(guī)范。在2PC中沒有明確資源是什么，以及資源是怎么提交的等等，而XA就是數(shù)據(jù)庫實(shí)現(xiàn)2PC的規(guī)范，已知常用的支持XA的關(guān)系型數(shù)據(jù)庫有Mysql、Oracle等。

本地消息表

本地消息表方案應(yīng)該是業(yè)界內(nèi)使用最為廣泛的，因?yàn)樗褂煤唵危杀颈容^低。

本地消息表的方案最初是由eBay提出（完整方案），核心思路是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理。

它的處理流程如下：

事務(wù)發(fā)起方把要處理的業(yè)務(wù)事務(wù)和寫消息表這兩個(gè)操作放在同一個(gè)本地事務(wù)里
事務(wù)發(fā)起方有一個(gè)定時(shí)任務(wù)輪詢消息表，把沒處理的消息發(fā)送到消息中間件
事務(wù)被動方從消息中間件獲取消息后，返回成功
事務(wù)發(fā)起方更新消息狀態(tài)為已成功

從處理流程來看，本地消息表方案是一個(gè)基于消息中間件的可靠性來達(dá)到事務(wù)的最終一致性的方案。

一些分析：

把業(yè)務(wù)處理和寫消息表放在同一個(gè)事務(wù)是為了失敗/異常后可以同時(shí)回滾
為什么不直接發(fā)消息，而是先寫消息表？試想，如果發(fā)送消息超時(shí)了，即不確定消息中間件收到消息沒，那么你是重試還是拋異?；貪L事務(wù)呢？回滾是不行的，因?yàn)榭赡芟⒅虚g件已經(jīng)收到消息，接收方收到消息后做處理，導(dǎo)致雙方數(shù)據(jù)不一致了；重試也是不行的，因?yàn)橛锌赡軙恢敝卦囀?，?dǎo)致事務(wù)阻塞。
基于上述分析，消息的接收方是需要做冪等操作的

本地消息表方案整體來說還是比較簡單、可用的，但是也有以下缺點(diǎn)：

消息數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)耦合，消息表需要根據(jù)具體的業(yè)務(wù)場景制定，不能公用。就算可以公用消息表，對于分庫的業(yè)務(wù)來說每個(gè)庫都是需要消息表的。
只適用于最終一致的業(yè)務(wù)場景。例如在 A -> B場景下，在不考慮網(wǎng)絡(luò)異常、宕機(jī)等非業(yè)務(wù)異常的情況下，A成功的話，B肯定也會成功的。

事務(wù)消息

事務(wù)消息是通過消息中間件來解耦本地消息表和業(yè)務(wù)數(shù)據(jù)表，適用于所有對數(shù)據(jù)最終一致性需求的場景?，F(xiàn)在支持事務(wù)消息的消息中間件只有RocketMQ，這個(gè)概念最早也是RocketMQ提出的。

通過事務(wù)消息實(shí)現(xiàn)分布式事務(wù)的流程如下：

發(fā)起方發(fā)送半事務(wù)消息會給RocketMQ ，此時(shí)消息的狀態(tài)prepare，接受方還不能拉取到此消息
發(fā)起方進(jìn)行本地事務(wù)操作
發(fā)起方給RocketMQ確認(rèn)提交消息，此時(shí)接受方可以消費(fèi)到此消息了

步驟1和3失敗/異常該如何處理：

RocketMQ會定期掃描還沒確認(rèn)的消息，回調(diào)給發(fā)送方，詢問此次事務(wù)的狀態(tài)，根據(jù)發(fā)送方的返回結(jié)果把這條消息進(jìn)行取消還是提交確認(rèn)。

可以看出事務(wù)消息的本質(zhì)的借鑒了二階段提交的思想，它跟本地消息表的做法也很像，事務(wù)消息做的事情其實(shí)就是把消息表的存儲和掃描消息表這兩個(gè)事情放到消息中間件來做，使得消息表和業(yè)務(wù)表解耦。

TCC

TCC （Try-Confirm-Cancel）事務(wù)模型采用的是補(bǔ)償機(jī)制，其核心思想是：針對每個(gè)操作，都要注冊一個(gè)與其對應(yīng)的確認(rèn)和補(bǔ)償操作。

相當(dāng)于XA來說，TCC可以不依賴于資源管理器，即數(shù)據(jù)庫，它是通過業(yè)務(wù)邏輯來控制確認(rèn)和補(bǔ)償操作的，所以它用了’Cancel’而非’Rollback’的字眼。它是一個(gè)應(yīng)用層面的2PC。

TCC分為三個(gè)階段：

Try階段，對業(yè)務(wù)資源進(jìn)行檢測和預(yù)留
Confirm階段，對Try階段預(yù)留的資源進(jìn)行確認(rèn)提交，Try階段執(zhí)行成功是Confirm階段執(zhí)行成功的前提
Cancel階段，對Try階段預(yù)留的資源進(jìn)行撤銷或釋放

看上去TCC跟2PC/3PC可能有點(diǎn)像，但是TCC強(qiáng)調(diào)的是補(bǔ)償，而且對于對資源的“預(yù)留”，“確認(rèn)”，“釋放”，TCC并沒有明確說要如何做，這個(gè)具體是要業(yè)務(wù)來定義的。

例如在轉(zhuǎn)賬的場景，“預(yù)留”操作可能就是對賬號里的部分資金進(jìn)行凍結(jié)，這樣這個(gè)資金只能是當(dāng)前事務(wù)才能用，別的事務(wù)用不了。

另外，對于異常的場景，TCC也沒有說要怎么做，因?yàn)門ry、Confirm、Cancel都是業(yè)務(wù)定義的，這三個(gè)階段中發(fā)生了異常，那么就由業(yè)務(wù)來做相應(yīng)的處理。一般都有以下幾種處理：

如果Try成功了，那么Confirm階段異常了就一直重試，直到成功
Try、Confirm、Cancel三個(gè)階段都有相應(yīng)的資源及事務(wù)日志，應(yīng)用根據(jù)日志（異步）來做重試或補(bǔ)償
TCC的實(shí)現(xiàn)依賴底層數(shù)據(jù)庫，異常后直接利用數(shù)據(jù)庫的事務(wù)機(jī)制回滾

其中現(xiàn)在使用比較多的TCC框架ByteTCC、tcc-transaction的原理都是基于第三點(diǎn)。

同時(shí)，在實(shí)現(xiàn)TCC時(shí)要注意以下三個(gè)問題：

允許空回滾，在Try沒有真正執(zhí)行的情況下，觸發(fā)了Cancel操作，這時(shí)要允許Cancel成功
防懸掛控制，Cancel操作比Try操作先執(zhí)行（網(wǎng)絡(luò)延遲原因），后面的Try操作不能執(zhí)行成功
冪等控制

TCC其實(shí)是把控制事務(wù)的邏輯放在業(yè)務(wù)應(yīng)用層面，而非資源管理器，這樣實(shí)現(xiàn)起來就會相對靈活很多，但相對對數(shù)據(jù)一致性的保證可能沒那么強(qiáng)（具體看怎么實(shí)現(xiàn)Try），整體來說TCC還有以下缺點(diǎn)：

對于Confirm和Cancel階段失敗后要完全靠業(yè)務(wù)應(yīng)用自己去處理
每個(gè)業(yè)務(wù)都需要實(shí)現(xiàn)Try、Confirm、Cancel三個(gè)接口，代碼量比較多
如果是基于現(xiàn)有的業(yè)務(wù)想使用TCC會比較困難。一是對于原來的接口要拆分為三個(gè)接口，入侵性比較大；二是因?yàn)橐觥邦A(yù)留”資源的操作，有可能需要對原來的業(yè)務(wù)模型進(jìn)行改造。

Saga

Saga事務(wù)模型又叫做長時(shí)間運(yùn)行的事務(wù)（Long-running-transaction）, 它是由普林斯頓大學(xué)的H.Garcia-Molina等人提出，它描述的是另外一種在沒有兩階段提交的的情況下解決分布式系統(tǒng)中復(fù)雜的業(yè)務(wù)事務(wù)問題。

該模型其核心思想就是拆分分布式系統(tǒng)中的長事務(wù)為多個(gè)短事務(wù)，或者叫多個(gè)本地事務(wù)，然后由 Saga工作流引擎負(fù)責(zé)協(xié)調(diào)，如果整個(gè)流程正常結(jié)束，那么就算是業(yè)務(wù)成功完成，如果在這過程中實(shí)現(xiàn)失敗，那么Saga工作流引擎就會以相反的順序調(diào)用補(bǔ)償操作，重新進(jìn)行業(yè)務(wù)回滾。

Saga也是一種補(bǔ)償協(xié)議，在 Saga 模式下，分布式事務(wù)內(nèi)有多個(gè)參與者，每一個(gè)參與者都是一個(gè)沖正補(bǔ)償服務(wù)，需要用戶根據(jù)業(yè)務(wù)場景實(shí)現(xiàn)其正向操作和逆向回滾操作。

你可以看到Saga跟TCC很像，但是Saga更加寬松，一致性更弱，在Saga看來，在一階段直接做提交/確認(rèn)操作就好了，有問題再做補(bǔ)償。這樣的話，Saga可以擁有比XA和TCC更好的性能（XA、TCC需要鎖定資源或預(yù)留資源），而且Saga強(qiáng)調(diào)通過事件驅(qū)動異步處理，實(shí)現(xiàn)高吞吐。

可以看出Saga是對TCC的一種“妥協(xié)”，從TCC的三個(gè)接口變?yōu)閮蓚€(gè)接口，一階段直接提交缺少對資源的隔離（如果一階段提交后，后面發(fā)現(xiàn)需要做補(bǔ)償，但是補(bǔ)償操作執(zhí)行前有另外的事務(wù)更改了數(shù)據(jù)，這時(shí)數(shù)據(jù)已經(jīng)變“臟”了，那么這時(shí)該如何處理是一個(gè)問題。在TCC沒有這個(gè)問題，因?yàn)橘Y源已經(jīng)被hold住了），因此對使用者也是比較寬松的，對于現(xiàn)有業(yè)務(wù)的改造也會比較簡單。

Saga實(shí)現(xiàn)分兩種，一種是Saga狀態(tài)機(jī)實(shí)現(xiàn)，一種是Saga AOP Proxy實(shí)現(xiàn)。Saga狀態(tài)機(jī)實(shí)現(xiàn)，在關(guān)于參與者服務(wù)編排實(shí)現(xiàn)又有集中式和協(xié)同式兩種分支。這點(diǎn)就不展開了。

TCC vs Saga

TCC和Saga都屬于補(bǔ)償型事務(wù)模型，Saga沒有Try，直接Commit，所有會產(chǎn)生實(shí)際的事務(wù)痕跡，而補(bǔ)償做的是反向操作。TCC是二階段的廣義實(shí)現(xiàn)，利用了數(shù)據(jù)的中間態(tài)，Cancel是中間狀態(tài)的數(shù)據(jù)進(jìn)行撤銷，從而不存在數(shù)據(jù)污染問題。

使用場景對比：

TCC適用于執(zhí)行時(shí)間確定且較短、對一致性要求比較高、數(shù)據(jù)隔離強(qiáng)的業(yè)務(wù)
Saga適用于業(yè)務(wù)流程長、業(yè)務(wù)流程多的業(yè)務(wù)，在銀行業(yè)金融機(jī)構(gòu)使用廣泛
TCC對現(xiàn)有業(yè)務(wù)改造較大，Saga則相對少點(diǎn)

Seata

Seata是一個(gè)由阿里做背書的分布式事務(wù)框架，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)。Seata將為用戶提供了AT、TCC、SAGA和XA事務(wù)模式，為用戶打造一站式的分布式解決方案。

AT模式

AT模式是Seata通過攔截、解釋用戶的SQL，對業(yè)務(wù)數(shù)據(jù)進(jìn)行加鎖、回滾等操作的基于二階段協(xié)議的一個(gè)實(shí)現(xiàn)。

它的特點(diǎn)是對業(yè)務(wù)無入侵，用戶只需關(guān)注自己的“業(yè)務(wù)SQL”，用戶的“業(yè)務(wù) SQL”作為一階段，Seata框架會自動生成事務(wù)的二階段提交和回滾操作。

在一階段，Seata會攔截“業(yè)務(wù)SQL”，首先解析SQL語義，找到“業(yè)務(wù)SQL”要更新的業(yè)務(wù)數(shù)據(jù)，在業(yè)務(wù)數(shù)據(jù)被更新前，將其保存成“before image”，然后執(zhí)行“業(yè)務(wù)SQL”更新業(yè)務(wù)數(shù)據(jù)，在業(yè)務(wù)數(shù)據(jù)更新之后，再將其保存成“after image”，最后生成行鎖。以上操作全部在一個(gè)數(shù)據(jù)庫事務(wù)內(nèi)完成，這樣保證了一階段操作的原子性。

二階段如果是提交的話，因?yàn)椤皹I(yè)務(wù)SQL”在一階段已經(jīng)提交至數(shù)據(jù)庫，所以Seata框架只需將一階段保存的快照數(shù)據(jù)和行鎖刪掉，完成數(shù)據(jù)清理即可。

TCC模式

Seata的TCC模式跟上面講的TCC事務(wù)模型差不多。

Saga模式

Saga模式也是上面講的Saga事務(wù)模型差不多。在Seata中對服務(wù)的編排引入了狀態(tài)機(jī)引擎，使得對業(yè)務(wù)流程的定義更加標(biāo)準(zhǔn)化，提高可讀性，不過相對來說配置會比較復(fù)雜繁瑣。同時(shí)支持注解的方式，這個(gè)在開發(fā)上會簡單一點(diǎn)，但功能可能少一點(diǎn)。

分布式事務(wù)一致性與Paxos一致性的思考

首先要明確一點(diǎn)的就是對于上述提到的分布式事務(wù)解決方案，如TCC、Saga、本地消息表等，其本質(zhì)都是2PC。

Paxos算法解決的問題是一個(gè)分布式系統(tǒng)如何就某個(gè)值（決議）達(dá)成一致。

咋看起來2PC和Paxos都是解決關(guān)于“一致性”的問題，其實(shí)細(xì)想它們解決的問題不在一個(gè)層面。

2PC要求分布式系統(tǒng)中的每個(gè)節(jié)點(diǎn)要不全部成功，要不全部失敗，強(qiáng)調(diào)的是原子性。

Paxos要求多個(gè)副本之間的數(shù)據(jù)一致性，其實(shí)這里用“一致性”并不準(zhǔn)確，應(yīng)該用“共識（Consensus）”才對。

例如2PC中的協(xié)調(diào)者單點(diǎn)的問題可以用Paxos算法通過選舉出新的協(xié)調(diào)者來解決。

總結(jié)

總得看來，分布式事務(wù)的解決方案都很難做到有高一致性的同時(shí)，也有高性能，同時(shí)在實(shí)現(xiàn)上也有一定的難度。在業(yè)務(wù)允許的情況下，我們通常處理分布式事務(wù)的一般原則應(yīng)是：業(yè)務(wù)規(guī)避 > 最終一致 > 強(qiáng)一致。

原文鏈接：https://albenw.github.io/posts/425b6837/
文章轉(zhuǎn)自：分布式實(shí)驗(yàn)室（版權(quán)歸原作者所有，侵刪）

聊一聊分布式事務(wù)