分布式事務(wù)之深入理解什么是2PC、3PC及TCC協(xié)議?-創(chuàng)新互聯(lián)

前言

在上一篇文章《教你一手如何基于RocketMQ搭建生產(chǎn)級消息集群》中給大家介紹了基于RocketMQ如何搭建生產(chǎn)級消息集群。因為本系列文章最終的目的是介紹基于RocketMQ的事物消息來解決分布式系統(tǒng)中的數(shù)據(jù)一致性問題,所以先給大家率先介紹了RocketMQ消息集群的搭建。

目前創(chuàng)新互聯(lián)已為千余家的企業(yè)提供了網(wǎng)站建設(shè)、域名、雅安服務(wù)器托管、網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計、休寧縣網(wǎng)站維護等服務(wù),公司將堅持客戶導向、應(yīng)用為本的策略,正道將秉承"和諧、參與、激情"的文化,與客戶和合作伙伴齊心協(xié)力一起成長,共同發(fā)展。

原本是想著在這篇文章中直接介紹RocketMQ的事務(wù)消息特性,但是在梳理的過程中作者發(fā)現(xiàn)對于分布式事務(wù)的概念,可能還會有很多同學不理解或者理解得不是很深刻的地方,而跳過這些基本概念直接去學習上層的實踐可能并不是一件很好的事情,因此在這篇文章中,作者打算重點給大家先介紹下分布式事務(wù)相關(guān)的基本概念,諸如分布式事務(wù)、2PC、3PC、TCC之類的基本問題,之后再單獨去介紹RocketMQ事務(wù)消息相關(guān)的實踐。

數(shù)據(jù)庫事務(wù)的概念

在講述分布式事務(wù)的概念之前,我們先來回顧下事務(wù)相關(guān)的一些概念。

事務(wù)的基本概念:

就是一個程序執(zhí)行單元,里面的操作要么全部執(zhí)行成功,要么全部執(zhí)行失敗,不允許只成功一半另外一半執(zhí)行失敗的事情發(fā)生。例如一段事務(wù)代碼做了兩次數(shù)據(jù)庫更新操作,那么這兩次數(shù)據(jù)庫操作要么全部執(zhí)行成功,要么全部回滾。

事務(wù)的基本特性

我們知道事務(wù)有4個非常重要的特性,即我們常說的(ACID)。

Atomicity(原子性):是說事務(wù)是一個不可分割的整體,所有操作要么全做,要么全不做;只要事務(wù)中有一個操作出錯,回滾到事務(wù)開始前的狀態(tài)的話,那么之前已經(jīng)執(zhí)行的所有操作都是無效的,都應(yīng)該回滾到開始前的狀態(tài)。

Consistency(一致性):是說事務(wù)執(zhí)行前后,數(shù)據(jù)從一個狀態(tài)到另一個狀態(tài)必須是一致的,比如A向B轉(zhuǎn)賬( A、B的總金額就是一個一致性狀態(tài)),不可能出現(xiàn)A扣了錢,B卻沒收到的情況發(fā)生。

Isolation(隔離性): 多個并發(fā)事務(wù)之間相互隔離,不能互相干擾。關(guān)于事務(wù)的隔離性,可能不是特別好理解,這里的并發(fā)事務(wù)是指兩個事務(wù)操作了同一份數(shù)據(jù)的情況;而對于并發(fā)事務(wù)操作同一份數(shù)據(jù)的隔離性問題,則是要求不能出現(xiàn)臟讀、幻讀的情況,即事務(wù)A不能讀取事務(wù)B還沒有提交的數(shù)據(jù),或者在事務(wù)A讀取數(shù)據(jù)進行更新操作時,不允許事務(wù)B率先更新掉這條數(shù)據(jù)。而為了解決這個問題,常用的手段就是加鎖了,對于數(shù)據(jù)庫來說就是通過數(shù)據(jù)庫的相關(guān)鎖機制來保證。

Durablity(持久性):事務(wù)完成后,對數(shù)據(jù)庫的更改是永久保存的,不能回滾。

關(guān)于數(shù)據(jù)庫事務(wù)的基本概念大家可以去網(wǎng)上搜一下,這里只是給大家回顧下事務(wù)的基本概念及特性,諸如事務(wù)并發(fā)問題、事務(wù)隔離級別等大家如有遺忘可以去回顧下(tips:面試經(jīng)常會問到的問題哦)。

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

以上內(nèi)容我們回顧了下事務(wù)的基本概念,那么分布式事務(wù)又是個什么概念呢?它與數(shù)據(jù)庫事務(wù)之間又有什么區(qū)別呢?

其實分布式事務(wù)從實質(zhì)上看與數(shù)據(jù)庫事務(wù)的概念是一致的,既然是事務(wù)也就需要滿足事務(wù)的基本特性(ACID),只是分布式事務(wù)相對于本地事務(wù)而言其表現(xiàn)形式有很大的不同。舉個例子,在一個JVM進程中如果需要同時操作數(shù)據(jù)庫的多條記錄,而這些操作需要在一個事務(wù)中,那么我們可以通過數(shù)據(jù)庫提供的事務(wù)機制(一般是數(shù)據(jù)庫鎖)來實現(xiàn)。

