本質(zhì)上來說，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

我們一直強(qiáng)調(diào)成都網(wǎng)站制作、做網(wǎng)站對(duì)于企業(yè)的重要性,如果您也覺得重要,那么就需要我們慎重對(duì)待,選擇一個(gè)安全靠譜的網(wǎng)站建設(shè)公司,企業(yè)網(wǎng)站我們建議是要么不做，要么就做好,讓網(wǎng)站能真正成為企業(yè)發(fā)展過程中的有力推手。專業(yè)網(wǎng)站建設(shè)公司不一定是大公司,成都創(chuàng)新互聯(lián)公司作為專業(yè)的網(wǎng)絡(luò)公司選擇我們就是放心。

1. 分布式理論
   1.1. CAP定律
   CAP指的是：一致性（Consistency）、可用性（Availability）、分區(qū)容錯(cuò)性（Partition tolerance）。
   CAP定律說的是，在一個(gè)分布式系統(tǒng)中，最多只能滿足C、A、P中的兩個(gè)，不可能三個(gè)同時(shí)滿足。
   在分布式系統(tǒng)中，網(wǎng)絡(luò)無法 100% 可靠，分區(qū)其實(shí)是一個(gè)必然現(xiàn)象。如果我們選擇了 CA 而放棄了 P，那么當(dāng)發(fā)生分區(qū)現(xiàn)象時(shí)，為了保證一致性，這個(gè)時(shí)候必須拒絕請(qǐng)求，但是 A 又不允許，所以分布式系統(tǒng)理論上不可能選擇 CA 架構(gòu)，只能選擇 CP 或者 AP 架構(gòu)。
   而且，顯然，任何橫向擴(kuò)展策略都要依賴于數(shù)據(jù)分區(qū)。因此，設(shè)計(jì)人員必須在一致性與可用性之間做出選擇。
   1.2. BASE理論
   往往在分布式系統(tǒng)中無法實(shí)現(xiàn)完全一致性，于是有了BASE理論，它是對(duì)CAP定律的進(jìn)一步擴(kuò)充
   BASE指的是：
   BASE理論是對(duì)CAP中的一致性和可用性進(jìn)行一個(gè)權(quán)衡的結(jié)果
   BASE理論核心思想就是：我們無法做到強(qiáng)一致，但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性
   BASE理論是通過犧牲強(qiáng)一致性來獲得可用性，并允許數(shù)據(jù)在一段時(shí)間內(nèi)是不一致的，但最終達(dá)到一致狀態(tài)
