云計算
背景
墨脫網站制作公司哪家好,找創新互聯建站!從網頁設計、網站建設、微信開發、APP開發、成都響應式網站建設公司等網站項目制作,到程序開發,運營維護。創新互聯建站自2013年起到現在10年的時間,我們擁有了豐富的建站經驗和運維經驗,來保證我們的工作的順利進行。專注于網站建設就選創新互聯建站。ACID
原子性(Atomicity)
一致性(Consistency)
隔離性(Isolation)
持久性(Durability)
CAP
一致性:在分布式系統中的所有數據備份,在同一時刻是否同樣的值。
可用性:在集群中一部分節點故障后,集群整體是否還能響應客戶端的讀寫請求。
分區容忍性:以實際效果而言,分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性,就意味著發生了分區的情況,必須就當前操作在C和A之間做出選擇。
BASE理論
我們無法做到強一致,但每個應用都可以根據自身的業務特點,采用適當的方式來使系統達到最終一致性。
解決方案
兩階段提交(2PC)
階段一
?階段二
情況1:當所有參與者均反饋 yes,提交事務
情況2:當有一個參與者反饋 no,回滾事務
問題
性能問題:所有參與者在事務提交階段處于同步阻塞狀態,占用系統資源,容易導致性能瓶頸。
可靠性問題:如果協調者存在單點故障問題,或出現故障,提供者將一直處于鎖定狀態。
?數據一致性問題:在階段 2 中,如果出現協調者和參與者都掛了的情況,有可能導致數據不一致。
優點:盡量保證了數據的強一致,適合對數據強一致要求很高的關鍵領域。(其實也不能100%保證強一致)。
缺點:實現復雜,犧牲了可用性,對性能影響較大,不適合高并發高性能場景。
三階段提交(3PC)
階段一
階段二
情況1:所有參與者均反饋 yes,協調者預執行事務
情況2:只要有一個參與者反饋 no,或者等待超時后協調者尚無法收到所有提供者的反饋,即中斷事務
階段三
情況 1:所有參與者均反饋 ack 響應,執行真正的事務提交
情況2:只要有一個參與者反饋 no,或者等待超時后協調組尚無法收到所有提供者的反饋,即回滾事務。
優點:相比二階段提交,三階段提交降低了阻塞范圍,在等待超時后協調者或參與者會中斷事務。避免了協調者單點問題。階段 3 中協調者出現問題時,參與者會繼續提交事務。
缺點:數據不一致問題依然存在,當在參與者收到 preCommit 請求后等待 do commite 指令時,此時如果協調者請求中斷事務,而協調者無法與參與者正常通信,會導致參與者繼續提交事務,造成數據不一致。
補償事務(TCC)
條件:
處理流程:
優點:
缺點:TCC 的 Try、Confirm 和 Cancel 操作功能要按具體業務來實現,業務耦合度較高,提高了開發成本。
本地消息表(消息隊列)
條件:?
服務消費者需要創建一張消息表,用來記錄消息狀態。
服務消費者和提供者需要支持冪等。
需要補償邏輯。
每個節點上起定時線程,檢查未處理完成或發出失敗的消息,重新發出消息,即重試機制和冪等性機制。
處理流程:
優點:從應用設計開發的角度實現了消息數據的可靠性,消息數據的可靠性不依賴于消息中間件,弱化了對 MQ 中間件特性的依賴。
缺點:與具體的業務場景綁定,耦合性強,不可公用。消息數據與業務數據同庫,占用業務系統資源。業務系統在使用關系型數據庫的情況下,消息服務性能會受到關系型數據庫并發性能的局限。
MQ事務消息(最終一致性)
條件:
處理流程:
優點:
缺點:
Sagas事務模型(最終一致性)
一、?事件/編排Choreography:沒有中央協調器(沒有單點風險)時,每個服務產生并聆聽其他服務的事件,并決定是否應采取行動。
處理流程:
優點:事件/編排是實現Saga模式的自然方式; 它很簡單,容易理解,不需要太多的努力來構建,所有參與者都是松散耦合的,因為他們彼此之間沒有直接的耦合。如果您的事務涉及2至4個步驟,則可能是非常合適的。
二、?命令/協調orchestrator:中央協調器負責集中處理事件的決策和業務邏輯排序。
優點:
缺點:協調器中集中太多邏輯的風險。
當前標題:調研|5種分布式事務解決方案優缺點對比
鏈接地址:http://vcdvsql.cn/article12/choedc.html
成都網站建設公司_創新互聯,為您提供網站設計、響應式網站、微信公眾號、品牌網站制作、移動網站建設、網站策劃
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