云計算

背景

墨脫網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站自2013年起到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

ACID

原子性（Atomicity）

一致性（Consistency）

隔離性（Isolation）

持久性（Durability）

CAP

一致性：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。

可用性：在集群中一部分節(jié)點故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。

分區(qū)容忍性：以實際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。

BASE理論

我們無法做到強一致，但每個應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

解決方案

兩階段提交（2PC）

階段一

?階段二

情況1：當(dāng)所有參與者均反饋 yes，提交事務(wù)

情況2：當(dāng)有一個參與者反饋 no，回滾事務(wù)

問題

性能問題：所有參與者在事務(wù)提交階段處于同步阻塞狀態(tài)，占用系統(tǒng)資源，容易導(dǎo)致性能瓶頸。

可靠性問題：如果協(xié)調(diào)者存在單點故障問題，或出現(xiàn)故障，提供者將一直處于鎖定狀態(tài)。

?數(shù)據(jù)一致性問題：在階段 2 中，如果出現(xiàn)協(xié)調(diào)者和參與者都掛了的情況，有可能導(dǎo)致數(shù)據(jù)不一致。

優(yōu)點：盡量保證了數(shù)據(jù)的強一致，適合對數(shù)據(jù)強一致要求很高的關(guān)鍵領(lǐng)域。（其實也不能100%保證強一致）。

缺點：實現(xiàn)復(fù)雜，犧牲了可用性，對性能影響較大，不適合高并發(fā)高性能場景。

三階段提交（3PC）

階段一

階段二

情況1：所有參與者均反饋 yes，協(xié)調(diào)者預(yù)執(zhí)行事務(wù)

情況2：只要有一個參與者反饋 no，或者等待超時后協(xié)調(diào)者尚無法收到所有提供者的反饋，即中斷事務(wù)

階段三

情況 1：所有參與者均反饋 ack 響應(yīng)，執(zhí)行真正的事務(wù)提交

情況2：只要有一個參與者反饋 no，或者等待超時后協(xié)調(diào)組尚無法收到所有提供者的反饋，即回滾事務(wù)。

優(yōu)點：相比二階段提交，三階段提交降低了阻塞范圍，在等待超時后協(xié)調(diào)者或參與者會中斷事務(wù)。避免了協(xié)調(diào)者單點問題。階段 3 中協(xié)調(diào)者出現(xiàn)問題時，參與者會繼續(xù)提交事務(wù)。

缺點：數(shù)據(jù)不一致問題依然存在，當(dāng)在參與者收到 preCommit 請求后等待 do commite 指令時，此時如果協(xié)調(diào)者請求中斷事務(wù)，而協(xié)調(diào)者無法與參與者正常通信，會導(dǎo)致參與者繼續(xù)提交事務(wù)，造成數(shù)據(jù)不一致。

補償事務(wù)（TCC）

條件：

處理流程：

優(yōu)點：

缺點：TCC 的 Try、Confirm 和 Cancel 操作功能要按具體業(yè)務(wù)來實現(xiàn)，業(yè)務(wù)耦合度較高，提高了開發(fā)成本。

本地消息表（消息隊列）

條件：?

服務(wù)消費者需要創(chuàng)建一張消息表，用來記錄消息狀態(tài)。

服務(wù)消費者和提供者需要支持冪等。

需要補償邏輯。

每個節(jié)點上起定時線程，檢查未處理完成或發(fā)出失敗的消息，重新發(fā)出消息，即重試機制和冪等性機制。

處理流程：

優(yōu)點：從應(yīng)用設(shè)計開發(fā)的角度實現(xiàn)了消息數(shù)據(jù)的可靠性，消息數(shù)據(jù)的可靠性不依賴于消息中間件，弱化了對 MQ 中間件特性的依賴。

缺點：與具體的業(yè)務(wù)場景綁定，耦合性強，不可公用。消息數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)同庫，占用業(yè)務(wù)系統(tǒng)資源。業(yè)務(wù)系統(tǒng)在使用關(guān)系型數(shù)據(jù)庫的情況下，消息服務(wù)性能會受到關(guān)系型數(shù)據(jù)庫并發(fā)性能的局限。

MQ事務(wù)消息（最終一致性）

條件：

處理流程：

優(yōu)點：

缺點：

Sagas事務(wù)模型（最終一致性）

一、?事件/編排Choreography：沒有中央?yún)f(xié)調(diào)器（沒有單點風(fēng)險）時，每個服務(wù)產(chǎn)生并聆聽其他服務(wù)的事件，并決定是否應(yīng)采取行動。

處理流程：

優(yōu)點：事件/編排是實現(xiàn)Saga模式的自然方式; 它很簡單，容易理解，不需要太多的努力來構(gòu)建，所有參與者都是松散耦合的，因為他們彼此之間沒有直接的耦合。如果您的事務(wù)涉及2至4個步驟，則可能是非常合適的。

二、?命令/協(xié)調(diào)orchestrator：中央?yún)f(xié)調(diào)器負(fù)責(zé)集中處理事件的決策和業(yè)務(wù)邏輯排序。

優(yōu)點：

缺點：協(xié)調(diào)器中集中太多邏輯的風(fēng)險。

當(dāng)前標(biāo)題：調(diào)研|5種分布式事務(wù)解決方案優(yōu)缺點對比
鏈接地址：http://jinyejixie.com/article12/choedc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計、響應(yīng)式網(wǎng)站、微信公眾號、品牌網(wǎng)站制作、移動網(wǎng)站建設(shè)、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)