億級(jí)流量架構(gòu)之分布式事務(wù)思路及方法

作者：等不到的口琴 2021-02-24 16:17:18

分布式事務(wù)以及分布式鎖是分布式中難點(diǎn),分布式事務(wù)一篇文章可能寫(xiě)不完,我的習(xí)慣時(shí)從基本概念出發(fā),一步一步開(kāi)始介紹,前面會(huì)先梳理事務(wù)中一些基本概念,對(duì)基本概念十分清楚的話可以直接看"一致性討論"以及后面的部分。

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

在日常生活中,很多事要么全部做,要么全部不做,不能只做一部分,不然就會(huì)產(chǎn)生其他復(fù)雜的問(wèn)題,很多人喜歡舉轉(zhuǎn)賬的例子,對(duì)于同一個(gè)賬號(hào),A在湖北往出轉(zhuǎn)500,B在廣東取錢(qián)500,那么A轉(zhuǎn)出去之后要將A賬號(hào)的錢(qián)數(shù)目扣除,B賬號(hào)數(shù)目增加: 事務(wù) = (A賬號(hào)扣除500,B賬號(hào)增加500)

看到?jīng)],像這樣多個(gè)步驟放在一起,就是事務(wù),要么都執(zhí)行,要么都不執(zhí)行,如果我們的數(shù)據(jù)存儲(chǔ)在多個(gè)數(shù)據(jù)庫(kù)中,也就是存在跨庫(kù)調(diào)用,由于網(wǎng)絡(luò)具有不安全性以及延時(shí)性,如何保證事務(wù)分布式執(zhí)行呢?如果執(zhí)行到一半斷電又該如何處理?在講解分布式事務(wù)之前先簡(jiǎn)單回顧事務(wù)的一些特點(diǎn),俗稱 ACID ,下面逐一講解:

原子性(Atomic)

在化學(xué)中,分子構(gòu)成的物質(zhì),分子是保持化學(xué)特性的最小單位,如 H2O,CO2H2O,CO2 等,由原子構(gòu)成的物質(zhì),原子保持物質(zhì)特性,像 FeFe 啥的,意思就是不可分割,再分成質(zhì)子中子啥的就不是我們認(rèn)為的物質(zhì)了,這兒的原子性也是這個(gè)道理,就是事務(wù)不可以再拆分,例如上面的事務(wù),看著可以是由兩個(gè)過(guò)程組成的事務(wù),但是你拆開(kāi)就不是我們認(rèn)為該有的過(guò)程,所以,事務(wù)不可再分,具有原子性。

一致性（Consistency）

一致性也很好理解,對(duì)于上面的兩個(gè)賬戶,如果銀行想知道自己這兒被存了多少錢(qián),那么這個(gè)事務(wù)執(zhí)行前,A賬號(hào)有500塊,B賬號(hào)沒(méi)有錢(qián),銀行賬戶總共500塊,事務(wù)執(zhí)行后A賬號(hào)沒(méi)有錢(qián),B賬號(hào)有500塊,也就是這個(gè)500塊是一定的,不可能出現(xiàn)A賬號(hào)有500塊,B賬號(hào)也有500塊, 那就數(shù)據(jù)不一致了,這樣的話,說(shuō)明事務(wù)中某些步驟執(zhí)行出現(xiàn)了問(wèn)題,產(chǎn)生中間數(shù)據(jù),那么就不一致。

在分布式中,對(duì)于一個(gè)結(jié)果,多處同時(shí)查詢,得出的結(jié)果應(yīng)該是一致的。

隔離性（Isolation）

一個(gè)事務(wù)在未完成時(shí)，另一個(gè)事務(wù)不會(huì)影響到它,也就是如果B還給C轉(zhuǎn)賬1000,記為事務(wù)2:

事務(wù)1 = (A賬號(hào)扣除500,B賬號(hào)增加500)

事務(wù)2 = (B賬號(hào)扣除1000,C賬號(hào)增加1000)

這兩個(gè)事務(wù)之間不會(huì)產(chǎn)生影響,也就是不會(huì)發(fā)生A轉(zhuǎn)出的500塊到達(dá)C賬號(hào)這種情況。

持久性（Durability）

持久化,一般是意味著將數(shù)據(jù)寫(xiě)入磁盤(pán),不會(huì)輕易改變的意思,這兒是事務(wù)提交之后,會(huì)影響到數(shù)據(jù)庫(kù),不會(huì)丟失。這也就意味著,隨著系統(tǒng)越來(lái)越龐大，我們?yōu)榱颂岣呖捎眯浴⒕S護(hù)性、吞吐量等等技術(shù)指標(biāo)，就算改善原有架構(gòu)，業(yè)務(wù)計(jì)算的問(wèn)題解決后，數(shù)據(jù)庫(kù)還是會(huì)成為整個(gè)系統(tǒng)中的瓶頸。

