本質上來說，分布式事務就是為了保證不同數據庫的數據一致性。

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

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

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

網頁名稱：分布式事務-創(chuàng)新互聯(lián)
標題路徑：http://vcdvsql.cn/article38/iissp.html

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

廣告

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