前言

眾所周知，數(shù)據(jù)庫(kù)能實(shí)現(xiàn)本地事務(wù)产上，也就是在同一個(gè)數(shù)據(jù)庫(kù)中棵磷，你可以允許一組操作要么全都正確執(zhí)行，要么全都不執(zhí)行蒂秘。這里特別強(qiáng)調(diào)了本地事務(wù)泽本，也就是目前的數(shù)據(jù)庫(kù)只能支持同一個(gè)數(shù)據(jù)庫(kù)中的事務(wù)。但現(xiàn)在的系統(tǒng)往往采用微服務(wù)架構(gòu)姻僧，業(yè)務(wù)系統(tǒng)擁有獨(dú)立的數(shù)據(jù)庫(kù)，因此就出現(xiàn)了跨多個(gè)數(shù)據(jù)庫(kù)的事務(wù)需求蒲牧，這種事務(wù)即為“分布式事務(wù)”撇贺。那么在目前數(shù)據(jù)庫(kù)不支持跨庫(kù)事務(wù)的情況下，我們?cè)撊绾螌?shí)現(xiàn)分布式事務(wù)呢冰抢？本文首先會(huì)為大家梳理分布式事務(wù)的基本概念和理論基礎(chǔ)松嘶，然后介紹幾種目前常用的分布式事務(wù)解決方案。

什么是事務(wù)呢挎扰？

事務(wù)由一組操作構(gòu)成翠订，我們希望這組操作能夠全部正確執(zhí)行巢音，如果這一組操作中的任意一個(gè)步驟發(fā)生錯(cuò)誤，那么就需要回滾之前已經(jīng)完成的操作尽超。也就是同一個(gè)事務(wù)中的所有操作官撼，要么全都正確執(zhí)行，要么全都不要執(zhí)行似谁。

事務(wù)的四大特性 ACID

說到事務(wù)傲绣，就得提到事務(wù)著名的四大特性。

原子性? 原子性要求巩踏，事務(wù)是一個(gè)不可分割的執(zhí)行單元秃诵，事務(wù)中的所有操作要么全都執(zhí)行，要么全都不執(zhí)行塞琼。

一致性? 一致性要求菠净，事務(wù)在開始前和結(jié)束后，數(shù)據(jù)庫(kù)的完整性約束沒有被破壞彪杉。

隔離性? 事務(wù)的執(zhí)行是相互獨(dú)立的毅往，它們不會(huì)相互干擾，一個(gè)事務(wù)不會(huì)看到另一個(gè)正在運(yùn)行過程中的事務(wù)的數(shù)據(jù)在讶。

持久性? 持久性要求煞抬，一個(gè)事務(wù)完成之后，事務(wù)的執(zhí)行結(jié)果必須是持久化保存的构哺。即使數(shù)據(jù)庫(kù)發(fā)生崩潰革答，在數(shù)據(jù)庫(kù)恢復(fù)后事務(wù)提交的結(jié)果仍然不會(huì)丟失。

注意：事務(wù)只能保證數(shù)據(jù)庫(kù)的高可靠性曙强，即數(shù)據(jù)庫(kù)本身發(fā)生問題后残拐，事務(wù)提交后的數(shù)據(jù)仍然能恢復(fù)；而如果不是數(shù)據(jù)庫(kù)本身的故障碟嘴，如硬盤損壞了溪食，那么事務(wù)提交的數(shù)據(jù)可能就丟失了。這屬于『高可用性』的范疇娜扇。因此错沃，事務(wù)只能保證數(shù)據(jù)庫(kù)的『高可靠性』，而『高可用性』需要整個(gè)系統(tǒng)共同配合實(shí)現(xiàn)雀瓢。

事務(wù)的隔離級(jí)別

這里擴(kuò)展一下枢析，對(duì)事務(wù)的隔離性做一個(gè)詳細(xì)的解釋。

在事務(wù)的四大特性ACID中刃麸，要求的隔離性是一種嚴(yán)格意義上的隔離醒叁，也就是多個(gè)事務(wù)是串行執(zhí)行的，彼此之間不會(huì)受到任何干擾。這確實(shí)能夠完全保證數(shù)據(jù)的安全性把沼，但在實(shí)際業(yè)務(wù)系統(tǒng)中啊易，這種方式性能不高。因此饮睬，數(shù)據(jù)庫(kù)定義了四種隔離級(jí)別租谈，隔離級(jí)別和數(shù)據(jù)庫(kù)的性能是呈反比的，隔離級(jí)別越低续捂，數(shù)據(jù)庫(kù)性能越高垦垂，而隔離級(jí)別越高，數(shù)據(jù)庫(kù)性能越差牙瓢。

事務(wù)并發(fā)執(zhí)行會(huì)出現(xiàn)的問題

我們先來看一下在不同的隔離級(jí)別下劫拗，數(shù)據(jù)庫(kù)可能會(huì)出現(xiàn)的問題：

更新丟失? 當(dāng)有兩個(gè)并發(fā)執(zhí)行的事務(wù)，更新同一行數(shù)據(jù)矾克，那么有可能一個(gè)事務(wù)會(huì)把另一個(gè)事務(wù)的更新覆蓋掉页慷。? 當(dāng)數(shù)據(jù)庫(kù)沒有加任何鎖操作的情況下會(huì)發(fā)生。

臟讀? 一個(gè)事務(wù)讀到另一個(gè)尚未提交的事務(wù)中的數(shù)據(jù)胁附。? 該數(shù)據(jù)可能會(huì)被回滾從而失效酒繁。? 如果第一個(gè)事務(wù)拿著失效的數(shù)據(jù)去處理那就發(fā)生錯(cuò)誤了。

不可重復(fù)讀? 不可重復(fù)度的含義：一個(gè)事務(wù)對(duì)同一行數(shù)據(jù)讀了兩次控妻，卻得到了不同的結(jié)果州袒。它具體分為如下兩種情況：

虛讀：在事務(wù)1兩次讀取同一記錄的過程中，事務(wù)2對(duì)該記錄進(jìn)行了修改弓候，從而事務(wù)1第二次讀到了不一樣的記錄郎哭。

幻讀：事務(wù)1在兩次查詢的過程中，事務(wù)2對(duì)該表進(jìn)行了插入菇存、刪除操作夸研，從而事務(wù)1第二次查詢的結(jié)果發(fā)生了變化。

不可重復(fù)讀 與 臟讀 的區(qū)別依鸥？? 臟讀讀到的是尚未提交的數(shù)據(jù)亥至，而不可重復(fù)讀讀到的是已經(jīng)提交的數(shù)據(jù)，只不過在兩次讀的過程中數(shù)據(jù)被另一個(gè)事務(wù)改過了贱迟。

數(shù)據(jù)庫(kù)的四種隔離級(jí)別

數(shù)據(jù)庫(kù)一共有如下四種隔離級(jí)別：

