什么是分布式事務，以及有哪些解決方案？

作者：咔咔侃技術 2019-09-09 10:09:51
運維
數(shù)據(jù)庫運維
分布式 當數(shù)據(jù)庫單表數(shù)據(jù)達到千萬級別，就要考慮分庫分表，那么就會從原來的一個數(shù)據(jù)庫變成多個數(shù)據(jù)庫。例如如果一個操作即操作了01庫，又操作了02庫，而且又要保證數(shù)據(jù)的一致性，那么就要用到分布式事務。

成都創(chuàng)新互聯(lián)長期為數(shù)千家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為樂山企業(yè)提供專業(yè)的做網(wǎng)站、網(wǎng)站設計，樂山網(wǎng)站改版等技術服務。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

什么是分布式事務?

答：指一次大的操作由不同的小操作組成的，這些小的操作分布在不同的服務器上，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。從本質(zhì)上來說，分布式事務就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

分布式事務產(chǎn)生的原因?

1 數(shù)據(jù)庫分庫分表

當數(shù)據(jù)庫單表數(shù)據(jù)達到千萬級別，就要考慮分庫分表，那么就會從原來的一個數(shù)據(jù)庫變成多個數(shù)據(jù)庫。例如如果一個操作即操作了01庫，又操作了02庫，而且又要保證數(shù)據(jù)的一致性，那么就要用到分布式事務。

2 應用SOA化

所謂的SOA化，就是業(yè)務的服務化。例如電商平臺下單操作就會產(chǎn)生調(diào)用庫存服務扣減庫存和訂單服務更新訂單數(shù)據(jù)，那么就會設計到訂單數(shù)據(jù)庫和庫存數(shù)據(jù)庫，為了保證數(shù)據(jù)的一致性，就需要用到分布式事務。

總結：其實上面兩種場景，歸根到底是要操作多數(shù)據(jù)庫，并且要保證數(shù)據(jù)的一致性，而產(chǎn)生的分布式事務的。

分布式事務解決方案

1、兩階段提交(2PC)

XA是一個分布式事務協(xié)議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫實現(xiàn)，比如Oracle、Mysql等數(shù)據(jù)庫都實現(xiàn)了XA接口，而事務管理器作為全局的調(diào)度者，負責各個本地資源的提交回滾。

XA實現(xiàn)分布式事務的原理如下：

總結

二階段提交看起來確實能夠提供原子性的操作，但是它存在幾個缺點：

• 同步阻塞問題：執(zhí)行過程中，所有參與節(jié)點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節(jié)點訪問公共資源不得不處于阻塞狀態(tài)。
• 單點故障：由于(事務管理器)協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障。(本地資源管理器)參與者會一直阻塞下去。尤其在第二階段，協(xié)調(diào)者發(fā)生故障，那么所有的參與者還都處于鎖定事務資源的狀態(tài)中，而無法繼續(xù)完成事務操作。(如果是協(xié)調(diào)者掛掉，可以重新選舉一個協(xié)調(diào)者，但是無法解決因為協(xié)調(diào)者宕機導致的參與者處于阻塞狀態(tài)的問題)
• 數(shù)據(jù)不一致：在二階段提交的階段二中，當協(xié)調(diào)者向參與者發(fā)送commit請求之后，發(fā)生了局部網(wǎng)絡異常或者在發(fā)送commit請求過程中協(xié)調(diào)者發(fā)生了故障，這會導致只有一部分參與者接收到了commit請求。而在這部分參與者接到commit請求之后就會執(zhí)行commit操作。但是其他部分未接到commit請求的機器無法執(zhí)行事務提交。于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致的現(xiàn)象。
• 二階段無法解決的問題：參與者在發(fā)出commit消息之后宕機，而唯一接收到這條消息的協(xié)調(diào)者同時也宕機了。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者，這條事務的狀態(tài)也是不確定的，沒人知道事務是否被已經(jīng)提交了。

2、三階段提交(3PC)

3PC其實在2PC的基礎上增加了CanCommit階段，是2PC的變種，并引入了超時機制。一旦事務參與者遲遲沒有收到協(xié)調(diào)者的Commit請求，就會自動進行本地commit，這樣相對有效的解決了協(xié)調(diào)者單點故障的問題。但是，性能和數(shù)據(jù)一致性問題沒有根本解決。

3PC分為三個階段：CanCommit、PreCommit、DoCommit

CanCommit階段

它跟2PC的 準備階段很像，協(xié)調(diào)者向參與者發(fā)送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。

• 事務詢問：協(xié)調(diào)者向參與者發(fā)送CanCommit請求。詢問是否可以執(zhí)行事務提交操作。然后開始等待參與者的響應
• 響應反饋：參與者接到CanCommit請求之后，正常情況下，如果其自身認為可以順利執(zhí)行事務，則返回Yes響應，并進入預備狀態(tài)。否則返回No

PreCommit階段

協(xié)調(diào)者根據(jù)參與者的響應情況來決定是否可以進行事務的PreCommit操作。根據(jù)響應情況，有以下兩種可能：

• 假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes，那么就會執(zhí)行事務的與執(zhí)行。
• 發(fā)送預提交請求：協(xié)調(diào)者向參與者發(fā)送PreCommit請求，并進入Prepared階段。
• 事務預提交：參與者接收到PreCommit請求后，會執(zhí)行事務操作，并將undo和redo信息記錄到事務日志中。
• 響應反饋：如果參與者成功的執(zhí)行了事務操作，則返回ACK響應，同時開始等待最終指令。
• 假如有任何一個參與者向協(xié)調(diào)者發(fā)送了No響應，或者等待超時，或者協(xié)調(diào)者都沒有接到參與者的響應，那么就執(zhí)行事務的中斷。
• 發(fā)送中斷請求：協(xié)調(diào)者向所有參與者發(fā)送abort請求。
• 中斷事務：參與者收到來自協(xié)調(diào)者的abort請求之后(或超時之后，仍未收到協(xié)調(diào)者的請求)，執(zhí)行事務的中斷。

