您好,登錄后才能下訂單哦!
本篇內容介紹了“Java分布式理論是什么”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
TCC:Try-Confirm-Cancel
Try階段:完成所有的業務檢查,預留(鎖定)業務資源
Confirm階段:確認執行業務操作,
Cancel階段: 業務最終失敗,或者部分業務資源鎖定失敗,釋放已鎖定的資源
以常見的下單時使用優惠券的場景為例,涉及三個應用:訂單服務、庫存服務、優惠券服務:
1、用戶提交下單請求 2、鎖定商品庫存 3、鎖定優惠券 4、訂單落庫
Try階段(用戶下單):
依次同步調用鎖定商品庫存、鎖定優惠券
Confirm階段(用戶支付完成):
更新訂單狀態為已支付
調用庫存扣減、優惠券核銷。可通過本地任務表或消息隊列保證最終處理成功。
Cancel階段:
場景一:鎖定商品庫存成功,鎖定優惠券業務處理失敗。整個業務操作失敗,釋放前一步鎖定的商品庫存。
場景二:庫存和優惠券都鎖定成功了,但是訂單超時未支付自動關閉,或者用戶主動取消。釋放對應的庫存和優惠券。
TCC使用了加鎖粒度較小的柔性事務。如上面的流程,鎖定庫存、鎖定優惠券、訂單落庫三個操作,并沒有遵循ACID的原則包在一個大的事務中整體進行原子性的提交。而是變成各自獨立應用處理的小事務分開處理。因此也無法保證在同一時刻各個數據源的數據是對應的(強一致性),某些時刻會出現鎖定了庫存但是訂單還沒有落庫。TCC追求的是最終一致性,根據業務最終的成功與否,變更參與者的最終狀態和業務狀態一致。
看到這,了解分布式中BASE理論的會想起軟狀態和最終一致性,TCC算是BASE理論的一種體現。
BASE:Basically Available(基本可用),Soft state(軟狀態),和 Eventually consistent(最終一致性)
基本可用:保證核心功能可用。犧牲邊緣功能和部分響應時間。比如電商中,核心業務為下單,物流查詢、商品評論可適當降級處理。
軟狀態:因為延遲等因素導致的各個節點在某時刻不一致的狀態。
最終一致:最終保持各個節點的數據一致。如上述場景。
然后我們又聽到2PC的概念,也是分為兩階段,先預留資源再提交,這不和TCC一樣嗎。的確,二者的兩階段提交的思想確實是一樣的。
2PC和TCC的兩階段補償的區別
但我們說的2PC指的是基于XA規范的兩階段提交。而XA規范定義的DTP分布式事務模型中TM和RM的交互。
DTP分布式事務模型中的三個角色:AP(應用程序)、TM(事務管理器)、RM(資源管理器)
由此總結
2PC是針對是資源層面的(這里的資源包括數據庫、消息隊列等)事務操作,他的協調者和參與者分別是事務管理器和資源管理器。關注的是多個數據源和數據副本之間的同步,為了保證強一致性,在整個兩階段包在一個大事務中,會一直持有資源的鎖。典型的例子如Mysql的先寫Redo日志再寫BinLog就是兩階段的提交。而像Springboot開發者只需要加個@Transactional注解即可,無需關心兩階段提交的細節。
TCC是針對業務應用程序層的,協調者是應用程序,參與者也是應用程序。關注的是應用之間數據的協調。對應的鎖定釋放邏輯包括冪等邏輯都需要開發者實現。
3PC
但是兩階段提交是完美的么,答案是否定的。
這里我們先不分什么TCC的兩階段提交還是基于XA的2PC了,再去想想剛才的下單場景有什么問題:
假如鎖定了庫存之后,應用或者說協調者崩潰了,后續的工作都沒完成。前期被鎖定的庫存沒有人來釋放了,最終一致性出現問題了。
3PC即是在這種背景下產生的
3PC中增加了超時機制,來避免上述資源狀態永遠無法實現最終一致的問題,然而超時了到底應該是回滾釋放還是提交確認呢?
先看看三個階段干了什么
階段1:查詢資源是否可用,注意只查詢不鎖定。所有參與者都可提交再進行下一段,降低預留資源時才發現部分參與者不可提交產生回滾的概率。
階段2:鎖定資源
階段3:提交確認
參與者收到PreCommit后返回超時,釋放預留資源,使整個事務在進入階段3之前完全回滾。
參與者收到DoCommit后返回超時,仍然提交確認。因為能進到階段3說明協調者已經完成了階段2對所有參與者的資源預留鎖定。雖然大概率整個事務會成功,但如此畢竟不是完全嚴謹的,腦裂問題仍然存在,仍然會出現某個參與者提交其他參與者返回失敗這樣數據不一致的問題。
腦裂問題:協調者就是分布式/集群中的大腦,腦裂即協調者(領導者)的作用失效了。比如崩潰了,或者出現了多個協調者,使得參與者的行為沒有被統一調度而出現不一致的情況。
“Java分布式理論是什么”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。