怎么理解web開發(fā)中的分布式事務(wù)

這篇文章主要講解了“怎么理解web開發(fā)中的分布式事務(wù)”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么理解web開發(fā)中的分布式事務(wù)”吧！

cap

C：一致性被稱為原子對象，任何的讀寫都應(yīng)該看起來是“原子”，或串行的。寫后面的讀一定能讀到前面寫的內(nèi)容，所有的讀寫請求都好像被全局排序。

A：對任何非失敗節(jié)點都應(yīng)該在有限時間內(nèi)給出請求的回應(yīng)。(請求的可終止性)

P：允許節(jié)點之間丟失任意多的消息，當(dāng)網(wǎng)絡(luò)分區(qū)發(fā)生時，節(jié)點之間的消息可能會完全丟失

個人理解:

1. 對于C，就是保證在一個時間點各個節(jié)點的狀態(tài)是一致的，而A是在用戶的視角看來各個節(jié)點都是正常的，P就是在節(jié)點看開各個節(jié)點都是正常連接

2. 但在分布式環(huán)境中，多實例部署是基本條件，因為網(wǎng)絡(luò)的不可靠性，造成了P成了硬性條件，所以分布式系統(tǒng)基本都是cp和ap的

base

1. 基本可用(Basically Available)

2. 軟狀態(tài)(Soft State)

3. 最終一致性(Eventually Consistent)

個人理解:

1. base理論落地基本都是ap的系統(tǒng)，分布式事務(wù)和業(yè)務(wù)有著強耦合的關(guān)系，因為基本上業(yè)務(wù)層面要維持一個中間狀態(tài)好讓事務(wù)可以有回滾余地而不破壞數(shù)據(jù)

2. 其次因為有中間狀態(tài)所以在事務(wù)的過程中基本都是最終一致

xa

如圖基本分以下三種角色

1. AP 應(yīng)用程序

2. RM 資源管理器

3. TM 事務(wù)管理器

個人理解:

1. 基本各個資源管理器要實現(xiàn)各自的資源管理接口

2. 應(yīng)用程序向資源管理器申請資源，然后對資源的修改不是直接通知資源管理器，而是預(yù)先準(zhǔn)備好，然后由三方的事務(wù)管理器統(tǒng)一進(jìn)行修改

3. 使用該協(xié)議的系統(tǒng)基本都是cp類型的系統(tǒng)

2pc/3pc

2pc：

個人理解:

1. 在prepare階段對事務(wù)執(zhí)行完畢剩下事務(wù)提交，只要一處執(zhí)行出問題就觸發(fā)事務(wù)回滾

2. 在提交階段由于網(wǎng)絡(luò)問題可能會有不一致的問題

3. 各個事務(wù)之間相互依賴成功，鎖定資源的時間過長(阻塞時間過長)

4. 對于事務(wù)協(xié)調(diào)器有超時重新選舉，但是各個服務(wù)沒有超時機制

3pc：

個人理解:

在2pc之上增加了一層，個人理解這一層是為了輔助超時階段，因為在preCommit階段事務(wù)已經(jīng)就剩下提交其他服務(wù)也都確認(rèn)成功，最后每個服務(wù)都會啟動一個超時計劃，到時直接提交而不是等待協(xié)調(diào)器來docommit,  而docommit就是提交命令，但是各個服務(wù)可能因為網(wǎng)絡(luò)無法接收所以有個超時機制，也就是為了彌補2pc中的阻塞過長和服務(wù)端沒有超時機制

tcc

個人理解:

1. tcc本質(zhì)就是base中的業(yè)務(wù)提供一種中間態(tài)，通過準(zhǔn)備提交和回滾來完成整體事務(wù)

2. 整體增加了事務(wù)管理器來自動化的進(jìn)行管理事務(wù)的進(jìn)程，比如宕機后事務(wù)管理器會定時的去執(zhí)行日志記錄中事務(wù)的進(jìn)程保證最終一致性

3. 一般分布式事務(wù)都會傳遞全局事務(wù)id來標(biāo)識事務(wù)和解決冪等性

sega

個人理解sega很像2pc但是sega的事務(wù)都是自己提交自己的，對于集中式出問題由主業(yè)務(wù)進(jìn)行回滾或者重試，對于分布式而是遞歸的形式進(jìn)行回滾

上述的幾個問題

1. 整體上我這樣理解，sega是最終一致性的，但是又不會有base的中間狀態(tài)，所以會有隔離性的問題，容易出現(xiàn)幻讀重復(fù)度，讀更改等各種問題，對于解決方案一般都是sega對應(yīng)的框架自行提供全局讀寫鎖來進(jìn)行提供隔離性

2. 對于sagas框架來看，他實現(xiàn)了事務(wù)協(xié)調(diào)器來簡化事務(wù)的回滾和重試，實現(xiàn)了一套自行生成回滾sql的機制來進(jìn)行

3. 對于sagas還有很多設(shè)計，目前個人沒有時間研究后續(xù)研究透了會重寫相關(guān)sagas的問題(對于sagas歷史好像最開始是阿里收費項目gks,當(dāng)時看人反匯編代碼說實現(xiàn)可能是自動生成回滾代碼的tcc，現(xiàn)在看來是saga的模式加全局鎖)

sega2種回滾方案

1. backward  recovery，向后恢復(fù)，補償所有已完成的事務(wù)，如果任一子事務(wù)失敗。即上面提到的第二種執(zhí)行順序，其中j是發(fā)生錯誤的sub-transaction，這種做法的效果是撤銷掉之前所有成功的sub-transation，使得整個Saga的執(zhí)行結(jié)果撤銷。

2. forward recovery，向前恢復(fù)，重試失敗的事務(wù)，假設(shè)每個子事務(wù)最終都會成功。適用于必須要成功的場景，執(zhí)行順序是類似于這樣的：T1, T2,  ..., Tj(失敗), Tj(重試),..., Tn，其中j是發(fā)生錯誤的sub-transaction。該情況下不需要Ci

集中式

分布式

消息事務(wù)/本地消息事務(wù)

感謝各位的閱讀，以上就是“怎么理解web開發(fā)中的分布式事務(wù)”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對怎么理解web開發(fā)中的分布式事務(wù)這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！