一致性的討論

ACID本質(zhì)而言都是為了保護(hù)數(shù)據(jù)的一致性,而數(shù)據(jù)數(shù)據(jù)持久化時(shí)會(huì)觸發(fā)數(shù)據(jù)庫(kù)操作,造成效率低小,所以圍繞一致性(效率)產(chǎn)生了一些討論,分別是強(qiáng)一致性、弱一致性、最終一致性。

強(qiáng)一致性

任何一次讀都能讀到某個(gè)數(shù)據(jù)的最近一次寫(xiě)的數(shù)據(jù)。系統(tǒng)中的所有進(jìn)程，看到的操作順序，都和全局時(shí)鐘下的順序一致。簡(jiǎn)言之，在任意時(shí)刻，所有節(jié)點(diǎn)中的數(shù)據(jù)是一樣的,這就要求數(shù)據(jù)一有改變就寫(xiě)到數(shù)據(jù)庫(kù)。

弱一致性

數(shù)據(jù)更新后，不要求及時(shí)寫(xiě)會(huì)數(shù)據(jù)庫(kù)以及同步到所有節(jié)點(diǎn),也就是這時(shí)候數(shù)據(jù)與真實(shí)數(shù)據(jù)可能有一些出入,對(duì)于架構(gòu)而言,如果能容忍后續(xù)的訪問(wèn)只能訪問(wèn)到部分或者全部訪問(wèn)不到，則是弱一致性。

最終一致性

不保證在任意時(shí)刻任意節(jié)點(diǎn)上的同一份數(shù)據(jù)都是相同的，也就是有些節(jié)點(diǎn)數(shù)據(jù)可能是準(zhǔn)確的,有的可能是不準(zhǔn)確的, 但是隨著時(shí)間的遷移，不同節(jié)點(diǎn)上的同一份數(shù)據(jù)總是在向趨同的方向變化。簡(jiǎn)單說(shuō)，就是在一段時(shí)間后，節(jié)點(diǎn)間的數(shù)據(jù)會(huì)最終達(dá)到一致?tīng)顟B(tài)。

三種一致性中,強(qiáng)一致性數(shù)據(jù)更加可靠,但是由于時(shí)時(shí)刻刻要求所有數(shù)據(jù)庫(kù)保持?jǐn)?shù)據(jù)一致,所以效率低下,數(shù)據(jù)沒(méi)有統(tǒng)一完,請(qǐng)求就沒(méi)法得到響應(yīng),高并發(fā)場(chǎng)景下,體驗(yàn)不太好,所以在實(shí)際使用中,根據(jù)不同的業(yè)務(wù)選擇是一致性也不同,購(gòu)物時(shí)賬號(hào)付錢(qián)肯定是強(qiáng)一致性,但是商品庫(kù)存數(shù)據(jù)就不一定非要強(qiáng)一致性,至于商品下面的評(píng)論啥的,甚至可以選擇弱一致性。

分庫(kù)分表

前面講過(guò)集群的AKF拆分原則( Redis集群拆分原則之AKF ),大概意思是硬件性能是由上限的,當(dāng)硬件沒(méi)法支撐請(qǐng)求流量時(shí),可以將流量分發(fā)到不同的服務(wù)器上,AKF拆分之Y軸、Z軸拆分是業(yè)務(wù)拆分與數(shù)據(jù)拆分,那也就會(huì)涉及到將數(shù)據(jù)庫(kù)中的數(shù)據(jù)拆分存儲(chǔ)在不同的地方,這就叫分庫(kù)分表,不同類(lèi)型數(shù)據(jù)存儲(chǔ)在不同數(shù)據(jù)庫(kù)中做多機(jī)存儲(chǔ)和負(fù)載,這樣一來(lái),傳統(tǒng)的事務(wù)機(jī)制ACID便無(wú)法正常運(yùn)行。

分庫(kù)分表內(nèi)容是數(shù)據(jù)切分（Sharding），以及切分后對(duì)數(shù)據(jù)的定位、整合。具體來(lái)說(shuō), 數(shù)據(jù)切分就是將數(shù)據(jù)分散存儲(chǔ)到多個(gè)數(shù)據(jù)庫(kù)中，使得單一數(shù)據(jù)庫(kù)中的數(shù)據(jù)量變小，通過(guò)擴(kuò)充主機(jī)的數(shù)量緩解單一數(shù)據(jù)庫(kù)性能問(wèn)題，從而達(dá)到提升數(shù)據(jù)庫(kù)操作性能的目的。

數(shù)據(jù)切分根據(jù)其切分類(lèi)型，可以分為兩種方式：垂直（縱向）切分和水平（橫向）切分。