doCommit階段

該階段進行真正的事務提交，也可以分為以下兩種情況：

• 執(zhí)行提交
• 發(fā)送提交請求：協(xié)調(diào)接收到參與者發(fā)送的ACK響應，那么將從預提交狀態(tài)進入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請求。
• 事務提交：參與者接收到doCommit請求之后，執(zhí)行正式的事務提交，并在完成事務提交之后釋放所有事務資源。
• 響應反饋：事務提交完之后，向協(xié)調(diào)者發(fā)送ACK響應。
• 完成事務：協(xié)調(diào)者接收到所有參與者的ACK響應之后，完成事務。
• 中斷事務
• 協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(可能是接受者發(fā)送的不是ACK響應，也可能響應超時)，那么就會執(zhí)行中斷事務。
• 發(fā)送中斷請求：協(xié)調(diào)者向所有參與者發(fā)送abort請求
• 事務回滾：參與者接收到abort請求之后，利用其在階段二記錄的undo信息來執(zhí)行事務的回滾操作，并在完成回滾之后釋放所有的事務資源。
• 反饋結果：參與者完成事務回滾之后，像協(xié)調(diào)者發(fā)送ACK消息。
• 中斷事務：協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務的中斷。

原理圖如下：

總結

相對于2PC而言，3PC對于協(xié)調(diào)者和參與者都設置了超時時間，而2PC只有協(xié)調(diào)者才擁有超時時間機制。這個優(yōu)化解決了，參與者在長時間無法與協(xié)調(diào)者節(jié)點通訊的情況下，無法釋放資源的問題，因為參與者自身擁有超時機制會在超時后，自動進行本地commit從而進行釋放資源。而這種機制也側面降低了整個事務的阻塞時間和范圍。但是仍然沒有解決數(shù)據(jù)一致性問題，即在參與者收到PreCommit請求后等待最終指令，如果此時協(xié)調(diào)者無法與參與者正常通信，會導致參與者繼續(xù)提交事務，造成數(shù)據(jù)不一致。

3、補償事務(TCC)

TCC(Try-Confirm-Cancel)又稱補償事務。它實際上與2PC、3PC一樣，都是分布式事務的一種實現(xiàn)方案而已。它分為三個操作：

• Try階段：主要是對業(yè)務系統(tǒng)做檢測及資源預留。
• Confirm階段：確認執(zhí)行業(yè)務操作。
• Cancel階段：取消執(zhí)行業(yè)務操作。

TCC事務的處理流程與2PC兩階段提交類似，不過2PC通常都是在DB層面，而TCC本質(zhì)上就是應用層面的2PC，需要通過業(yè)務邏輯來實現(xiàn)。它的優(yōu)勢在于，可以讓應用自己定義數(shù)據(jù)庫操作的粒度，使得降低鎖沖突、提交吞吐量。

不過對應用的侵入性非常強，業(yè)務邏輯的每個分支都需要實現(xiàn)try、confirm、cancel三個操作。

TCC原理圖如下：

4、消息事務+最終一致性

所謂的消息事務就是基于消息中間件的兩階段提交，本質(zhì)上是中間件的一種特殊利用，他是將本地事務和發(fā)消息放在一個分布式事務里，保證要么本地操作成功并且對外發(fā)消息成功，要么兩者都失敗，開源的RocketMQ就支持這一特性，具體原理如下：

步驟如下：

1. 服務A向消息中間件發(fā)送一條預備消息。
2. 消息中間件保存預備消息并返回成功。
3. 服務A執(zhí)行本地事務。
4. 服務A發(fā)送提交消息給消息中間件，服務B接收到消息之后執(zhí)行本地事務。

基于消息中間件的兩階段提交往往用在高并發(fā)場景下，將一個分布式事務拆成一個消息事務(服務A的本地操作+發(fā)消息)+服務B的本地操作，其中服務B的操作由消息驅(qū)動，只要消息事務成功，那么服務A一定成功，消息也一定發(fā)出來了，這時候服務B會收到消息去執(zhí)行本地操作，如果本地操作失敗，消息會重投，直到服務B操作成功，這樣就變相地實現(xiàn)了A與B的分布式事務。

以上幾個步驟可能存在異常情況，現(xiàn)在對其進行分析：

• 步驟一出錯：則整個事務失敗，不會執(zhí)行服務A的本地操作。
• 步驟二出錯：則整個事務失敗，不會執(zhí)行服務A的本地操作。
• 步驟三出錯：需要做回滾預備消息，由服務A實現(xiàn)一個消息中間件的回調(diào)接口，消息中間件會不斷執(zhí)行回調(diào)接口，檢查服務A事務執(zhí)行是否執(zhí)行成功，如果失敗則回滾預備消息。
• 步驟四出錯：這個時候服務A的本地事務是成功的，但是消息中間件不需要回滾，其實通過回調(diào)接口，消息中間件能夠檢查到服務A執(zhí)行成功了，這個時候其實不需要服務發(fā)提交消息了，消息中間件可以自己對消息進行提交，從而完成整個消息事務。

當前題目：什么是分布式事務，以及有哪些解決方案？
分享路徑：http://uogjgqi.cn/article/dpjcosd.html