Read uncommitted 讀未提交? 在該級(jí)別下姐扮，一個(gè)事務(wù)對(duì)一行數(shù)據(jù)修改的過程中，不允許另一個(gè)事務(wù)對(duì)該行數(shù)據(jù)進(jìn)行修改衣吠，但允許另一個(gè)事務(wù)對(duì)該行數(shù)據(jù)讀溶握。? 因此本級(jí)別下，不會(huì)出現(xiàn)更新丟失蒸播，但會(huì)出現(xiàn)臟讀、不可重復(fù)讀。

Read committed 讀提交? 在該級(jí)別下袍榆，未提交的寫事務(wù)不允許其他事務(wù)訪問該行胀屿，因此不會(huì)出現(xiàn)臟讀；但是讀取數(shù)據(jù)的事務(wù)允許其他事務(wù)的訪問該行數(shù)據(jù)包雀，因此會(huì)出現(xiàn)不可重復(fù)讀的情況宿崭。

Repeatable read 重復(fù)讀? 在該級(jí)別下，讀事務(wù)禁止寫事務(wù)才写，但允許讀事務(wù)葡兑，因此不會(huì)出現(xiàn)同一事務(wù)兩次讀到不同的數(shù)據(jù)的情況（不可重復(fù)讀），且寫事務(wù)禁止其他一切事務(wù)赞草。

Serializable 序列化? 該級(jí)別要求所有事務(wù)都必須串行執(zhí)行讹堤，因此能避免一切因并發(fā)引起的問題，但效率很低厨疙。

隔離級(jí)別越高洲守，越能保證數(shù)據(jù)的完整性和一致性，但是對(duì)并發(fā)性能的影響也越大沾凄。對(duì)于多數(shù)應(yīng)用程序梗醇，可以優(yōu)先考慮把數(shù)據(jù)庫(kù)系統(tǒng)的隔離級(jí)別設(shè)為Read Committed。它能夠避免臟讀取撒蟀，而且具有較好的并發(fā)性能叙谨。盡管它會(huì)導(dǎo)致不可重復(fù)讀、幻讀和第二類丟失更新這些并發(fā)問題保屯，在可能出現(xiàn)這類問題的個(gè)別場(chǎng)合手负，可以由應(yīng)用程序采用悲觀鎖或樂觀鎖來控制。

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

到此為止虫溜，所介紹的事務(wù)都是基于單數(shù)據(jù)庫(kù)的本地事務(wù)，目前的數(shù)據(jù)庫(kù)僅支持單庫(kù)事務(wù)股缸，并不支持跨庫(kù)事務(wù)衡楞。而隨著微服務(wù)架構(gòu)的普及，一個(gè)大型業(yè)務(wù)系統(tǒng)往往由若干個(gè)子系統(tǒng)構(gòu)成敦姻，這些子系統(tǒng)又擁有各自獨(dú)立的數(shù)據(jù)庫(kù)瘾境。往往一個(gè)業(yè)務(wù)流程需要由多個(gè)子系統(tǒng)共同完成，而且這些操作可能需要在一個(gè)事務(wù)中完成镰惦。在微服務(wù)系統(tǒng)中迷守，這些業(yè)務(wù)場(chǎng)景是普遍存在的。此時(shí)旺入，我們就需要在數(shù)據(jù)庫(kù)之上通過某種手段兑凿，實(shí)現(xiàn)支持跨數(shù)據(jù)庫(kù)的事務(wù)支持凯力，這也就是大家常說的“分布式事務(wù)”。

這里舉一個(gè)分布式事務(wù)的典型例子——用戶下單過程礼华。? 當(dāng)我們的系統(tǒng)采用了微服務(wù)架構(gòu)后咐鹤，一個(gè)電商系統(tǒng)往往被拆分成如下幾個(gè)子系統(tǒng)：商品系統(tǒng)、訂單系統(tǒng)圣絮、支付系統(tǒng)祈惶、積分系統(tǒng)等。整個(gè)下單的過程如下：

用戶通過商品系統(tǒng)瀏覽商品扮匠，他看中了某一項(xiàng)商品捧请，便點(diǎn)擊下單

此時(shí)訂單系統(tǒng)會(huì)生成一條訂單

訂單創(chuàng)建成功后，支付系統(tǒng)提供支付功能

當(dāng)支付完成后棒搜，由積分系統(tǒng)為該用戶增加積分

上述步驟2疹蛉、3、4需要在一個(gè)事務(wù)中完成帮非。對(duì)于傳統(tǒng)單體應(yīng)用而言氧吐，實(shí)現(xiàn)事務(wù)非常簡(jiǎn)單，只需將這三個(gè)步驟放在一個(gè)方法A中末盔，再用Spring的@Transactional注解標(biāo)識(shí)該方法即可筑舅。Spring通過數(shù)據(jù)庫(kù)的事務(wù)支持，保證這些步驟要么全都執(zhí)行完成陨舱，要么全都不執(zhí)行翠拣。但在這個(gè)微服務(wù)架構(gòu)中，這三個(gè)步驟涉及三個(gè)系統(tǒng)游盲，涉及三個(gè)數(shù)據(jù)庫(kù)误墓，此時(shí)我們必須在數(shù)據(jù)庫(kù)和應(yīng)用系統(tǒng)之間，通過某項(xiàng)黑科技益缎，實(shí)現(xiàn)分布式事務(wù)的支持谜慌。

CAP理論

CAP理論說的是：在一個(gè)分布式系統(tǒng)中，最多只能滿足C莺奔、A欣范、P中的兩個(gè)需求。

CAP的含義：

C：Consistency 一致性? 同一數(shù)據(jù)的多個(gè)副本是否實(shí)時(shí)相同令哟。

A：Availability 可用性? 可用性：一定時(shí)間內(nèi) & 系統(tǒng)返回一個(gè)明確的結(jié)果 則稱為該系統(tǒng)可用恼琼。

P：Partition tolerance 分區(qū)容錯(cuò)性? 將同一服務(wù)分布在多個(gè)系統(tǒng)中，從而保證某一個(gè)系統(tǒng)宕機(jī)屏富，仍然有其他系統(tǒng)提供相同的服務(wù)晴竞。

CAP理論告訴我們，在分布式系統(tǒng)中狠半，C噩死、A颤难、P三個(gè)條件中我們最多只能選擇兩個(gè)。那么問題來了甜滨，究竟選擇哪兩個(gè)條件較為合適呢乐严？

對(duì)于一個(gè)業(yè)務(wù)系統(tǒng)來說，可用性和分區(qū)容錯(cuò)性是必須要滿足的兩個(gè)條件衣摩，并且這兩者是相輔相成的。業(yè)務(wù)系統(tǒng)之所以使用分布式系統(tǒng)捂敌，主要原因有兩個(gè)：

提升整體性能? 當(dāng)業(yè)務(wù)量猛增艾扮，單個(gè)服務(wù)器已經(jīng)無法滿足我們的業(yè)務(wù)需求的時(shí)候，就需要使用分布式系統(tǒng)占婉，使用多個(gè)節(jié)點(diǎn)提供相同的功能泡嘴，從而整體上提升系統(tǒng)的性能，這就是使用分布式系統(tǒng)的第一個(gè)原因逆济。