垂直拆分

垂直切分常見(jiàn)有垂直分庫(kù)和垂直分表兩種,兩種含義類(lèi)似。

垂直分庫(kù)就是根據(jù)業(yè)務(wù)耦合性，將關(guān)聯(lián)度低的不同表存儲(chǔ)在不同的數(shù)據(jù)庫(kù)。做法與大系統(tǒng)拆分為多個(gè)小系統(tǒng)類(lèi)似，按業(yè)務(wù)分類(lèi)進(jìn)行獨(dú)立劃分。與"微服務(wù)治理"的做法相似，每個(gè)微服務(wù)使用單獨(dú)的一個(gè)數(shù)據(jù)庫(kù)。如圖：

垂直分表類(lèi)似,例如將一張表包含一個(gè)人所有信息,例如姓名、身份證、性別、身高、體重、省、市、區(qū)、村、專(zhuān)業(yè)、G點(diǎn)等等,那么可以拆分成三個(gè)表:

第一個(gè)表只包含基本信息(姓名、身份證、性別、身高、體重);

第二個(gè)表包含籍貫信息(省、市、區(qū)、村);

第三個(gè)表包含學(xué)習(xí)信息(專(zhuān)業(yè)、G點(diǎn))。

垂直拆分優(yōu)缺點(diǎn)

垂直切分的優(yōu)點(diǎn)：

解決業(yè)務(wù)系統(tǒng)層面的耦合，業(yè)務(wù)清晰
與微服務(wù)的治理類(lèi)似，也能對(duì)不同業(yè)務(wù)的數(shù)據(jù)進(jìn)行分級(jí)管理、維護(hù)、監(jiān)控、擴(kuò)展等
高并發(fā)場(chǎng)景下，垂直切分一定程度的提升IO、數(shù)據(jù)庫(kù)連接數(shù)、單機(jī)硬件資源的瓶頸

垂直切分的缺點(diǎn)：

部分表無(wú)法join，只能通過(guò)接口聚合方式解決，提升了開(kāi)發(fā)的復(fù)雜度
分布式事務(wù)處理復(fù)雜
依然存在單表數(shù)據(jù)量過(guò)大的問(wèn)題（需要水平切分）

水平拆分

上面對(duì)數(shù)據(jù)庫(kù)垂直拆分之后,如果某個(gè)庫(kù)還是好大,比如存儲(chǔ)的數(shù)據(jù)極其龐大,那么可以再對(duì)數(shù)據(jù)庫(kù)進(jìn)行水平的拆分:

上面的水平拆分時(shí)按照ID區(qū)間來(lái)切分。例如：將userId為1~10000的記錄分到第一個(gè)庫(kù)，10001~20000的分到第二個(gè)庫(kù)，以此類(lèi)推。某種意義上，某些系統(tǒng)中使用的"冷熱數(shù)據(jù)分離"，將一些使用較少的歷史數(shù)據(jù)遷移到其他庫(kù)中，業(yè)務(wù)功能上只提供熱點(diǎn)數(shù)據(jù)的查詢，也是類(lèi)似的實(shí)踐。

除了上面按照用戶ID區(qū)間拆分,也可以做Hash運(yùn)算拆分,這兒就不詳細(xì)展開(kāi)了。

水平拆分優(yōu)缺點(diǎn)

水平拆分優(yōu)點(diǎn)在于：

單表大小可控
天然便于水平擴(kuò)展，后期如果想對(duì)整個(gè)分片集群擴(kuò)容時(shí)，只需要添加節(jié)點(diǎn)即可，無(wú)需對(duì)其他分片的數(shù)據(jù)進(jìn)行遷移
使用分片字段進(jìn)行范圍查找時(shí)，連續(xù)分片可快速定位分片進(jìn)行快速查詢，有效避免跨分片查詢的問(wèn)題。

水平拆分缺點(diǎn)：

熱點(diǎn)數(shù)據(jù)成為性能瓶頸。連續(xù)分片可能存在數(shù)據(jù)熱點(diǎn)，例如按時(shí)間字段分片，有些分片存儲(chǔ)最近時(shí)間段內(nèi)的數(shù)據(jù)，可能會(huì)被頻繁的讀寫(xiě)，而有些分片存儲(chǔ)的歷史數(shù)據(jù)，則很少被查詢

分庫(kù)分表帶來(lái)的問(wèn)題

