溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這期內容當中小編將會給大家帶來有關什么是微服務架構及分布式事務的解決方案，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
事務的四中隔離級別 read uncommitted 最低級別，任何情況都無法保證 read committed 可避免臟讀的發生 repeatable_read 可避免臟讀、不可重復讀的發生 Serializable可避免臟讀、不可重復讀、幻讀的發生 事務的四個特性 原子性 在計算機程序中，原子性就是對一組數據的操作是一個整體不可分割的意思。 一致性 經典的轉賬說明，A給B10000塊，那么A 賬戶少了 10000塊，B賬戶多了10000塊，不能出現B賬戶多了10000塊，而A賬戶的金額沒有變化 隔離性 還是那轉賬的例子說明，A給B 轉賬 10000 ，C給D 轉賬 50000，AB ，CD 這兩組直接是沒有關系的，是隔離的。 持久性 持久性就是持久化這樣，也沒什么可說的。 事務的七種傳播行為 propagation_requeired 如果存在一個事務，則支持當前的事務，如果沒有事務則開啟一個新的事務 propagation_supports 如果存在一個事務，支持當前事務，如果沒有事務，則非事務的執行，但是對于事務同步的事務管理器，propagation_supports 與不使用事務有少許不同 propagation_mandatory 如果存在一個事務，支持當前的事務，如果沒有一個活動的事務，則拋出異常 propagation_requires_new 總是開啟一個新的事務，如果一個事務已經存在，則將這個存在的事務掛起 propagation_never 總是非事務地執行，如果存在一個活動事務，則拋出異常 propagation_not_supported 總是非事務的執行，并掛起任何存在的事務 propagation_nested 如果一個活動的事務存在，則運行在一個嵌套的事務中，如果沒有活動事務，則按TransactionDefinition.PROPAGATION_REQUIRED 屬性執行
分布式事務是在分布架構，微服務的架構下出現的，分布式事務就是將多個節點的事務看成一個整體處理。
分布式事務一般有事務參與者，資源服務器，事務管理器等組成
分布式事務出現的場景有哪些 eg. 下訂單，減庫存，支付
分布式事務強調的不是事務，它依賴于每個單點的事務機制，它強調的是事務的分布式。到底如何解決分布式事務
實現思路
2PC 3PC，也說 兩段式，3段式 事務
基于XA 的分布式事務
基于消息的最終一致性方案
TCC 編程是補償事務(比較常用的一種分布式解決方案)
看圖，首先是一個事務管理器，第一個階段事務管理器先給兩個資源管理器發送 prepare 命令，如果兩個資源管理器的其中一個沒有ready, 那么就要等待了，等兩個資源管理器都給事務管理器回復 ready 命令，那么第一個階段就完事了；接下來進入第二個階段，事務管理器給兩個資源管理器發送 commit 命令，如果兩個資源管理器都接收到命令并提交了 committed
那么事務這一組事務OK，但是如果其中一個沒有 committed ，那就出問題了。這個2PC 的分布式事務還有其他諸多的問題。
我們來看一下 3PC
三段式提交3PC:三段式事務就是在 兩段式事務的 預備 和 提交 中間加了一層 "預">
2PC 和 3PC 在正式分布式系統中一般不會使用
xa 的分布式事務是 2PC 的演進而來。
基于消息的一致性方案
如下圖，加入A 是支付系統，B是訂單系統，A 發送一個預備消息給 mq，mq 收到預備消息保存，并返回個A 系統說，我mq 已經收到你的預備消息了，你可以執行你的業務邏輯了，然后A系統開始執行本地事務，并發送給mq 提交消息，mq 收到A 系統的提交消息（此時支付系統已經支付了），mq 將消息發送給訂單系統 B，說A系統已經支付了，你趕緊給我改訂單狀態，同時 mq 回調給 A 系統，讓A 該干嘛干嘛。這里可能有人就要問了，如果B系統修改訂單狀態失敗怎么辦 ？ 對啊，這怎么辦呢，其實實際中，再A 系統 發送提交消息之前呢，可以另起一個線程，并讓它掛起一下，掛起之后，去告訴B 系統，A這邊馬上就要提交了，你趕緊修改下訂單狀態吧。等B 修改完訂單狀態，A 就去提交支付，如果B 修改失敗，A就在本地回滾了。
基于消息的一致性方案是屬于強一致性的方案，一定是同時成功，或者同時失敗，不會出現其他的情況，缺點就是 A 系統支付業務就會暫停，B 修改之前就會一直等待，但是一般是等不起的。后面我們來說說 TCC
T try ,C confirm ,C cancel 中文簡單解釋就是 : 嘗試執行，確認操作，取消操作
假如上圖的服務A 是扣減庫存，服務B 是創建訂單，以扣減庫存創建訂單這一業務流程來說一下 TCC
首先第一步 app 告訴事務協調器要啟動一個事務了，然后就調用 try 接口 ，服務A try 接口扣減庫存， 服務B 創建訂單,最終 app 收到 AB 兩個的try 接口的執行結果，如果有一個失敗了，app 告訴事務協調器，剛剛這個事務失敗了，你調用 Cancel 接口吧；如果兩個都成功了，那么 app 告訴事務協調器調用 Confirm 接口
TCC的核心思想是資源，最核心的就是 在 Try 階段，一定要把資源做好預留（加鎖，加版本號，加分布式鎖等方式，先把資源給占著），為什么一定要預留呢，不預留的話，在 Cancel 階段就無法補償了，也就違背了TCC設計的初衷。如果對于資源的掌控力度不夠，不建議使用TCC，如果資源沒辦法做預留，沒有樂觀鎖，沒有狀態等字段，沒法預留也就沒法用TCC
tcc 補償性 和 基于 消息的分布式事務 表
基于消息的分布式事務是強一致性的，會存在浪費資源;因為會存在等待，唯獨最大的好處就是強一致性，實際業務中，可能要去要對接支付寶支付，微信支付，銀聯支付等待，這種消息性的事務還是可以使用的
TCC 強調的是在 try 的階段對資源做預留
TCC 在確認和取消階段釋放資源
如果是確認階段，那么將資源刪掉就行了，如果是取消階段，那么我們需要將這些資源進行反向的補償。
與消息性事務，TCC 的時效性高
上述就是小編為大家分享的什么是微服務架構及分布式事務的解決方案了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