實(shí)現(xiàn)分區(qū)容錯(cuò)性? 單一節(jié)點(diǎn) 或 多個(gè)節(jié)點(diǎn)處于相同的網(wǎng)絡(luò)環(huán)境下酌予，那么會(huì)存在一定的風(fēng)險(xiǎn)，萬(wàn)一該機(jī)房斷電奖慌、該地區(qū)發(fā)生自然災(zāi)害抛虫，那么業(yè)務(wù)系統(tǒng)就全面癱瘓了。為了防止這一問題简僧，采用分布式系統(tǒng)建椰，將多個(gè)子系統(tǒng)分布在不同的地域、不同的機(jī)房中岛马，從而保證系統(tǒng)高可用性棉姐。

這說明分區(qū)容錯(cuò)性是分布式系統(tǒng)的根本，如果分區(qū)容錯(cuò)性不能滿足啦逆，那使用分布式系統(tǒng)將失去意義伞矩。

此外，可用性對(duì)業(yè)務(wù)系統(tǒng)也尤為重要夏志。在大談?dòng)脩趔w驗(yàn)的今天乃坤，如果業(yè)務(wù)系統(tǒng)時(shí)常出現(xiàn)“系統(tǒng)異常”盲镶、響應(yīng)時(shí)間過長(zhǎng)等情況侥袜，這使得用戶對(duì)系統(tǒng)的好感度大打折扣，在互聯(lián)網(wǎng)行業(yè)競(jìng)爭(zhēng)激烈的今天溉贿，相同領(lǐng)域的競(jìng)爭(zhēng)者不甚枚舉枫吧，系統(tǒng)的間歇性不可用會(huì)立馬導(dǎo)致用戶流向競(jìng)爭(zhēng)對(duì)手。因此宇色，我們只能通過犧牲一致性來?yè)Q取系統(tǒng)的可用性和分區(qū)容錯(cuò)性九杂。這也就是下面要介紹的BASE理論颁湖。

BASE理論

CAP理論告訴我們一個(gè)悲慘但不得不接受的事實(shí)——我們只能在C、A例隆、P中選擇兩個(gè)條件甥捺。而對(duì)于業(yè)務(wù)系統(tǒng)而言，我們往往選擇犧牲一致性來?yè)Q取系統(tǒng)的可用性和分區(qū)容錯(cuò)性镀层。不過這里要指出的是镰禾，所謂的“犧牲一致性”并不是完全放棄數(shù)據(jù)一致性，而是犧牲強(qiáng)一致性換取弱一致性唱逢。下面來介紹下BASE理論吴侦。

BA：Basic Available 基本可用

整個(gè)系統(tǒng)在某些不可抗力的情況下，仍然能夠保證“可用性”坞古，即一定時(shí)間內(nèi)仍然能夠返回一個(gè)明確的結(jié)果备韧。只不過“基本可用”和“高可用”的區(qū)別是：

“一定時(shí)間”可以適當(dāng)延長(zhǎng)? 當(dāng)舉行大促時(shí)，響應(yīng)時(shí)間可以適當(dāng)延長(zhǎng)

給部分用戶返回一個(gè)降級(jí)頁(yè)面? 給部分用戶直接返回一個(gè)降級(jí)頁(yè)面痪枫，從而緩解服務(wù)器壓力织堂。但要注意，返回降級(jí)頁(yè)面仍然是返回明確結(jié)果奶陈。

S：Soft State：柔性狀態(tài)? 同一數(shù)據(jù)的不同副本的狀態(tài)易阳，可以不需要實(shí)時(shí)一致。

E：Eventual Consisstency：最終一致性? 同一數(shù)據(jù)的不同副本的狀態(tài)尿瞭，可以不需要實(shí)時(shí)一致闽烙，但一定要保證經(jīng)過一定時(shí)間后仍然是一致的。

酸堿平衡

ACID能夠保證事務(wù)的強(qiáng)一致性声搁，即數(shù)據(jù)是實(shí)時(shí)一致的黑竞。這在本地事務(wù)中是沒有問題的，在分布式事務(wù)中疏旨，強(qiáng)一致性會(huì)極大影響分布式系統(tǒng)的性能很魂，因此分布式系統(tǒng)中遵循BASE理論即可。但分布式系統(tǒng)的不同業(yè)務(wù)場(chǎng)景對(duì)一致性的要求也不同檐涝。如交易場(chǎng)景下遏匆，就要求強(qiáng)一致性，此時(shí)就需要遵循ACID理論谁榜，而在注冊(cè)成功后發(fā)送短信驗(yàn)證碼等場(chǎng)景下幅聘，并不需要實(shí)時(shí)一致，因此遵循BASE理論即可窃植。因此要根據(jù)具體業(yè)務(wù)場(chǎng)景帝蒿，在ACID和BASE之間尋求平衡。

分布式事務(wù)協(xié)議

下面介紹幾種實(shí)現(xiàn)分布式事務(wù)的協(xié)議巷怜。

兩階段提交協(xié)議 2PC

分布式系統(tǒng)的一個(gè)難點(diǎn)是如何保證架構(gòu)下多個(gè)節(jié)點(diǎn)在進(jìn)行事務(wù)性操作的時(shí)候保持一致性葛超。為實(shí)現(xiàn)這個(gè)目的暴氏，二階段提交算法的成立基于以下假設(shè)：

該分布式系統(tǒng)中，存在一個(gè)節(jié)點(diǎn)作為協(xié)調(diào)者(Coordinator)绣张，其他節(jié)點(diǎn)作為參與者(Cohorts)答渔。且節(jié)點(diǎn)之間可以進(jìn)行網(wǎng)絡(luò)通信。

所有節(jié)點(diǎn)都采用預(yù)寫式日志侥涵，且日志被寫入后即被保持在可靠的存儲(chǔ)設(shè)備上沼撕，即使節(jié)點(diǎn)損壞不會(huì)導(dǎo)致日志數(shù)據(jù)的消失做院。

所有節(jié)點(diǎn)不會(huì)永久性損壞，即使損壞后仍然可以恢復(fù)蟋字。

1. 第一階段（投票階段）：

協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)詢問是否可以執(zhí)行提交操作(vote)斩祭，并開始等待各參與者節(jié)點(diǎn)的響應(yīng)。

參與者節(jié)點(diǎn)執(zhí)行詢問發(fā)起為止的所有事務(wù)操作昏苏，并將Undo信息和Redo信息寫入日志。（注意：若成功這里其實(shí)每個(gè)參與者已經(jīng)執(zhí)行了事務(wù)操作）

各參與者節(jié)點(diǎn)響應(yīng)協(xié)調(diào)者節(jié)點(diǎn)發(fā)起的詢問。如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行成功招狸，則它返回一個(gè)”同意”消息；如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行失敗邻薯，則它返回一個(gè)”中止”消息裙戏。