分庫(kù)分表能有效的緩解單機(jī)和單庫(kù)帶來(lái)的性能瓶頸和壓力，突破網(wǎng)絡(luò)IO、硬件資源、連接數(shù)的瓶頸，同時(shí)也帶來(lái)了一些問(wèn)題,前面說(shuō)過(guò),事務(wù)包含一組子操作,這些造作要么全部執(zhí)行,要么全部不執(zhí)行,但是分庫(kù)之后,一個(gè)事務(wù)可能涉及多個(gè)數(shù)據(jù)庫(kù)或者多個(gè)表擴(kuò)庫(kù)執(zhí)行,而網(wǎng)絡(luò)具有不穩(wěn)定性,也就是事務(wù)執(zhí)行難度加大,分表分庫(kù)后事務(wù)為了與傳統(tǒng)事務(wù)做出區(qū)別,叫做分布式事務(wù)(跨分片事務(wù))。

跨分片事務(wù)也是分布式事務(wù)，沒(méi)有簡(jiǎn)單的方案，一般可使用"XA協(xié)議"和"兩階段提交"處理。

分布式事務(wù)能最大限度保證了數(shù)據(jù)庫(kù)操作的原子性。但在提交事務(wù)時(shí)需要協(xié)調(diào)多個(gè)節(jié)點(diǎn)，推后了提交事務(wù)的時(shí)間點(diǎn)，延長(zhǎng)了事務(wù)的執(zhí)行時(shí)間。導(dǎo)致事務(wù)在訪問(wèn)共享資源時(shí)發(fā)生沖突或死鎖的概率增高。隨著數(shù)據(jù)庫(kù)節(jié)點(diǎn)的增多，這種趨勢(shì)會(huì)越來(lái)越嚴(yán)重，從而成為系統(tǒng)在數(shù)據(jù)庫(kù)層面上水平擴(kuò)展的枷鎖。

最終一致性

對(duì)于那些性能要求很高，但對(duì)一致性要求不高的系統(tǒng)，往往不苛求系統(tǒng)的實(shí)時(shí)一致性，只要在允許的時(shí)間段內(nèi)達(dá)到最終一致性即可，可采用事務(wù)補(bǔ)償?shù)姆绞健Ｅc事務(wù)在執(zhí)行中發(fā)生錯(cuò)誤后立即回滾的方式不同，事務(wù)補(bǔ)償是一種事后檢查補(bǔ)救的措施，一些常見(jiàn)的實(shí)現(xiàn)方法有：對(duì)數(shù)據(jù)進(jìn)行對(duì)賬檢查，基于日志進(jìn)行對(duì)比，定期同標(biāo)準(zhǔn)數(shù)據(jù)來(lái)源進(jìn)行同步等等。事務(wù)補(bǔ)償還要結(jié)合業(yè)務(wù)系統(tǒng)來(lái)考慮。

分布式事務(wù)解決思路

講這個(gè)之前需要先簡(jiǎn)單回顧C(jī)AP原則和Base理論,因?yàn)榉植际绞聞?wù)不同于 ACID 的剛性事務(wù)，在分布式場(chǎng)景下基于 BASE 理論，提出了柔性事務(wù)的概念。要想通過(guò)柔性事務(wù)來(lái)達(dá)到最終的一致性，就需要依賴于一些特性，這些特性在具體的方案中不一定都要滿足，因?yàn)椴煌姆桨敢蟛灰粯樱坏嵌疾粷M足的話，是不可能做柔性事務(wù)的。

CAP原則

CAP一般人可能聽(tīng)了不下一百遍了,很多人都說(shuō)CAP是"三選二"的關(guān)系,讓人誤以為有AC這種情況,但是實(shí)際CAP是二選一的關(guān)系,這個(gè)在2012年已經(jīng)有一篇論文進(jìn)行解釋: CAP Twelve Years Later: How the "Rules" Have Changed

相當(dāng)于是對(duì)之前三選二說(shuō)法進(jìn)行修正,CAP中P(分區(qū)容錯(cuò)性)是必須具備的,在滿足P的前提下,很難同時(shí)滿足A(可用性)和C(一致性),但是在之后,又有一篇文章: Harvest, yield, and scalable tolerant systems ,這篇論文是基于上面那篇“CAP 12年后”的論文寫(xiě)的，它主要提出了 Harvest 和 Yield 概念，并把上面那篇論文中所討論的東西講得更為仔細(xì)了一些。簡(jiǎn)單來(lái)說(shuō)就是滿足P之后,C和A在放寬約束后可以得到兼顧,并不是非此即彼的關(guān)系,說(shuō)遠(yuǎn)了。

為什么P是必須的?

為什么CAP原則中分區(qū)容錯(cuò)性是必須的呢,首先要理解什么是分區(qū)容錯(cuò)性,分區(qū),這兒說(shuō)的是網(wǎng)絡(luò),網(wǎng)絡(luò)集群設(shè)計(jì)到很多的服務(wù)器,某一瞬間網(wǎng)絡(luò)不穩(wěn)定,那么相當(dāng)于將網(wǎng)絡(luò)分成了不同的區(qū),假設(shè)分成了兩個(gè)區(qū),這時(shí)候如果有一筆交易:

