.Net Core with 微服務(wù) - 分布式事務(wù) - 2PC、3PC

時(shí)間：2023-05-20 22:46:02 | 來源：網(wǎng)站運(yùn)營

時(shí)間：2023-05-20 22:46:02 來源：網(wǎng)站運(yùn)營

.Net Core with 微服務(wù) - 分布式事務(wù) - 2PC、3PC：最近比較忙，好久沒更新了。這次我們來聊一聊分布式事務(wù)。
在微服務(wù)體系下，我們的應(yīng)用被分割成多個(gè)服務(wù)，每個(gè)服務(wù)都配置一個(gè)數(shù)據(jù)庫。如果我們的服務(wù)劃分的不夠完美，那么為了完成業(yè)務(wù)會出現(xiàn)非常多的跨庫事務(wù)。即使按照 DDD 的原則來切分服務(wù)還是免不了有的業(yè)務(wù)場景需要多個(gè)業(yè)務(wù)同時(shí)提交成功或者同時(shí)回滾的場景。比如會員使用積分下訂單這個(gè)場景，那么會員服務(wù)的積分扣減需要跟訂單下單成功同時(shí)完成。如果下單成功，但是扣減積分接口失敗，那么就會造成數(shù)據(jù)的不一致性。這個(gè)時(shí)候我們就需要使用分布式事務(wù)來保證數(shù)據(jù)的一致性。
由于分布式事務(wù)要介紹的東西比較多，這一篇只介紹 2PC、3PC 的基本概念，所以 .net 相關(guān)的內(nèi)容大概也只會出現(xiàn)在標(biāo)題上一次，笑哭。

什么是 2PC

2PC 既 Two-phase Commit ，中文翻譯為二階段提交。2PC 要求每個(gè)事務(wù)的參與方都把一個(gè)事務(wù)抽象成2個(gè)階段。下面大概分析下 2PC 事務(wù)的流程。
首先提出2個(gè)概念：

1. 參與方
   分布式事務(wù)中所有需要同時(shí)進(jìn)入事務(wù)的業(yè)務(wù)方。
2. 協(xié)調(diào)器
   分布式環(huán)境下為了對多個(gè)事務(wù)參與方進(jìn)行統(tǒng)一的調(diào)度管理，我們需要一個(gè)調(diào)度器。

階段一

事務(wù)開始后，協(xié)調(diào)器下達(dá)事務(wù)開始的命令，每個(gè)參與方收到命令后開始執(zhí)行準(zhǔn)備階段（Prepare phase），所謂準(zhǔn)備階段就是執(zhí)行本地事物，這個(gè)時(shí)候資源被鎖定，但是不進(jìn)行提交。如果這個(gè)階段沒有發(fā)生異常，那么參與方會通知協(xié)調(diào)器“執(zhí)行成功”。如果某個(gè)參與方在這個(gè)階段失敗了，那么同樣通知協(xié)調(diào)器“執(zhí)行失敗”，協(xié)調(diào)器會給所有參與方發(fā)布回滾的命令。參與方在收到“回滾”命令后執(zhí)行回滾操作。

階段二

如果所有的參與方在階段一全部響應(yīng)成功，那么協(xié)調(diào)器就會給每個(gè)參與方發(fā)布執(zhí)行提交操作的命令。參與方收到提交命令后開始嘗試進(jìn)行事務(wù)提交。如果事務(wù)提交成功，參與方會通知協(xié)調(diào)器“提交成功”。待到所有的參與方全部回復(fù)“提交成功”，那么本次事務(wù)成功執(zhí)行。



到這里我們可以看到 2PC 模型跟數(shù)據(jù)庫的事務(wù)模型是高度契合的，所以 2PC 經(jīng)常用來把多個(gè)數(shù)據(jù)庫事物包裝成一個(gè)分布式事務(wù)的場景。事實(shí)上大多數(shù)數(shù)據(jù)庫如：oracle，mysql等自己已經(jīng)實(shí)現(xiàn)了基于XA協(xié)議的2PC 事務(wù)。

2PC 的問題

