分布式事務(wù)淺析及簡單實(shí)現(xiàn)
在分布式系統(tǒng)中,為了保證數(shù)據(jù)的高可用,通常,我們會將數(shù)據(jù)保留多個(gè)副本(replica),這些副本會放置在不同的物理的機(jī)器上。為了對用戶提供正確的 CRUD 等語義,我們需要保證這些放置在不同物理機(jī)器上的副本是一致的。分布式事務(wù)在現(xiàn)在遍地都是分布式部署的系統(tǒng)中幾乎是必要的。
我們先聊一下啥是事務(wù)?
分布式事務(wù)、事務(wù)隔離級別、ACID我相信大家這些東西都耳熟能詳了,那什么是事務(wù)呢?
概念:
一般是指要做的或所做的事情。
指作為單個(gè)邏輯工作單元執(zhí)行的一系列操作,要么全部執(zhí)行,要么全部不執(zhí)行。
簡單的說,事務(wù)就是并發(fā)控制的單位,是用戶定義的一個(gè)操作序列。
特性:
事務(wù)是恢復(fù)和并發(fā)控制的基本單位。
事務(wù)應(yīng)該具有4個(gè)屬性:原子性、一致性、隔離性、持久性。這四個(gè)屬性通常稱為ACID特性。
- 原子性(atomicity):一個(gè)事務(wù)是一個(gè)不可分割的工作單位,事務(wù)中包括的操作要么都做,要么都不做。
- 一致性(consistency):事務(wù)必須是使數(shù)據(jù)庫從一個(gè)一致性狀態(tài)變到另一個(gè)一致性狀態(tài)。一致性與原子性是密切相關(guān)的。
- 隔離性(isolation):一個(gè)事務(wù)的執(zhí)行不能被其他事務(wù)干擾。即一個(gè)事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對并發(fā)的其他事務(wù)是隔離的,并發(fā)執(zhí)行的各個(gè)事務(wù)之間不能互相干擾。
- 持久性(durability):持久性也稱永久性(permanence),指一個(gè)事務(wù)一旦提交,它對數(shù)據(jù)庫中數(shù)據(jù)的改變就應(yīng)該是永久性的。接下來的其他操作或故障不應(yīng)該對其有任何影響。
那什么是分布式事務(wù)呢?
這里舉個(gè)簡單的例子:大家可以想一下,你下單流程可能涉及到10多個(gè)環(huán)節(jié),你下單付錢都成功了,但是你優(yōu)惠券扣減失敗了,積分新增失敗了,前者公司會被薅羊毛,后者用戶會不開心,
但是這些都在不同的服務(wù)怎么保證大家都成功呢? 分布式事務(wù)。
分布式事務(wù)是指會涉及到操作多個(gè)數(shù)據(jù)庫的事務(wù)。其實(shí)就是將對同一庫事務(wù)的概念擴(kuò)大到了對多個(gè)庫的事務(wù)。目的是為了保證分布式系統(tǒng)中的數(shù)據(jù)一致性。分布式事務(wù)處理的關(guān)鍵是必須有一種方法可以知道事務(wù)在任何地方所做的所有動作,提交或回滾事務(wù)的決定必須產(chǎn)生統(tǒng)一的結(jié)果(全部提交或全部回滾)
比較著名的分布式事務(wù)有:
- 2pc(兩段式提交)
- 3pc(三段式提交)
- TCC(Try、Confirm、Cancel)
- 半消息/最終一致性(RocketMQ)
這里我就介紹下最簡單的2pc(兩段式),以及大家以后可能比較常用的半消息事務(wù)也就是最終一致性,別的事務(wù)都大同小異,都有很多優(yōu)點(diǎn)。
當(dāng)然也都有種種弊端:
例如長時(shí)間鎖定數(shù)據(jù)庫資源,導(dǎo)致系統(tǒng)的響應(yīng)不快,并發(fā)上不去。
網(wǎng)絡(luò)抖動出現(xiàn)腦裂情況,導(dǎo)致事物參與者,不能很好地執(zhí)行協(xié)調(diào)者的指令,導(dǎo)致數(shù)據(jù)不一致。
單點(diǎn)故障:例如事物協(xié)調(diào)者,在某一時(shí)刻宕機(jī),雖然可以通過選舉機(jī)制產(chǎn)生新的Leader,但是這過程中,必然出現(xiàn)問題,而TCC,只有強(qiáng)悍的技術(shù)團(tuán)隊(duì),才能支持開發(fā),成本太高。
開始介紹這個(gè)兩個(gè)事物吧。
2pc(兩段式提交) :
第一階段:準(zhǔn)備階段(投票階段) 和第二階段:提交階段(執(zhí)行階段)
2pc(兩段式提交)可以說是分布式事務(wù)的最開始的樣子了,像極了媒婆,就是通過消息中間件或者全部事務(wù)管理來協(xié)調(diào)多個(gè)系統(tǒng),在兩個(gè)系統(tǒng)操作事務(wù)的時(shí)候都鎖定資源但是不提交事務(wù),等兩者都準(zhǔn)備好了,告訴消息中間件或者全部事務(wù)管理者,然后再分別提交事務(wù)。不管最后結(jié)果如何,第二階段都會結(jié)束當(dāng)前事務(wù)
但是問題所在是,如果A系統(tǒng)事務(wù)提交成功了,但是B系統(tǒng)在提交的時(shí)候網(wǎng)絡(luò)波動或者各種原因提交失敗了,其實(shí)還是會失敗的。
最終一致性:
整個(gè)流程中,我們能保證是:
- 業(yè)務(wù)主動方本地事務(wù)提交失敗,業(yè)務(wù)被動方不會收到消息的投遞。
- 只要業(yè)務(wù)主動方本地事務(wù)執(zhí)行成功,那么消息服務(wù)一定會投遞消息給下游的業(yè)務(wù)被動方,并最終保證業(yè)務(wù)被動方一定能成功消費(fèi)該消息(消費(fèi)成功或失敗,即最終一定會有一個(gè)最終態(tài))。
- 不過呢技術(shù)就是這樣,各種極端的情況我們都需要考慮,也很難有完美的方案,所以才會有這么多的方案三段式、TCC、最大努力通知等等分布式事務(wù)方案,大家只需要知道為啥要做,做了有啥好處,有啥壞處,在實(shí)際開發(fā)的時(shí)候都注意下就好了,系統(tǒng)都是根據(jù)業(yè)務(wù)場景設(shè)計(jì)出來的,離開業(yè)務(wù)的技術(shù)沒有意義,離開技術(shù)的業(yè)務(wù)沒有底氣。
【本文是51CTO專欄機(jī)構(gòu)“AiChinaTech”的原創(chuàng)文章,微信公眾號( id: tech-AI)”】