對(duì)分區(qū)一發(fā)出消息:A給B轉(zhuǎn)賬100元,對(duì)分區(qū)二發(fā)出消息:A給B轉(zhuǎn)賬200元

那么對(duì)于兩個(gè)分區(qū)而言,有兩種情況:

a）無(wú)可用性，即這兩筆交易至少會(huì)有一筆交易不會(huì)被接受；

b）無(wú)一致性，一半看到的是 A給B轉(zhuǎn)賬100元而另一半則看到 A給B轉(zhuǎn)賬200元。

所以,分區(qū)容忍性必須要滿足,解決策略是一個(gè)數(shù)據(jù)項(xiàng)復(fù)制到多個(gè)節(jié)點(diǎn)上，那么出現(xiàn)分區(qū)之后，這一數(shù)據(jù)項(xiàng)就可能分布到各個(gè)區(qū)里。容忍性就提高了。

Base理論

在很多時(shí)候，我們并不需要強(qiáng)一致性的系統(tǒng)，所以后來(lái)，人們爭(zhēng)論關(guān)于數(shù)據(jù)一致性和可用性時(shí)，主要是集中在強(qiáng)一致性的 ACID 或最終一致性的 BASE中, BASE是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果，其來(lái)源于對(duì)大規(guī)模互聯(lián)網(wǎng)分布式系統(tǒng)實(shí)踐的總結(jié)，是基于CAP定律逐步演化而來(lái)。其核心思想是即使無(wú)法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)，才用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)打到最終一致性。

BASE理論是Basically Available(基本可用)，Soft State（軟狀態(tài)）和Eventually Consistent（最終一致性）三個(gè)短語(yǔ)的縮寫(xiě)。

基本可用

假設(shè)系統(tǒng)，出現(xiàn)了不可預(yù)知的故障，但還是能用，相比較正常的系統(tǒng)而言：

響應(yīng)時(shí)間上的損失 ：正常情況下的搜索引擎0.5秒即返回給用戶結(jié)果，而基本可用的搜索引擎可以在2秒作用返回結(jié)果。
功能上的損失 ：在一個(gè)電商網(wǎng)站上，正常情況下，用戶可以順利完成每一筆訂單。但是到了大促期間，為了保護(hù)購(gòu)物系統(tǒng)的穩(wěn)定性，部分消費(fèi)者可能會(huì)被引導(dǎo)到一個(gè)降級(jí)頁(yè)面。

這就叫基本可用

軟狀態(tài)

相對(duì)于原子性而言，要求多個(gè)節(jié)點(diǎn)的數(shù)據(jù)副本都是一致的，這是一種“硬狀態(tài)”。軟狀態(tài)指的是：允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該狀態(tài)不影響系統(tǒng)的整體可用性，即允許系統(tǒng)在多個(gè)不同節(jié)點(diǎn)的數(shù)據(jù)副本存在數(shù)據(jù)延時(shí)。

最終一致性

上面說(shuō)軟狀態(tài)，然后不可能一直是軟狀態(tài)，必須有個(gè)時(shí)間期限。在期限過(guò)后，應(yīng)當(dāng)保證所有副本保持?jǐn)?shù)據(jù)一致性，從而達(dá)到數(shù)據(jù)的最終一致性。這個(gè)時(shí)間期限取決于網(wǎng)絡(luò)延時(shí)、系統(tǒng)負(fù)載、數(shù)據(jù)復(fù)制方案設(shè)計(jì)等等因素。

Base其核心思想是：

既然無(wú)法做到強(qiáng)一致性（Strong consistency），但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性（Eventual consistency）。有了Base理論就可以開(kāi)始講述分布式事務(wù)的處理思路了。

二階段提交協(xié)議

二階段提交(2PC：Two-Phase Commit),顧名思義，該協(xié)議將一個(gè)分布式的事務(wù)過(guò)程拆分成兩個(gè)階段：投票和 事務(wù)提交 。為了讓整個(gè)數(shù)據(jù)庫(kù)集群能夠正常的運(yùn)行，該協(xié)議指定了一個(gè) 協(xié)調(diào)者 單點(diǎn)，用于協(xié)調(diào)整個(gè)數(shù)據(jù)庫(kù)集群各節(jié)點(diǎn)的運(yùn)行。為了簡(jiǎn)化描述，我們將數(shù)據(jù)庫(kù)集群中的各個(gè)節(jié)點(diǎn)稱為 參與者 ，三階段提交協(xié)議中同樣包含協(xié)調(diào)者和參與者這兩個(gè)角色定義,后面再說(shuō)。