2. 第二階段（提交執(zhí)行階段）：

當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為”同意”時(shí)：

協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”正式提交(commit)”的請(qǐng)求。

參與者節(jié)點(diǎn)正式完成操作厕诡，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源累榜。

參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”完成”消息。

協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”完成”消息后灵嫌，完成事務(wù)壹罚。

如果任一參與者節(jié)點(diǎn)在第一階段返回的響應(yīng)消息為”中止”，或者 協(xié)調(diào)者節(jié)點(diǎn)在第一階段的詢問超時(shí)之前無法獲取所有參與者節(jié)點(diǎn)的響應(yīng)消息時(shí)：

協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”回滾操作(rollback)”的請(qǐng)求寿羞。

參與者節(jié)點(diǎn)利用之前寫入的Undo信息執(zhí)行回滾猖凛，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源。

參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”回滾完成”消息绪穆。

協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”回滾完成”消息后辨泳，取消事務(wù)。

不管最后結(jié)果如何玖院，第二階段都會(huì)結(jié)束當(dāng)前事務(wù)菠红。

二階段提交看起來確實(shí)能夠提供原子性的操作，但是不幸的事难菌，二階段提交還是有幾個(gè)缺點(diǎn)的：

執(zhí)行過程中试溯，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的。當(dāng)參與者占有公共資源時(shí)扔傅，其他第三方節(jié)點(diǎn)訪問公共資源不得不處于阻塞狀態(tài)耍共。

參與者發(fā)生故障烫饼。協(xié)調(diào)者需要給每個(gè)參與者額外指定超時(shí)機(jī)制，超時(shí)后整個(gè)事務(wù)失敗试读。（沒有多少容錯(cuò)機(jī)制）

協(xié)調(diào)者發(fā)生故障杠纵。參與者會(huì)一直阻塞下去。需要額外的備機(jī)進(jìn)行容錯(cuò)钩骇。（這個(gè)可以依賴后面要講的Paxos協(xié)議實(shí)現(xiàn)HA）

二階段無法解決的問題：協(xié)調(diào)者再發(fā)出commit消息之后宕機(jī)比藻，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者倘屹，這條事務(wù)的狀態(tài)也是不確定的银亲，沒人知道事務(wù)是否被已經(jīng)提交。

為此纽匙，Dale Skeen和Michael Stonebraker在“A Formal Model of Crash Recovery in a Distributed System”中提出了三階段提交協(xié)議（3PC）务蝠。

三階段提交協(xié)議 3PC

與兩階段提交不同的是，三階段提交有兩個(gè)改動(dòng)點(diǎn)烛缔。

引入超時(shí)機(jī)制馏段。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。

在第一階段和第二階段中插入一個(gè)準(zhǔn)備階段践瓷。保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的院喜。

也就是說，除了引入超時(shí)機(jī)制之外晕翠，3PC把2PC的準(zhǔn)備階段再次一分為二喷舀，這樣三階段提交就有CanCommit、PreCommit淋肾、DoCommit三個(gè)階段硫麻。

1. CanCommit階段

3PC的CanCommit階段其實(shí)和2PC的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求巫员，參與者如果可以提交就返回Yes響應(yīng)庶香，否則返回No響應(yīng)。

事務(wù)詢問? 協(xié)調(diào)者向參與者發(fā)送CanCommit請(qǐng)求简识。詢問是否可以執(zhí)行事務(wù)提交操作赶掖。然后開始等待參與者的響應(yīng)。

響應(yīng)反饋? 參與者接到CanCommit請(qǐng)求之后七扰，正常情況下奢赂，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)颈走，并進(jìn)入預(yù)備狀態(tài)膳灶。否則反饋No

2. PreCommit階段

協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以記性事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況，有以下兩種可能轧钓。? 假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)序厉，那么就會(huì)執(zhí)行事務(wù)的預(yù)執(zhí)行。

發(fā)送預(yù)提交請(qǐng)求? 協(xié)調(diào)者向參與者發(fā)送PreCommit請(qǐng)求毕箍，并進(jìn)入Prepared階段弛房。

事務(wù)預(yù)提交? 參與者接收到PreCommit請(qǐng)求后，會(huì)執(zhí)行事務(wù)操作而柑，并將undo和redo信息記錄到事務(wù)日志中文捶。

響應(yīng)反饋? 如果參與者成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)媒咳，同時(shí)開始等待最終指令粹排。

假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時(shí)之后涩澡，協(xié)調(diào)者都沒有接到參與者的響應(yīng)顽耳，那么就執(zhí)行事務(wù)的中斷。

發(fā)送中斷請(qǐng)求? 協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求妙同。

中斷事務(wù)? 參與者收到來自協(xié)調(diào)者的abort請(qǐng)求之后（或超時(shí)之后斧抱，仍未收到協(xié)調(diào)者的請(qǐng)求），執(zhí)行事務(wù)的中斷渐溶。

3. doCommit階段該階段進(jìn)行真正的事務(wù)提交，也可以分為以下兩種情況弄抬。

該階段進(jìn)行真正的事務(wù)提交茎辐，也可以分為以下兩種情況。

3.1 執(zhí)行提交

發(fā)送提交請(qǐng)求? 協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)掂恕，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)拖陆。并向所有參與者發(fā)送doCommit請(qǐng)求。

事務(wù)提交? 參與者接收到doCommit請(qǐng)求之后懊亡，執(zhí)行正式的事務(wù)提交依啰。并在完成事務(wù)提交之后釋放所有事務(wù)資源。

響應(yīng)反饋? 事務(wù)提交完之后店枣，向協(xié)調(diào)者發(fā)送Ack響應(yīng)速警。

完成事務(wù)? 協(xié)調(diào)者接收到所有參與者的ack響應(yīng)之后，完成事務(wù)鸯两。

3.2 中斷事務(wù)協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)（可能是接受者發(fā)送的不是ACK響應(yīng)闷旧，也可能響應(yīng)超時(shí)），那么就會(huì)執(zhí)行中斷事務(wù)钧唐。

發(fā)送中斷請(qǐng)求? 協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求

事務(wù)回滾? 參與者接收到abort請(qǐng)求之后忙灼，利用其在階段二記錄的undo信息來執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源。

反饋結(jié)果? 參與者完成事務(wù)回滾之后该园，向協(xié)調(diào)者發(fā)送ACK消息

中斷事務(wù)? 協(xié)調(diào)者接收到參與者反饋的ACK消息之后酸舍，執(zhí)行事務(wù)的中斷。

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

分布式事務(wù)的解決方案有如下幾種：

全局消息

基于可靠消息服務(wù)的分布式事務(wù)

TCC

最大努力通知

方案1：全局事務(wù)（DTP模型）

全局事務(wù)基于DTP模型實(shí)現(xiàn)里初。DTP是由X/Open組織提出的一種分布式事務(wù)模型——X/Open Distributed Transaction Processing Reference Model啃勉。它規(guī)定了要實(shí)現(xiàn)分布式事務(wù)，需要三種角色：