1. 在一階段，假設(shè)參與方A執(zhí)行事務(wù)成功并通知了協(xié)調(diào)器，參與方B執(zhí)行失敗，由于網(wǎng)絡(luò)的問題一直無法上報(bào)給協(xié)調(diào)器，這個(gè)時(shí)候會造成參與方A事務(wù)一直是等待提交狀態(tài)，阻塞整個(gè)業(yè)務(wù)。這個(gè)時(shí)候就需要引入超時(shí)機(jī)制，在一定時(shí)間內(nèi)沒收到協(xié)調(diào)器的指令后直接回滾事務(wù)。
2. 在一階段，假設(shè)參與方A執(zhí)行事務(wù)成功并通知了協(xié)調(diào)器，參與方B執(zhí)行成功，由于網(wǎng)絡(luò)的問題一直無法上報(bào)給協(xié)調(diào)器，這個(gè)時(shí)候會造成參與方A、參與方B事務(wù)一直是等待提交狀態(tài)，阻塞整個(gè)業(yè)務(wù)。這個(gè)時(shí)候不光在參與方A一側(cè)需要引入超時(shí)機(jī)制，在參與方B同樣需要進(jìn)入超時(shí)機(jī)制來自動回滾事務(wù)。
3. 在二階段，如果參與方A提交成功，參與方B因?yàn)槟承┰蛱峤皇?，或者是服?wù)器宕機(jī)或者是網(wǎng)絡(luò)原因B一致沒有收到提交的指令，這個(gè)時(shí)候就會造成數(shù)據(jù)不一致，這種情況 2PC 幾乎沒有補(bǔ)償能力，只能依靠后期手動修復(fù)數(shù)據(jù)。
4. 如果協(xié)調(diào)器在一階段中間掛了，那么跟以上1、2情況類似，需要通過超時(shí)機(jī)制來補(bǔ)償。
5. 如果協(xié)調(diào)器在二階段中間掛了，比如只給參與方A發(fā)送了提交請求，那么就會造成以上問題3類似的問題，造成數(shù)據(jù)不一致。
6. 2PC 因?yàn)橐蕾嚁?shù)據(jù)庫本地事務(wù)，我們知道事務(wù)一旦開啟就會阻塞后面的業(yè)務(wù)執(zhí)行。所以該方法在并發(fā)高的情況下會有比較大的性能問題。而且他所阻塞的時(shí)間遠(yuǎn)遠(yuǎn)高于單機(jī)事務(wù)，因?yàn)樗牡臅r(shí)間取決于執(zhí)行時(shí)間最長的那個(gè)參與方所執(zhí)行的事務(wù)。

3PC

由于 2PC 的眾多問題，又有人發(fā)明了 3PC 事務(wù)。
3PC 事務(wù)是對 2PC 的一次改進(jìn)：

1. 首先引入了超時(shí)機(jī)制避免事務(wù)長時(shí)間阻塞。
2. 3PC 在 2PC 的 Prepare phase 階段之前又加入了一個(gè)階段叫做 CanCommit 階段?，F(xiàn)在3個(gè)階段分別是：CanCommit、PreCommit、DoCommit 。后兩個(gè)階段大致可以映射到 2PC 的一階段跟二階段。那么CanCommit 階段是干嘛的呢？CanCommit 只是一次預(yù)檢，協(xié)調(diào)器先問一下各個(gè)參與者是否可以進(jìn)行事務(wù)，同時(shí)也校驗(yàn)一下當(dāng)前的網(wǎng)絡(luò)是否正常，參與者服務(wù)器有沒有宕機(jī)。經(jīng)過這一次校驗(yàn)后，至少可以比 2PC 安全一點(diǎn)，減少因?yàn)楫?dāng)前網(wǎng)絡(luò)故障服務(wù)宕機(jī)帶來的故障的概率。但是 3PC 任然無法完全解決問題，在 DoCommit 命令發(fā)布后，依然有可能部分參與者提交成功，部分失敗，2PC 數(shù)據(jù)不一致的問題 3PC 依然無法避免。

總結(jié)

以上簡單介紹了 2PC、3PC 分布式事務(wù)的原理。我們可以看到 2PC 在理想情況下是可以保證數(shù)據(jù)一致性的。但是在復(fù)雜的生產(chǎn)環(huán)境下服務(wù)器宕機(jī)、網(wǎng)絡(luò)故障的情況時(shí)有發(fā)生，最終導(dǎo)致數(shù)據(jù)的不一致，并且 2PC 的性能也差強(qiáng)人意。3PC 雖然改進(jìn)了 2PC 的一些缺點(diǎn)，但是仍然沒有解決掉最致命的數(shù)據(jù)不一致的問題、以及性能的問題。所以 2PC、3PC 并不是分布式事務(wù)的首選方案。那么下期我們將繼續(xù)這個(gè)話題，繼續(xù)介紹 TCC 分布式事務(wù)。

相關(guān)文章

NET Core with 微服務(wù) - 什么是微服務(wù)
.Net Core with 微服務(wù) - 架構(gòu)圖
.Net Core with 微服務(wù) - Ocelot 網(wǎng)關(guān)
.Net Core with 微服務(wù) - Consul 注冊中心
.Net Core with 微服務(wù) - Seq 日志聚合
.Net Core with 微服務(wù) - Elastic APM
.Net Core with 微服務(wù) - Consul 配置中心
.Net Core with 微服務(wù) - Polly 熔斷降級

關(guān)注我的公眾號一起玩轉(zhuǎn)技術(shù)