第一階段：投票

該階段的主要目的在于打探數(shù)據(jù)庫(kù)集群中的各個(gè)參與者是否能夠正常的執(zhí)行事務(wù)，具體步驟如下：

協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)執(zhí)行請(qǐng)求，并等待參與者反饋事務(wù)執(zhí)行結(jié)果；
事務(wù)參與者收到請(qǐng)求之后，執(zhí)行事務(wù)但不提交，并記錄事務(wù)日志；
參與者將自己事務(wù)執(zhí)行情況反饋給協(xié)調(diào)者，同時(shí)阻塞等待協(xié)調(diào)者的后續(xù)指令。

第二階段：事務(wù)提交

在經(jīng)過(guò)第一階段協(xié)調(diào)者的詢盤(pán)之后，各個(gè)參與者會(huì)回復(fù)自己事務(wù)的執(zhí)行情況，這時(shí)候存在 3 種可能性：

所有的參與者都回復(fù)能夠正常執(zhí)行事務(wù)。
一個(gè)或多個(gè)參與者回復(fù)事務(wù)執(zhí)行失敗。
協(xié)調(diào)者等待超時(shí)。

對(duì)于第 1 種情況，協(xié)調(diào)者將向所有的參與者發(fā)出提交事務(wù)的通知，具體步驟如下：

協(xié)調(diào)者向各個(gè)參與者發(fā)送 commit 通知，請(qǐng)求提交事務(wù)；
參與者收到事務(wù)提交通知之后執(zhí)行 commit 操作，然后釋放占有的資源；
參與者向協(xié)調(diào)者返回事務(wù) commit 結(jié)果信息。

對(duì)于第 2 和第 3 種情況，協(xié)調(diào)者均認(rèn)為參與者無(wú)法成功執(zhí)行事務(wù)，為了整個(gè)集群數(shù)據(jù)的一致性，所以要向各個(gè)參與者發(fā)送事務(wù)回滾通知，具體步驟如下：

協(xié)調(diào)者向各個(gè)參與者發(fā)送事務(wù) rollback 通知，請(qǐng)求回滾事務(wù)；
參與者收到事務(wù)回滾通知之后執(zhí)行 rollback 操作，然后釋放占有的資源；
參與者向協(xié)調(diào)者返回事務(wù) rollback 結(jié)果信息。

兩階段提交協(xié)議解決的是分布式數(shù)據(jù)庫(kù)數(shù)據(jù)強(qiáng)一致性問(wèn)題，實(shí)際應(yīng)用中更多的是用來(lái)解決事務(wù)操作的原子性，下圖描繪了協(xié)調(diào)者與參與者的狀態(tài)轉(zhuǎn)換。

站在協(xié)調(diào)者的角度，在發(fā)起投票之后就進(jìn)入了 WAIT 等待狀態(tài)，等待所有參與者回復(fù)各自事務(wù)執(zhí)行狀態(tài)，并在收到所有參與者的回復(fù)后決策下一步是發(fā)送 commit提交或 rollback回滾信息。

站在參與者的角度，當(dāng)回復(fù)完協(xié)調(diào)者的投票請(qǐng)求之后便進(jìn)入 READY 狀態(tài)（能夠正常執(zhí)行事務(wù)），接下去就是等待協(xié)調(diào)者最終的決策通知，一旦收到通知便可依據(jù)決策執(zhí)行 commit 或 rollback 操作。

兩階段提交協(xié)議原理簡(jiǎn)單、易于實(shí)現(xiàn)，但是缺點(diǎn)也是顯而易見(jiàn)的，包含如下：

單點(diǎn)問(wèn)題

協(xié)調(diào)者在整個(gè)兩階段提交過(guò)程中扮演著舉足輕重的作用，一旦協(xié)調(diào)者所在服務(wù)器宕機(jī)，就會(huì)影響整個(gè)數(shù)據(jù)庫(kù)集群的正常運(yùn)行。比如在第二階段中，如果協(xié)調(diào)者因?yàn)楣收喜荒苷０l(fā)送事務(wù)提交或回滾通知，那么參與者們將一直處于阻塞狀態(tài)，整個(gè)數(shù)據(jù)庫(kù)集群將無(wú)法提供服務(wù)。

同步阻塞

兩階段提交執(zhí)行過(guò)程中，所有的參與者都需要聽(tīng)從協(xié)調(diào)者的統(tǒng)一調(diào)度，期間處于阻塞狀態(tài)而不能從事其他操作，這樣效率極其低下。

數(shù)據(jù)不一致性