AP：Application 應(yīng)用系統(tǒng)? 它就是我們開發(fā)的業(yè)務(wù)系統(tǒng)青瀑，在我們開發(fā)的過程中璧亮，可以使用資源管理器提供的事務(wù)接口來實(shí)現(xiàn)分布式事務(wù)。

TM：Transaction Manager 事務(wù)管理器

分布式事務(wù)的實(shí)現(xiàn)由事務(wù)管理器來完成斥难，它會(huì)提供分布式事務(wù)的操作接口供我們的業(yè)務(wù)系統(tǒng)調(diào)用枝嘶。這些接口稱為TX接口。

事務(wù)管理器還管理著所有的資源管理器哑诊，通過它們提供的XA接口來同一調(diào)度這些資源管理器群扶，以實(shí)現(xiàn)分布式事務(wù)。

DTP只是一套實(shí)現(xiàn)分布式事務(wù)的規(guī)范镀裤，并沒有定義具體如何實(shí)現(xiàn)分布式事務(wù)竞阐，TM可以采用2PC、3PC暑劝、Paxos等協(xié)議實(shí)現(xiàn)分布式事務(wù)骆莹。

RM：Resource Manager 資源管理器

能夠提供數(shù)據(jù)服務(wù)的對(duì)象都可以是資源管理器，比如：數(shù)據(jù)庫(kù)担猛、消息中間件幕垦、緩存等。大部分場(chǎng)景下傅联，數(shù)據(jù)庫(kù)即為分布式事務(wù)中的資源管理器先改。

資源管理器能夠提供單數(shù)據(jù)庫(kù)的事務(wù)能力，它們通過XA接口蒸走，將本數(shù)據(jù)庫(kù)的提交仇奶、回滾等能力提供給事務(wù)管理器調(diào)用，以幫助事務(wù)管理器實(shí)現(xiàn)分布式的事務(wù)管理比驻。

XA是DTP模型定義的接口该溯，用于向事務(wù)管理器提供該資源管理器(該數(shù)據(jù)庫(kù))的提交、回滾等能力嫁艇。

DTP只是一套實(shí)現(xiàn)分布式事務(wù)的規(guī)范朗伶，RM具體的實(shí)現(xiàn)是由數(shù)據(jù)庫(kù)廠商來完成的。

有沒有基于DTP模型的分布式事務(wù)中間件步咪？

DTP模型有啥優(yōu)缺點(diǎn)论皆？

方案2：基于可靠消息服務(wù)的分布式事務(wù)

這種實(shí)現(xiàn)分布式事務(wù)的方式需要通過消息中間件來實(shí)現(xiàn)。假設(shè)有A和B兩個(gè)系統(tǒng)，分別可以處理任務(wù)A和任務(wù)B点晴。此時(shí)系統(tǒng)A中存在一個(gè)業(yè)務(wù)流程感凤，需要將任務(wù)A和任務(wù)B在同一個(gè)事務(wù)中處理。下面來介紹基于消息中間件來實(shí)現(xiàn)這種分布式事務(wù)粒督。

在系統(tǒng)A處理任務(wù)A前陪竿，首先向消息中間件發(fā)送一條消息

消息中間件收到后將該條消息持久化，但并不投遞屠橄。此時(shí)下游系統(tǒng)B仍然不知道該條消息的存在族跛。

消息中間件持久化成功后，便向系統(tǒng)A返回一個(gè)確認(rèn)應(yīng)答锐墙；

系統(tǒng)A收到確認(rèn)應(yīng)答后礁哄，則可以開始處理任務(wù)A；

任務(wù)A處理完成后溪北，向消息中間件發(fā)送Commit請(qǐng)求桐绒。該請(qǐng)求發(fā)送完成后，對(duì)系統(tǒng)A而言之拨，該事務(wù)的處理過程就結(jié)束了茉继，此時(shí)它可以處理別的任務(wù)了。? 但commit消息可能會(huì)在傳輸途中丟失蚀乔，從而消息中間件并不會(huì)向系統(tǒng)B投遞這條消息烁竭，從而系統(tǒng)就會(huì)出現(xiàn)不一致性。這個(gè)問題由消息中間件的事務(wù)回查機(jī)制完成吉挣，下文會(huì)介紹颖变。

消息中間件收到Commit指令后，便向系統(tǒng)B投遞該消息听想，從而觸發(fā)任務(wù)B的執(zhí)行；

當(dāng)任務(wù)B執(zhí)行完成后马胧，系統(tǒng)B向消息中間件返回一個(gè)確認(rèn)應(yīng)答汉买，告訴消息中間件該消息已經(jīng)成功消費(fèi)，此時(shí)佩脊，這個(gè)分布式事務(wù)完成蛙粘。

上述過程可以得出如下幾個(gè)結(jié)論：? 1. 消息中間件扮演者分布式事務(wù)協(xié)調(diào)者的角色。? 2. 系統(tǒng)A完成任務(wù)A后威彰，到任務(wù)B執(zhí)行完成之間出牧，會(huì)存在一定的時(shí)間差。在這個(gè)時(shí)間差內(nèi)歇盼，整個(gè)系統(tǒng)處于數(shù)據(jù)不一致的狀態(tài)舔痕，但這短暫的不一致性是可以接受的，因?yàn)榻?jīng)過短暫的時(shí)間后，系統(tǒng)又可以保持?jǐn)?shù)據(jù)一致性伯复，滿足BASE理論慨代。

上述過程中，如果任務(wù)A處理失敗啸如，那么需要進(jìn)入回滾流程侍匙，如下圖所示：

若系統(tǒng)A在處理任務(wù)A時(shí)失敗，那么就會(huì)向消息中間件發(fā)送Rollback請(qǐng)求叮雳。和發(fā)送Commit請(qǐng)求一樣想暗，系統(tǒng)A發(fā)完之后便可以認(rèn)為回滾已經(jīng)完成，它便可以去做其他的事情帘不。

消息中間件收到回滾請(qǐng)求后说莫，直接將該消息丟棄，而不投遞給系統(tǒng)B厌均，從而不會(huì)觸發(fā)系統(tǒng)B的任務(wù)B唬滑。

此時(shí)系統(tǒng)又處于一致性狀態(tài)，因?yàn)槿蝿?wù)A和任務(wù)B都沒有執(zhí)行棺弊。

上面所介紹的Commit和Rollback都屬于理想情況晶密，但在實(shí)際系統(tǒng)中，Commit和Rollback指令都有可能在傳輸途中丟失模她。那么當(dāng)出現(xiàn)這種情況的時(shí)候稻艰，消息中間件是如何保證數(shù)據(jù)一致性呢？——答案就是超時(shí)詢問機(jī)制侈净。

title