2. 分布式事務(wù)解決方案
   2.1. 基于XA協(xié)議的兩階段提交
   XA協(xié)議包含兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫實(shí)現(xiàn)，目前主流的關(guān)系型數(shù)據(jù)庫都實(shí)現(xiàn)了XA接口，而事務(wù)管理器作為全局的調(diào)度者，負(fù)責(zé)各個(gè)本地資源的提交和回滾。
   
   優(yōu)點(diǎn)：盡量保證了數(shù)據(jù)的強(qiáng)一致，適合對(duì)數(shù)據(jù)強(qiáng)一致要求很高的關(guān)鍵領(lǐng)域。（其實(shí)也不能100%保證強(qiáng)一致）
   缺點(diǎn)：XA協(xié)議遵循強(qiáng)一致性。在事務(wù)執(zhí)行過程中，各個(gè)節(jié)點(diǎn)占用著數(shù)據(jù)庫資源，只有當(dāng)所有節(jié)點(diǎn)準(zhǔn)備完畢，事務(wù)協(xié)調(diào)者才會(huì)通知提交，參與者提交后釋放資源。這樣的過程有著非常明顯的性能問題。
   （PS：XA三階段提交在兩階段提交的基礎(chǔ)上增加了CanCommit階段，并且引入了超時(shí)機(jī)制。這樣三階段提交就有CanCommit、PreCommit、DoCommit三個(gè)階段。）
   兩階段提交方案鎖定資源時(shí)間長，對(duì)性能影響很大，基本不適合解決微服務(wù)事務(wù)問題。
   2.2. TCC方案
   TCC 其實(shí)就是采用的補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷）操作。
   其將整個(gè)業(yè)務(wù)邏輯的每個(gè)分支顯式的分成了Try、Confirm、Cancel三個(gè)操作。Try部分完成業(yè)務(wù)的準(zhǔn)備工作，confirm部分完成業(yè)務(wù)的提交，cancel部分完成事務(wù)的回滾。
   
   拿前面的下單的例子來說，服務(wù)A的try相當(dāng)于查詢是否有可用的積分，Confirm相當(dāng)于扣減積分，Cancel相當(dāng)于增加積分。
   優(yōu)點(diǎn)：跟2PC比起來，實(shí)現(xiàn)以及流程相對(duì)簡單了一些，但數(shù)據(jù)的一致性比2PC也要差一些
   缺點(diǎn)：TCC屬于應(yīng)用層的一種補(bǔ)償方式，所以需要程序員在實(shí)現(xiàn)的時(shí)候多寫很多補(bǔ)償?shù)拇a，而且補(bǔ)償?shù)臅r(shí)候也有可能失敗，在一些場景中，一些業(yè)務(wù)流程可能用TCC不太好定義及處理。
   2.3. 本地消息表
   其基本的設(shè)計(jì)思想是將遠(yuǎn)程分布式事務(wù)拆分成一系列的本地事務(wù)。
   消息生產(chǎn)方，需要額外建一個(gè)消息表，并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務(wù)數(shù)據(jù)要在一個(gè)事務(wù)里提交，也就是說他們要在一個(gè)數(shù)據(jù)庫里面。然后消息會(huì)經(jīng)過MQ發(fā)送到消息的消費(fèi)方。如果消息發(fā)送失敗，會(huì)進(jìn)行重試發(fā)送。
   消息消費(fèi)方，需要處理這個(gè)消息，并完成自己的業(yè)務(wù)邏輯。此時(shí)如果本地事務(wù)處理成功，表明已經(jīng)處理成功了，如果處理失敗，那么就會(huì)重試執(zhí)行。如果是業(yè)務(wù)上面的失敗，可以給生產(chǎn)方發(fā)送一個(gè)業(yè)務(wù)補(bǔ)償消息，通知生產(chǎn)方進(jìn)行回滾等操作。
   生產(chǎn)方和消費(fèi)方定時(shí)掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動(dòng)對(duì)賬補(bǔ)賬邏輯，這種方案還是非常實(shí)用的。
   本地消息表是一個(gè)比較好的做法，這樣可以有效防止重復(fù)消息處理
   以轉(zhuǎn)賬為例，這種方式的過程是這樣的：
   有了消息表以后，可以防止重復(fù)、可以重試、保證消息不丟失、做冪等性校驗(yàn)
   優(yōu)點(diǎn)：一種非常經(jīng)典的實(shí)現(xiàn)，避免了分布式事務(wù)，實(shí)現(xiàn)了最終一致性。
   缺點(diǎn)：消息表會(huì)耦合到業(yè)務(wù)系統(tǒng)中，如果沒有封裝好的解決方案，會(huì)有很多雜活需要處理。
   2.4. MQ（非事務(wù)消息）
   如果不把本地?cái)?shù)據(jù)庫操作和消息投遞放在同一個(gè)事務(wù)中，那么很難保證本地事務(wù)成功后消息一定發(fā)送成功
   如果把它們放在同一個(gè)事務(wù)中，那么考慮下面幾種情況：
   以上三種情況都是正常的，不會(huì)有什么問題
   然而，考慮下面這種情況：
   本地?cái)?shù)據(jù)庫操作成功，消息投遞成功，應(yīng)用服務(wù)器掛了，事務(wù)回滾，于是不一致出現(xiàn)了，即本地?cái)?shù)據(jù)庫操作沒成功，而消息卻發(fā)成功了
   如果這是轉(zhuǎn)賬的話，對(duì)方會(huì)無緣無故多出一筆錢
   究其原因，是因?yàn)榘l(fā)消息不是數(shù)據(jù)庫操作，它不受ACID的限制，也就是說數(shù)據(jù)庫事務(wù)管不了發(fā)消息，因?yàn)樗麄儾皇峭粋€(gè)數(shù)據(jù)庫的同一個(gè)事務(wù)，當(dāng)然還有一個(gè)原因是發(fā)出去的消息是無法撤銷的。（PS：在后面將要介紹的RocketMQ的事務(wù)消息可以撤銷）
   而上面消息表的話，是同一個(gè)數(shù)據(jù)庫的同一個(gè)事務(wù)，因此不會(huì)出現(xiàn)這種問題
   綜上，這種方式有一定的風(fēng)險(xiǎn)，它無法保證本地?cái)?shù)據(jù)庫操作 與 消息投遞的一致性，不建議使用
   2.5. MQ（事務(wù)消息）
   目前，僅阿里云的RocketMQ支持事務(wù)消息。幫助用戶實(shí)現(xiàn)類似 X/Open XA 的分布事務(wù)功能，通過 MQ 事務(wù)消息能達(dá)到分布式事務(wù)的最終一致。
   
   說明：
   其中，事務(wù)消息發(fā)送對(duì)應(yīng)步驟1、2、3、4，事務(wù)消息回查對(duì)應(yīng)步驟5、6、7
   2.6. GTS
   全局事務(wù)服務(wù)（Global Transaction Service，簡稱 GTS）是一款高性能、高可靠、接入簡單的分布式事務(wù)中間件，用于解決分布式環(huán)境下的數(shù)據(jù)一致性問題。GTS 可以保證分布式系統(tǒng)中的分布式事務(wù)的 ACID 特性。它是阿里云的一款產(chǎn)品。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

網(wǎng)頁名稱：分布式事務(wù)-創(chuàng)新互聯(lián)
標(biāo)題路徑：http://m.rwnh.cn/article38/iissp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、網(wǎng)站導(dǎo)航、品牌網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈、虛擬主機(jī)、響應(yīng)式網(wǎng)站

廣告

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