兩階段提交協(xié)議雖然是分布式數(shù)據(jù)強(qiáng)一致性所設(shè)計(jì)，但仍然存在數(shù)據(jù)不一致性的可能性。比如在第二階段中，假設(shè)協(xié)調(diào)者發(fā)出了事務(wù) commit 通知，但是因?yàn)榫W(wǎng)絡(luò)問(wèn)題該通知僅被一部分參與者所收到并執(zhí)行了commit 操作，其余的參與者則因?yàn)闆](méi)有收到通知一直處于阻塞狀態(tài)，這時(shí)候就產(chǎn)生了數(shù)據(jù)的不一致性。

針對(duì)上述問(wèn)題可以引入超時(shí)機(jī)制和互詢機(jī)制在很大程度上予以解決。

超時(shí)機(jī)制

對(duì)于協(xié)調(diào)者來(lái)說(shuō)如果在指定時(shí)間內(nèi)沒(méi)有收到所有參與者的應(yīng)答，則可以自動(dòng)退出 WAIT 狀態(tài)，并向所有參與者發(fā)送 rollback 通知。對(duì)于參與者來(lái)說(shuō)如果位于 READY 狀態(tài)，但是在指定時(shí)間內(nèi)沒(méi)有收到協(xié)調(diào)者的第二階段通知，則不能武斷地執(zhí)行 rollback 操作，因?yàn)閰f(xié)調(diào)者可能發(fā)送的是 commit 通知，這個(gè)時(shí)候執(zhí)行 rollback 就會(huì)導(dǎo)致數(shù)據(jù)不一致。

互詢機(jī)制

此時(shí)，我們可以介入互詢機(jī)制，讓參與者 A 去詢問(wèn)其他參與者 B 的執(zhí)行情況。如果 B 執(zhí)行了 rollback 或 commit 操作，則 A 可以大膽的與 B 執(zhí)行相同的操作；如果 B 此時(shí)還沒(méi)有到達(dá) READY 狀態(tài)，則可以推斷出協(xié)調(diào)者發(fā)出的肯定是 rollback 通知；如果 B 同樣位于 READY 狀態(tài)，則 A 可以繼續(xù)詢問(wèn)另外的參與者。只有當(dāng)所有的參與者都位于 READY 狀態(tài)時(shí)，此時(shí)兩階段提交協(xié)議無(wú)法處理，將陷入長(zhǎng)時(shí)間的阻塞狀態(tài)。

三階段提交協(xié)議

三階段提交協(xié)議（3PC：Three-Phase Commit）, 針對(duì)兩階段提交存在的問(wèn)題，三階段提交協(xié)議通過(guò)引入一個(gè) 預(yù)詢盤(pán) 階段，以及超時(shí)策略來(lái)減少整個(gè)集群的阻塞時(shí)間，提升系統(tǒng)性能。三階段提交的三個(gè)階段分別為：預(yù)詢盤(pán)（can_commit）、預(yù)提交（pre_commit），以及事務(wù)提交（do_commit）。

第一階段：預(yù)詢盤(pán)

該階段協(xié)調(diào)者會(huì)去詢問(wèn)各個(gè)參與者是否能夠正常執(zhí)行事務(wù)，參與者根據(jù)自身情況回復(fù)一個(gè)預(yù)估值，相對(duì)于真正的執(zhí)行事務(wù)，這個(gè)過(guò)程是輕量的，具體步驟如下：

協(xié)調(diào)者向各個(gè)參與者發(fā)送事務(wù)詢問(wèn)通知，詢問(wèn)是否可以執(zhí)行事務(wù)操作，并等待回復(fù)；
各個(gè)參與者依據(jù)自身狀況回復(fù)一個(gè)預(yù)估值，如果預(yù)估自己能夠正常執(zhí)行事務(wù)就返回確定信息，并進(jìn)入預(yù)備狀態(tài)，否則返回否定信息。

第二階段：預(yù)提交

本階段協(xié)調(diào)者會(huì)根據(jù)第一階段的詢盤(pán)結(jié)果采取相應(yīng)操作，詢盤(pán)結(jié)果主要有 3 種：

所有的參與者都返回確定信息。
一個(gè)或多個(gè)參與者返回否定信息。
協(xié)調(diào)者等待超時(shí)。

針對(duì)第 1 種情況，協(xié)調(diào)者會(huì)向所有參與者發(fā)送事務(wù)執(zhí)行請(qǐng)求，具體步驟如下：

協(xié)調(diào)者向所有的事務(wù)參與者發(fā)送事務(wù)執(zhí)行通知；
參與者收到通知后執(zhí)行事務(wù)但不提交；
參與者將事務(wù)執(zhí)行情況返回給客戶端。

在上述步驟中，如果參與者等待超時(shí)，則會(huì)中斷事務(wù)。針對(duì)第 2 和第 3 種情況，協(xié)調(diào)者認(rèn)為事務(wù)無(wú)法正常執(zhí)行，于是向各個(gè)參與者發(fā)出 abort 通知，請(qǐng)求退出預(yù)備狀態(tài)，具體步驟如下：