系統(tǒng)A除了實(shí)現(xiàn)正常的業(yè)務(wù)流程外尊勿，還需提供一個(gè)事務(wù)詢問的接口，供消息中間件調(diào)用畜侦。當(dāng)消息中間件收到一條事務(wù)型消息后便開始計(jì)時(shí)元扔，如果到了超時(shí)時(shí)間也沒收到系統(tǒng)A發(fā)來的Commit或Rollback指令的話，就會(huì)主動(dòng)調(diào)用系統(tǒng)A提供的事務(wù)詢問接口詢問該系統(tǒng)目前的狀態(tài)旋膳。該接口會(huì)返回三種結(jié)果：

提交? 若獲得的狀態(tài)是“提交”澎语，則將該消息投遞給系統(tǒng)B。

回滾? 若獲得的狀態(tài)是“回滾”验懊，則直接將條消息丟棄擅羞。

處理中? 若獲得的狀態(tài)是“處理中”，則繼續(xù)等待义图。

消息中間件的超時(shí)詢問機(jī)制能夠防止上游系統(tǒng)因在傳輸過程中丟失Commit/Rollback指令而導(dǎo)致的系統(tǒng)不一致情況减俏，而且能降低上游系統(tǒng)的阻塞時(shí)間，上游系統(tǒng)只要發(fā)出Commit/Rollback指令后便可以處理其他任務(wù)碱工，無需等待確認(rèn)應(yīng)答娃承。而Commit/Rollback指令丟失的情況通過超時(shí)詢問機(jī)制來彌補(bǔ)奏夫，這樣大大降低上游系統(tǒng)的阻塞時(shí)間，提升系統(tǒng)的并發(fā)度草慧。

下面來說一說消息投遞過程的可靠性保證桶蛔。? 當(dāng)上游系統(tǒng)執(zhí)行完任務(wù)并向消息中間件提交了Commit指令后，便可以處理其他任務(wù)了漫谷，此時(shí)它可以認(rèn)為事務(wù)已經(jīng)完成仔雷，接下來消息中間件一定會(huì)保證消息被下游系統(tǒng)成功消費(fèi)掉！那么這是怎么做到的呢舔示？這由消息中間件的投遞流程來保證碟婆。

消息中間件向下游系統(tǒng)投遞完消息后便進(jìn)入阻塞等待狀態(tài)，下游系統(tǒng)便立即進(jìn)行任務(wù)的處理惕稻，任務(wù)處理完成后便向消息中間件返回應(yīng)答竖共。消息中間件收到確認(rèn)應(yīng)答后便認(rèn)為該事務(wù)處理完畢！

如果消息在投遞過程中丟失俺祠，或消息的確認(rèn)應(yīng)答在返回途中丟失公给，那么消息中間件在等待確認(rèn)應(yīng)答超時(shí)之后就會(huì)重新投遞，直到下游消費(fèi)者返回消費(fèi)成功響應(yīng)為止蜘渣。當(dāng)然淌铐，一般消息中間件可以設(shè)置消息重試的次數(shù)和時(shí)間間隔，比如：當(dāng)?shù)谝淮瓮哆f失敗后蔫缸，每隔五分鐘重試一次腿准，一共重試3次。如果重試3次之后仍然投遞失敗拾碌，那么這條消息就需要人工干預(yù)吐葱。

有的同學(xué)可能要問：消息投遞失敗后為什么不回滾消息，而是不斷嘗試重新投遞校翔？

這就涉及到整套分布式事務(wù)系統(tǒng)的實(shí)現(xiàn)成本問題弟跑。? 我們知道，當(dāng)系統(tǒng)A將向消息中間件發(fā)送Commit指令后防症，它便去做別的事情了窖认。如果此時(shí)消息投遞失敗，需要回滾的話告希，就需要讓系統(tǒng)A事先提供回滾接口，這無疑增加了額外的開發(fā)成本烧给，業(yè)務(wù)系統(tǒng)的復(fù)雜度也將提高燕偶。對(duì)于一個(gè)業(yè)務(wù)系統(tǒng)的設(shè)計(jì)目標(biāo)是，在保證性能的前提下础嫡，最大限度地降低系統(tǒng)復(fù)雜度指么，從而能夠降低系統(tǒng)的運(yùn)維成本酝惧。

不知大家是否發(fā)現(xiàn)，上游系統(tǒng)A向消息中間件提交Commit/Rollback消息采用的是異步方式伯诬，也就是當(dāng)上游系統(tǒng)提交完消息后便可以去做別的事情晚唇，接下來提交、回滾就完全交給消息中間件來完成盗似，并且完全信任消息中間件哩陕，認(rèn)為它一定能正確地完成事務(wù)的提交或回滾。然而赫舒，消息中間件向下游系統(tǒng)投遞消息的過程是同步的悍及。也就是消息中間件將消息投遞給下游系統(tǒng)后，它會(huì)阻塞等待接癌，等下游系統(tǒng)成功處理完任務(wù)返回確認(rèn)應(yīng)答后才取消阻塞等待心赶。為什么這兩者在設(shè)計(jì)上是不一致的呢？

首先缺猛，上游系統(tǒng)和消息中間件之間采用異步通信是為了提高系統(tǒng)并發(fā)度缨叫。業(yè)務(wù)系統(tǒng)直接和用戶打交道，用戶體驗(yàn)尤為重要荔燎，因此這種異步通信方式能夠極大程度地降低用戶等待時(shí)間耻姥。此外，異步通信相對(duì)于同步通信而言湖雹，沒有了長(zhǎng)時(shí)間的阻塞等待咏闪，因此系統(tǒng)的并發(fā)性也大大增加。但異步通信可能會(huì)引起Commit/Rollback指令丟失的問題摔吏，這就由消息中間件的超時(shí)詢問機(jī)制來彌補(bǔ)鸽嫂。

那么，消息中間件和下游系統(tǒng)之間為什么要采用同步通信呢征讲？

異步能提升系統(tǒng)性能据某，但隨之會(huì)增加系統(tǒng)復(fù)雜度；而同步雖然降低系統(tǒng)并發(fā)度诗箍，但實(shí)現(xiàn)成本較低癣籽。因此，在對(duì)并發(fā)度要求不是很高的情況下滤祖，或者服務(wù)器資源較為充裕的情況下筷狼，我們可以選擇同步來降低系統(tǒng)的復(fù)雜度。? 我們知道匠童，消息中間件是一個(gè)獨(dú)立于業(yè)務(wù)系統(tǒng)的第三方中間件埂材，它不和任何業(yè)務(wù)系統(tǒng)產(chǎn)生直接的耦合，它也不和用戶產(chǎn)生直接的關(guān)聯(lián)汤求，它一般部署在獨(dú)立的服務(wù)器集群上俏险，具有良好的可擴(kuò)展性严拒，所以不必太過于擔(dān)心它的性能，如果處理速度無法滿足我們的要求竖独，可以增加機(jī)器來解決裤唠。而且，即使消息中間件處理速度有一定的延遲那也是可以接受的莹痢，因?yàn)榍懊嫠榻B的BASE理論就告訴我們了种蘸，我們追求的是最終一致性，而非實(shí)時(shí)一致性格二，因此消息中間件產(chǎn)生的時(shí)延導(dǎo)致事務(wù)短暫的不一致是可以接受的劈彪。

