本篇內(nèi)容介紹了“Java分布式理論是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名與空間、網(wǎng)頁空間、營銷軟件、網(wǎng)站建設(shè)、陸河網(wǎng)站維護、網(wǎng)站推廣。

柔性事務(wù)TCC

TCC：Try-Confirm-Cancel

Try階段：完成所有的業(yè)務(wù)檢查，預(yù)留(鎖定)業(yè)務(wù)資源

Confirm階段：確認(rèn)執(zhí)行業(yè)務(wù)操作，

Cancel階段： 業(yè)務(wù)最終失敗，或者部分業(yè)務(wù)資源鎖定失敗，釋放已鎖定的資源

以常見的下單時使用優(yōu)惠券的場景為例，涉及三個應(yīng)用：訂單服務(wù)、庫存服務(wù)、優(yōu)惠券服務(wù)：

1、用戶提交下單請求
2、鎖定商品庫存
3、鎖定優(yōu)惠券
4、訂單落庫

Try階段（用戶下單）：
        依次同步調(diào)用鎖定商品庫存、鎖定優(yōu)惠券
Confirm階段（用戶支付完成）：
       更新訂單狀態(tài)為已支付
       調(diào)用庫存扣減、優(yōu)惠券核銷。可通過本地任務(wù)表或消息隊列保證最終處理成功。
Cancel階段： 
        場景一：鎖定商品庫存成功，鎖定優(yōu)惠券業(yè)務(wù)處理失敗。整個業(yè)務(wù)操作失敗，釋放前一步鎖定的商品庫存。
        場景二：庫存和優(yōu)惠券都鎖定成功了，但是訂單超時未支付自動關(guān)閉，或者用戶主動取消。釋放對應(yīng)的庫存和優(yōu)惠券。

TCC使用了加鎖粒度較小的柔性事務(wù)。如上面的流程，鎖定庫存、鎖定優(yōu)惠券、訂單落庫三個操作，并沒有遵循ACID的原則包在一個大的事務(wù)中整體進行原子性的提交。而是變成各自獨立應(yīng)用處理的小事務(wù)分開處理。因此也無法保證在同一時刻各個數(shù)據(jù)源的數(shù)據(jù)是對應(yīng)的（強一致性），某些時刻會出現(xiàn)鎖定了庫存但是訂單還沒有落庫。TCC追求的是最終一致性，根據(jù)業(yè)務(wù)最終的成功與否，變更參與者的最終狀態(tài)和業(yè)務(wù)狀態(tài)一致。

看到這，了解分布式中BASE理論的會想起軟狀態(tài)和最終一致性，TCC算是BASE理論的一種體現(xiàn)。

BASE理論

BASE：Basically Available(基本可用)，Soft state（軟狀態(tài)）,和 Eventually consistent（最終一致性）

 基本可用：保證核心功能可用。犧牲邊緣功能和部分響應(yīng)時間。比如電商中，核心業(yè)務(wù)為下單，物流查詢、商品評論可適當(dāng)降級處理。

軟狀態(tài)：因為延遲等因素導(dǎo)致的各個節(jié)點在某時刻不一致的狀態(tài)。

最終一致：最終保持各個節(jié)點的數(shù)據(jù)一致。如上述場景。

2PC和3PC

然后我們又聽到2PC的概念，也是分為兩階段，先預(yù)留資源再提交，這不和TCC一樣嗎。的確，二者的兩階段提交的思想確實是一樣的。

2PC和TCC的兩階段補償?shù)膮^(qū)別

但我們說的2PC指的是基于XA規(guī)范的兩階段提交。而XA規(guī)范定義的DTP分布式事務(wù)模型中TM和RM的交互。

DTP分布式事務(wù)模型中的三個角色：AP(應(yīng)用程序)、TM（事務(wù)管理器）、RM（資源管理器）

由此總結(jié)

2PC是針對是資源層面的（這里的資源包括數(shù)據(jù)庫、消息隊列等）事務(wù)操作，他的協(xié)調(diào)者和參與者分別是事務(wù)管理器和資源管理器。關(guān)注的是多個數(shù)據(jù)源和數(shù)據(jù)副本之間的同步，為了保證強一致性，在整個兩階段包在一個大事務(wù)中，會一直持有資源的鎖。典型的例子如MySQL的先寫Redo日志再寫B(tài)inLog就是兩階段的提交。而像Springboot開發(fā)者只需要加個@Transactional注解即可，無需關(guān)心兩階段提交的細節(jié)。

TCC是針對業(yè)務(wù)應(yīng)用程序?qū)拥?，協(xié)調(diào)者是應(yīng)用程序，參與者也是應(yīng)用程序。關(guān)注的是應(yīng)用之間數(shù)據(jù)的協(xié)調(diào)。對應(yīng)的鎖定釋放邏輯包括冪等邏輯都需要開發(fā)者實現(xiàn)。

3PC

但是兩階段提交是完美的么，答案是否定的。

這里我們先不分什么TCC的兩階段提交還是基于XA的2PC了，再去想想剛才的下單場景有什么問題：

假如鎖定了庫存之后，應(yīng)用或者說協(xié)調(diào)者崩潰了，后續(xù)的工作都沒完成。前期被鎖定的庫存沒有人來釋放了，最終一致性出現(xiàn)問題了。

3PC即是在這種背景下產(chǎn)生的

3PC中增加了超時機制，來避免上述資源狀態(tài)永遠無法實現(xiàn)最終一致的問題，然而超時了到底應(yīng)該是回滾釋放還是提交確認(rèn)呢？

先看看三個階段干了什么

        階段1：查詢資源是否可用，注意只查詢不鎖定。所有參與者都可提交再進行下一段，降低預(yù)留資源時才發(fā)現(xiàn)部分參與者不可提交產(chǎn)生回滾的概率。

        階段2：鎖定資源

        階段3：提交確認(rèn)

參與者收到PreCommit后返回超時，釋放預(yù)留資源，使整個事務(wù)在進入階段3之前完全回滾。

參與者收到DoCommit后返回超時，仍然提交確認(rèn)。因為能進到階段3說明協(xié)調(diào)者已經(jīng)完成了階段2對所有參與者的資源預(yù)留鎖定。雖然大概率整個事務(wù)會成功，但如此畢竟不是完全嚴(yán)謹(jǐn)?shù)?，腦裂問題仍然存在，仍然會出現(xiàn)某個參與者提交其他參與者返回失敗這樣數(shù)據(jù)不一致的問題。

腦裂問題：協(xié)調(diào)者就是分布式/集群中的大腦，腦裂即協(xié)調(diào)者（領(lǐng)導(dǎo)者）的作用失效了。比如崩潰了，或者出現(xiàn)了多個協(xié)調(diào)者，使得參與者的行為沒有被統(tǒng)一調(diào)度而出現(xiàn)不一致的情況。

“Java分布式理論是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

本文標(biāo)題：Java分布式理論是什么
文章分享：http://jinyejixie.com/article36/gpshsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、用戶體驗、網(wǎng)站策劃、網(wǎng)站排名、響應(yīng)式網(wǎng)站、做網(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)