協(xié)調(diào)者向所有事務(wù)參與者發(fā)送 abort 通知；
參與者收到通知后中斷事務(wù)。

第三階段：事務(wù)提交

如果第二階段事務(wù)未中斷，那么本階段協(xié)調(diào)者將會(huì)依據(jù)事務(wù)執(zhí)行返回的結(jié)果來(lái)決定提交或回滾事務(wù)，分為 3 種情況：

所有的參與者都能正常執(zhí)行事務(wù)。
一個(gè)或多個(gè)參與者執(zhí)行事務(wù)失敗。
協(xié)調(diào)者等待超時(shí)。

針對(duì)第 1 種情況，協(xié)調(diào)者向各個(gè)參與者發(fā)起事務(wù)提交請(qǐng)求，具體步驟如下：

協(xié)調(diào)者向所有參與者發(fā)送事務(wù) commit 通知；
所有參與者在收到通知之后執(zhí)行 commit 操作，并釋放占有的資源；
參與者向協(xié)調(diào)者反饋事務(wù)提交結(jié)果。

針對(duì)第 2 和第 3 種情況，協(xié)調(diào)者認(rèn)為事務(wù)無(wú)法成功執(zhí)行，于是向各個(gè)參與者發(fā)送事務(wù)回滾請(qǐng)求，具體步驟如下：

協(xié)調(diào)者向所有參與者發(fā)送事務(wù) rollback 通知；
所有參與者在收到通知之后執(zhí)行 rollback 操作，并釋放占有的資源；
參與者向協(xié)調(diào)者反饋事務(wù)回滾結(jié)果。

在本階段如果因?yàn)閰f(xié)調(diào)者或網(wǎng)絡(luò)問(wèn)題，導(dǎo)致參與者遲遲不能收到來(lái)自協(xié)調(diào)者的 commit 或 rollback 請(qǐng)求，那么參與者將不會(huì)如兩階段提交中那樣陷入阻塞，而是等待超時(shí)后繼續(xù) commit，相對(duì)于兩階段提交雖然降低了同步阻塞，但仍然無(wú)法完全避免數(shù)據(jù)的不一致。兩階段提交協(xié)議中所存在的長(zhǎng)時(shí)間阻塞狀態(tài)發(fā)生的幾率還是非常低的，所以雖然三階段提交協(xié)議相對(duì)于兩階段提交協(xié)議對(duì)于數(shù)據(jù)強(qiáng)一致性更有保障，但是因?yàn)樾蕟?wèn)題，兩階段提交協(xié)議在實(shí)際系統(tǒng)中反而更加受寵。

TCC模式

TCC是Try、Confirm 和 Cancel三個(gè)單詞首字母縮寫(xiě),它們分別的職責(zé)是：

Try：負(fù)責(zé)預(yù)留資源（比如新建一條狀態(tài)=PENDING的訂單）;

做業(yè)務(wù)檢查，簡(jiǎn)單來(lái)說(shuō)就是不能預(yù)留已經(jīng)被占用的資源;

隔離預(yù)留資源。

Confirm：負(fù)責(zé)落地所預(yù)留的資源

真正的執(zhí)行業(yè)務(wù)使用try階段預(yù)留的資源,冪等。

Cancel：負(fù)責(zé)撤銷(xiāo)所預(yù)留的資源

需要用戶根據(jù)自己的業(yè)務(wù)場(chǎng)景實(shí)現(xiàn) Try、Confirm 和 Cancel 三個(gè)操作；事務(wù)發(fā)起方在一階段執(zhí)行 Try 方式，在二階段提交執(zhí)行 Confirm 方法，二階段回滾執(zhí)行 Cancel 方法。

關(guān)于預(yù)留資源要多說(shuō)兩句，資源都是有限的，因此預(yù)留資源都是有時(shí)效的，如果當(dāng)預(yù)留資源遲遲得不到Confirm——我們將這種情況稱為timeout——參與方會(huì)自行將其Cancel。也就是說(shuō)參與方對(duì)于資源具有自我管理能力，這樣可以避免因發(fā)起方的問(wèn)題導(dǎo)致資源被長(zhǎng)期占用。

TCC增加了業(yè)務(wù)檢查和撤銷(xiāo)事務(wù)的功能。同時(shí)，TCC將2PC數(shù)據(jù)庫(kù)層面的動(dòng)作提升到了服務(wù)層面，不同的是TCC的所有動(dòng)作都是一個(gè)本地事務(wù)，每個(gè)本地事務(wù)都在動(dòng)作完成后commit到數(shù)據(jù)庫(kù)：