方案3：最大努力通知（定期校對(duì)）

最大努力通知也被稱為定期校對(duì)，其實(shí)在方案二中已經(jīng)包含顶猜，這里再單獨(dú)介紹沧奴，主要是為了知識(shí)體系的完整性。這種方案也需要消息中間件的參與长窄，其過程如下：

上游系統(tǒng)在完成任務(wù)后滔吠，向消息中間件同步地發(fā)送一條消息，確保消息中間件成功持久化這條消息挠日，然后上游系統(tǒng)可以去做別的事情了疮绷；

消息中間件收到消息后負(fù)責(zé)將該消息同步投遞給相應(yīng)的下游系統(tǒng)，并觸發(fā)下游系統(tǒng)的任務(wù)執(zhí)行嚣潜；

當(dāng)下游系統(tǒng)處理成功后冬骚，向消息中間件反饋確認(rèn)應(yīng)答，消息中間件便可以將該條消息刪除懂算，從而該事務(wù)完成只冻。

上面是一個(gè)理想化的過程，但在實(shí)際場(chǎng)景中计技，往往會(huì)出現(xiàn)如下幾種意外情況：

消息中間件向下游系統(tǒng)投遞消息失敗

上游系統(tǒng)向消息中間件發(fā)送消息失敗

對(duì)于第一種情況喜德，消息中間件具有重試機(jī)制，我們可以在消息中間件中設(shè)置消息的重試次數(shù)和重試時(shí)間間隔垮媒，對(duì)于網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的消息投遞失敗的情況舍悯，往往重試幾次后消息便可以成功投遞，如果超過了重試的上限仍然投遞失敗睡雇，那么消息中間件不再投遞該消息萌衬，而是記錄在失敗消息表中，消息中間件需要提供失敗消息的查詢接口它抱，下游系統(tǒng)會(huì)定期查詢失敗消息秕豫，并將其消費(fèi)，這就是所謂的“定期校對(duì)”抗愁。

如果重復(fù)投遞和定期校對(duì)都不能解決問題馁蒂，往往是因?yàn)橄掠蜗到y(tǒng)出現(xiàn)了嚴(yán)重的錯(cuò)誤，此時(shí)就需要人工干預(yù)蜘腌。

對(duì)于第二種情況沫屡，需要在上游系統(tǒng)中建立消息重發(fā)機(jī)制〈橹椋可以在上游系統(tǒng)建立一張本地消息表沮脖，并將任務(wù)處理過程和向本地消息表中插入消息這兩個(gè)步驟放在一個(gè)本地事務(wù)中完成。如果向本地消息表插入消息失敗芯急，那么就會(huì)觸發(fā)回滾勺届，之前的任務(wù)處理結(jié)果就會(huì)被取消。如果這量步都執(zhí)行成功娶耍，那么該本地事務(wù)就完成了免姿。接下來會(huì)有一個(gè)專門的消息發(fā)送者不斷地發(fā)送本地消息表中的消息，如果發(fā)送失敗它會(huì)返回重試榕酒。當(dāng)然胚膊，也要給消息發(fā)送者設(shè)置重試的上限，一般而言想鹰，達(dá)到重試上限仍然發(fā)送失敗紊婉，那就意味著消息中間件出現(xiàn)嚴(yán)重的問題，此時(shí)也只有人工干預(yù)才能解決問題辑舷。

對(duì)于不支持事務(wù)型消息的消息中間件喻犁，如果要實(shí)現(xiàn)分布式事務(wù)的話，就可以采用這種方式何缓。它能夠通過重試機(jī)制+定期校對(duì)實(shí)現(xiàn)分布式事務(wù)肢础，但相比于第二種方案，它達(dá)到數(shù)據(jù)一致性的周期較長(zhǎng)歌殃，而且還需要在上游系統(tǒng)中實(shí)現(xiàn)消息重試發(fā)布機(jī)制乔妈，以確保消息成功發(fā)布給消息中間件，這無疑增加了業(yè)務(wù)系統(tǒng)的開發(fā)成本氓皱，使得業(yè)務(wù)系統(tǒng)不夠純粹路召，并且這些額外的業(yè)務(wù)邏輯無疑會(huì)占用業(yè)務(wù)系統(tǒng)的硬件資源，從而影響性能波材。

因此股淡，盡量選擇支持事務(wù)型消息的消息中間件來實(shí)現(xiàn)分布式事務(wù)，如RocketMQ廷区。

方案4：TCC（兩階段型唯灵、補(bǔ)償型）

TCC即為Try Confirm Cancel，它屬于補(bǔ)償型分布式事務(wù)隙轻。顧名思義埠帕，TCC實(shí)現(xiàn)分布式事務(wù)一共有三個(gè)步驟：

Try：嘗試待執(zhí)行的業(yè)務(wù)

這個(gè)過程并未執(zhí)行業(yè)務(wù)垢揩，只是完成所有業(yè)務(wù)的一致性檢查，并預(yù)留好執(zhí)行所需的全部資源

Confirm：執(zhí)行業(yè)務(wù)

這個(gè)過程真正開始執(zhí)行業(yè)務(wù)敛瓷，由于Try階段已經(jīng)完成了一致性檢查叁巨，因此本過程直接執(zhí)行，而不做任何檢查呐籽。并且在執(zhí)行的過程中锋勺，會(huì)使用到Try階段預(yù)留的業(yè)務(wù)資源。

Cancel：取消執(zhí)行的業(yè)務(wù)

若業(yè)務(wù)執(zhí)行失敗狡蝶，則進(jìn)入Cancel階段庶橱，它會(huì)釋放所有占用的業(yè)務(wù)資源，并回滾Confirm階段執(zhí)行的操作贪惹。

下面以一個(gè)轉(zhuǎn)賬的例子來解釋下TCC實(shí)現(xiàn)分布式事務(wù)的過程苏章。

假設(shè)用戶A用他的賬戶余額給用戶B發(fā)一個(gè)100元的紅包，并且余額系統(tǒng)和紅包系統(tǒng)是兩個(gè)獨(dú)立的系統(tǒng)馍乙。

Try

創(chuàng)建一條轉(zhuǎn)賬流水布近，并將流水的狀態(tài)設(shè)為交易中

將用戶A的賬戶中扣除100元（預(yù)留業(yè)務(wù)資源）

Try成功之后，便進(jìn)入Confirm階段

Try過程發(fā)生任何異常丝格，均進(jìn)入Cancel階段

Confirm

向B用戶的紅包賬戶中增加100元

將流水的狀態(tài)設(shè)為交易已完成

Confirm過程發(fā)生任何異常撑瞧，均進(jìn)入Cancel階段

Confirm過程執(zhí)行成功，則該事務(wù)結(jié)束

Cancel

將用戶A的賬戶增加100元