而隨著這個JVM進程(應(yīng)用)被拆分成了微服務(wù)架構(gòu),原本一個本地邏輯執(zhí)行單元被拆分到了多個獨立的微服務(wù)中,這些微服務(wù)又分別操作不同的數(shù)據(jù)庫和表,服務(wù)之間通過網(wǎng)絡(luò)調(diào)用。

舉個例子:服務(wù)A收到一筆購物下單請求后,需要調(diào)用服務(wù)B去支付,支付成功則處理購物訂單為待發(fā)貨狀態(tài),否則就需要將購物訂單處理為失敗狀態(tài)。(如圖所示)

分布式事務(wù)之深入理解什么是2PC、3PC及TCC協(xié)議?

在上面這個例子中會不會出現(xiàn)服務(wù)B支付成功了,但是由于網(wǎng)絡(luò)調(diào)用的問題沒有通知到服務(wù)A,導致用戶付了錢,但是購物訂單無法顯示支付成功的狀態(tài)呢?

答案是這種情況是普遍存在的,因為服務(wù)B在處理成功后需要向服務(wù)A發(fā)送網(wǎng)絡(luò)請求,而這個過程是極有可能失敗的。那么如何確保“服務(wù)A->服務(wù)B”這個過程能夠組成一個事務(wù),要么全部成功、要么全部失敗呢?而這就是典型的需要通過分布式事務(wù)解決的問題。

分布式事務(wù)是為了解決微服務(wù)架構(gòu)(形式都是分布式系統(tǒng))中不同節(jié)點之間的數(shù)據(jù)一致性問題。這個一致性問題本質(zhì)上解決的也是傳統(tǒng)事務(wù)需要解決的問題,即一個請求在多個微服務(wù)調(diào)用鏈中,所有服務(wù)的數(shù)據(jù)處理要么全部成功,要么全部回滾。當然分布式事務(wù)問題的形式可能與傳統(tǒng)事務(wù)會有比較大的差異,但是問題本質(zhì)是一致的,都是要求解決數(shù)據(jù)的一致性問題。

而分布式事務(wù)的實現(xiàn)方式有很多種,最具有代表性的是由Oracle Tuxedo系統(tǒng)提出的XA分布式事務(wù)協(xié)議。XA協(xié)議包括兩階段提交(2PC)三階段提交(3PC)兩種實現(xiàn),接下來我們分別來介紹下這兩種實現(xiàn)方式的原理。

兩階段提交(2PC)

兩階段提交又稱2PC(two-phase commit protocol),2pc是一個非常經(jīng)典的強一致、中心化的原子提交協(xié)議。這里所說的中心化是指協(xié)議中有兩類節(jié)點:一個是中心化協(xié)調(diào)者節(jié)點(coordinator)和N個參與者節(jié)點(partcipant)。

下面我們就以一個盡量貼近實際業(yè)務(wù)場景的操作來舉例:"假設(shè)在一個分布式架構(gòu)的系統(tǒng)中事務(wù)的發(fā)起者通過分布式事務(wù)協(xié)調(diào)者(如RocketMQ,在早期RocketMQ版本不提供事務(wù)消息特性時,有些公司會自己研發(fā)一個基于MQ的可靠消息服務(wù)來實現(xiàn)一定的分布式事務(wù)的特性)分別向應(yīng)用服務(wù)A、應(yīng)用服務(wù)B發(fā)起處理請求,二者在處理的過程中會分別操作自身服務(wù)的數(shù)據(jù)庫,現(xiàn)在要求應(yīng)用服務(wù)A、應(yīng)用服務(wù)B的數(shù)據(jù)處理操作要在一個事務(wù)里"?

在上面這個例子中如果采用兩階段提交來實現(xiàn)分布式事務(wù),那么其運行原理應(yīng)該是個什么樣的呢?(如

創(chuàng)新互聯(lián)www.cdcxhl.cn,專業(yè)提供香港、美國云服務(wù)器,動態(tài)BGP最優(yōu)骨干路由自動選擇,持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證, 機房獨有T級流量清洗系統(tǒng)配攻擊溯源,準確進行流量調(diào)度,確保服務(wù)器高可用性。佳節(jié)活動現(xiàn)已開啟,新人活動云服務(wù)器買多久送多久。

分享文章:分布式事務(wù)之深入理解什么是2PC、3PC及TCC協(xié)議?-創(chuàng)新互聯(lián)
網(wǎng)站路徑:http://muchs.cn/article8/ddccop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站改版、做網(wǎng)站、自適應(yīng)網(wǎng)站Google、網(wǎng)站設(shè)計公司、網(wǎng)站制作

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

網(wǎng)站建設(shè)網(wǎng)站維護公司