將流水的狀態(tài)設(shè)為交易失敗

在傳統(tǒng)事務(wù)機(jī)制中显蝌，業(yè)務(wù)邏輯的執(zhí)行和事務(wù)的處理预伺，是在不同的階段由不同的部件來完成的：業(yè)務(wù)邏輯部分訪問資源實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)，其處理是由業(yè)務(wù)系統(tǒng)負(fù)責(zé)曼尊；事務(wù)處理部分通過協(xié)調(diào)資源管理器以實(shí)現(xiàn)事務(wù)管理酬诀，其處理由事務(wù)管理器來負(fù)責(zé)。二者沒有太多交互的地方骆撇，所以瞒御，傳統(tǒng)事務(wù)管理器的事務(wù)處理邏輯，僅需要著眼于事務(wù)完成（commit/rollback）階段神郊，而不必關(guān)注業(yè)務(wù)執(zhí)行階段肴裙。

TCC全局事務(wù)必須基于RM本地事務(wù)來實(shí)現(xiàn)全局事務(wù)

TCC服務(wù)是由Try/Confirm/Cancel業(yè)務(wù)構(gòu)成的，? 其Try/Confirm/Cancel業(yè)務(wù)在執(zhí)行時(shí)涌乳，會(huì)訪問資源管理器（Resource Manager蜻懦，下文簡(jiǎn)稱RM）來存取數(shù)據(jù)。這些存取操作夕晓，必須要參與RM本地事務(wù)宛乃，以使其更改的數(shù)據(jù)要么都commit，要么都rollback。

這一點(diǎn)不難理解征炼，考慮一下如下場(chǎng)景：

假設(shè)圖中的服務(wù)B沒有基于RM本地事務(wù)（以RDBS為例析既，可通過設(shè)置auto-commit為true來模擬），那么一旦[B:Try]操作中途執(zhí)行失敗谆奥，TCC事務(wù)框架后續(xù)決定回滾全局事務(wù)時(shí)渡贾，該[B:Cancel]則需要判斷[B:Try]中哪些操作已經(jīng)寫到DB、哪些操作還沒有寫到DB：假設(shè)[B:Try]業(yè)務(wù)有5個(gè)寫庫(kù)操作雄右，[B:Cancel]業(yè)務(wù)則需要逐個(gè)判斷這5個(gè)操作是否生效，并將生效的操作執(zhí)行反向操作纺讲。

不幸的是擂仍，由于[B:Cancel]業(yè)務(wù)也有n（0<=n<=5）個(gè)反向的寫庫(kù)操作，此時(shí)一旦[B:Cancel]也中途出錯(cuò)熬甚，則后續(xù)的[B:Cancel]執(zhí)行任務(wù)更加繁重逢渔。因?yàn)椋啾鹊谝淮蝃B:Cancel]操作乡括，后續(xù)的[B:Cancel]操作還需要判斷先前的[B:Cancel]操作的n（0<=n<=5）個(gè)寫庫(kù)中哪幾個(gè)已經(jīng)執(zhí)行肃廓、哪幾個(gè)還沒有執(zhí)行，這就涉及到了冪等性問題诲泌。而對(duì)冪等性的保障盲赊，又很可能還需要涉及額外的寫庫(kù)操作，該寫庫(kù)操作又會(huì)因?yàn)闆]有RM本地事務(wù)的支持而存在類似問題敷扫。哀蘑。】冢可想而知绘迁，如果不基于RM本地事務(wù)，TCC事務(wù)框架是無法有效的管理TCC全局事務(wù)的卒密。

反之缀台，基于RM本地事務(wù)的TCC事務(wù)，這種情況則會(huì)很容易處理：[B:Try]操作中途執(zhí)行失敗哮奇，TCC事務(wù)框架將其參與RM本地事務(wù)直接rollback即可膛腐。后續(xù)TCC事務(wù)框架決定回滾全局事務(wù)時(shí)，在知道“[B:Try]操作涉及的RM本地事務(wù)已經(jīng)rollback”的情況下屏镊，根本無需執(zhí)行[B:Cancel]操作依疼。

換句話說，基于RM本地事務(wù)實(shí)現(xiàn)TCC事務(wù)框架時(shí)而芥，一個(gè)TCC型服務(wù)的cancel業(yè)務(wù)要么執(zhí)行律罢，要么不執(zhí)行，不需要考慮部分執(zhí)行的情況。

TCC事務(wù)框架應(yīng)該提供Confirm/Cancel服務(wù)的冪等性保障

一般認(rèn)為误辑，服務(wù)的冪等性沧踏，是指針對(duì)同一個(gè)服務(wù)的多次(n>1)請(qǐng)求和對(duì)它的單次(n=1)請(qǐng)求，二者具有相同的副作用巾钉。

在TCC事務(wù)模型中翘狱，Confirm/Cancel業(yè)務(wù)可能會(huì)被重復(fù)調(diào)用，其原因很多砰苍。比如潦匈，全局事務(wù)在提交/回滾時(shí)會(huì)調(diào)用各TCC服務(wù)的Confirm/Cancel業(yè)務(wù)邏輯。執(zhí)行這些Confirm/Cancel業(yè)務(wù)時(shí)赚导，可能會(huì)出現(xiàn)如網(wǎng)絡(luò)中斷的故障而使得全局事務(wù)不能完成茬缩。因此，故障恢復(fù)機(jī)制后續(xù)仍然會(huì)重新提交/回滾這些未完成的全局事務(wù)吼旧，這樣就會(huì)再次調(diào)用參與該全局事務(wù)的各TCC服務(wù)的Confirm/Cancel業(yè)務(wù)邏輯凰锡。

既然Confirm/Cancel業(yè)務(wù)可能會(huì)被多次調(diào)用，就需要保障其冪等性圈暗。? 那么掂为，應(yīng)該由TCC事務(wù)框架來提供冪等性保障？還是應(yīng)該由業(yè)務(wù)系統(tǒng)自行來保障冪等性呢员串？? 個(gè)人認(rèn)為勇哗，應(yīng)該是由TCC事務(wù)框架來提供冪等性保障。如果僅僅只是極個(gè)別服務(wù)存在這個(gè)問題的話寸齐，那么由業(yè)務(wù)系統(tǒng)來負(fù)責(zé)也是可以的智绸；然而，這是一類公共問題访忿，毫無疑問瞧栗，所有TCC服務(wù)的Confirm/Cancel業(yè)務(wù)存在冪等性問題。TCC服務(wù)的公共問題應(yīng)該由TCC事務(wù)框架來解決海铆；而且迹恐，考慮一下由業(yè)務(wù)系統(tǒng)來負(fù)責(zé)冪等性需要考慮的問題，就會(huì)發(fā)現(xiàn)卧斟，這無疑增大了業(yè)務(wù)系統(tǒng)的復(fù)雜度殴边。

作者：Java喵

鏈接：http://www.reibang.com/p/558bf880219b

來源：簡(jiǎn)書

著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)珍语，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處锤岸。