什么是微服務(wù)架構(gòu)及分布式事務(wù)的解決方案

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)什么是微服務(wù)架構(gòu)及分布式事務(wù)的解決方案，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

事務(wù)的四中隔離級別

read uncommitted 最低級別，任何情況都無法保證
read committed 可避免臟讀的發(fā)生
repeatable_read 可避免臟讀、不可重復(fù)讀的發(fā)生
Serializable可避免臟讀、不可重復(fù)讀、幻讀的發(fā)生

事務(wù)的四個特性

原子性
在計算機程序中，原子性就是對一組數(shù)據(jù)的操作是一個整體不可分割的意思。
一致性
經(jīng)典的轉(zhuǎn)賬說明，A給B10000塊，那么A 賬戶少了 10000塊，B賬戶多了10000塊，不能出現(xiàn)B賬戶多了10000塊，而A賬戶的金額沒有變化
隔離性
還是那轉(zhuǎn)賬的例子說明，A給B 轉(zhuǎn)賬 10000 ，C給D 轉(zhuǎn)賬 50000，AB ，CD 這兩組直接是沒有關(guān)系的，是隔離的。
持久性
持久性就是持久化這樣，也沒什么可說的。

事務(wù)的七種傳播行為

propagation_requeired
如果存在一個事務(wù)，則支持當(dāng)前的事務(wù)，如果沒有事務(wù)則開啟一個新的事務(wù)
propagation_supports
如果存在一個事務(wù)，支持當(dāng)前事務(wù)，如果沒有事務(wù)，則非事務(wù)的執(zhí)行，但是對于事務(wù)同步的事務(wù)管理器，propagation_supports 
與不使用事務(wù)有少許不同
propagation_mandatory
如果存在一個事務(wù)，支持當(dāng)前的事務(wù)，如果沒有一個活動的事務(wù)，則拋出異常
propagation_requires_new
總是開啟一個新的事務(wù)，如果一個事務(wù)已經(jīng)存在，則將這個存在的事務(wù)掛起
propagation_never
總是非事務(wù)地執(zhí)行，如果存在一個活動事務(wù)，則拋出異常
propagation_not_supported
總是非事務(wù)的執(zhí)行，并掛起任何存在的事務(wù)
propagation_nested
如果一個活動的事務(wù)存在，則運行在一個嵌套的事務(wù)中，如果沒有活動事務(wù)，則按TransactionDefinition.PROPAGATION_REQUIRED 屬性執(zhí)行

分布式事務(wù)

1. 分布式事務(wù)是在分布架構(gòu)，微服務(wù)的架構(gòu)下出現(xiàn)的，分布式事務(wù)就是將多個節(jié)點的事務(wù)看成一個整體處理。

2. 分布式事務(wù)一般有事務(wù)參與者，資源服務(wù)器，事務(wù)管理器等組成

3. 分布式事務(wù)出現(xiàn)的場景有哪些 eg. 下訂單，減庫存，支付

4. 分布式事務(wù)強調(diào)的不是事務(wù)，它依賴于每個單點的事務(wù)機制，它強調(diào)的是事務(wù)的分布式。到底如何解決分布式事務(wù)

實現(xiàn)思路

• 2PC 3PC，也說 兩段式，3段式 事務(wù)

• 基于XA 的分布式事務(wù)

• 基于消息的最終一致性方案

• TCC 編程是補償事務(wù)(比較常用的一種分布式解決方案)

兩段式事務(wù) 2PC

看圖，首先是一個事務(wù)管理器，第一個階段事務(wù)管理器先給兩個資源管理器發(fā)送 prepare 命令，如果兩個資源管理器的其中一個沒有ready, 那么就要等待了，等兩個資源管理器都給事務(wù)管理器回復(fù) ready 命令，那么第一個階段就完事了；接下來進入第二個階段，事務(wù)管理器給兩個資源管理器發(fā)送 commit 命令，如果兩個資源管理器都接收到命令并提交了 committed
那么事務(wù)這一組事務(wù)OK，但是如果其中一個沒有 committed ，那就出問題了。這個2PC 的分布式事務(wù)還有其他諸多的問題。

我們來看一下 3PC

• 三段式提交3PC:三段式事務(wù)就是在 兩段式事務(wù)的 預(yù)備 和 提交 中間加了一層 "預(yù)">

2PC 和 3PC 在正式分布式系統(tǒng)中一般不會使用

基于XA 的分布式事務(wù)

xa 的分布式事務(wù)是 2PC 的演進而來。

基于消息的一致性方案

• 如下圖，加入A 是支付系統(tǒng)，B是訂單系統(tǒng)，A 發(fā)送一個預(yù)備消息給 mq，mq 收到預(yù)備消息保存，并返回個A 系統(tǒng)說，我mq 已經(jīng)收到你的預(yù)備消息了，你可以執(zhí)行你的業(yè)務(wù)邏輯了，然后A系統(tǒng)開始執(zhí)行本地事務(wù)，并發(fā)送給mq 提交消息，mq 收到A 系統(tǒng)的提交消息（此時支付系統(tǒng)已經(jīng)支付了），mq 將消息發(fā)送給訂單系統(tǒng) B，說A系統(tǒng)已經(jīng)支付了，你趕緊給我改訂單狀態(tài)，同時 mq 回調(diào)給 A 系統(tǒng)，讓A 該干嘛干嘛。這里可能有人就要問了，如果B系統(tǒng)修改訂單狀態(tài)失敗怎么辦 ？ 對啊，這怎么辦呢，其實實際中，再A 系統(tǒng) 發(fā)送提交消息之前呢，可以另起一個線程，并讓它掛起一下，掛起之后，去告訴B 系統(tǒng)，A這邊馬上就要提交了，你趕緊修改下訂單狀態(tài)吧。等B 修改完訂單狀態(tài)，A 就去提交支付，如果B 修改失敗，A就在本地回滾了。

• 基于消息的一致性方案是屬于強一致性的方案，一定是同時成功，或者同時失敗，不會出現(xiàn)其他的情況，缺點就是 A 系統(tǒng)支付業(yè)務(wù)就會暫停，B 修改之前就會一直等待，但是一般是等不起的。后面我們來說說 TCC

TCC補償性事務(wù)

T try ,C confirm ,C cancel
中文簡單解釋就是 : 嘗試執(zhí)行，確認(rèn)操作，取消操作

假如上圖的服務(wù)A 是扣減庫存，服務(wù)B 是創(chuàng)建訂單，以扣減庫存創(chuàng)建訂單這一業(yè)務(wù)流程來說一下 TCC
首先第一步 app 告訴事務(wù)協(xié)調(diào)器要啟動一個事務(wù)了，然后就調(diào)用 try 接口 ，服務(wù)A try 接口扣減庫存， 服務(wù)B 創(chuàng)建訂單,最終 app 收到 AB 兩個的try 接口的執(zhí)行結(jié)果，如果有一個失敗了，app 告訴事務(wù)協(xié)調(diào)器，剛剛這個事務(wù)失敗了，你調(diào)用 Cancel 接口吧；如果兩個都成功了，那么 app 告訴事務(wù)協(xié)調(diào)器調(diào)用 Confirm 接口

TCC的核心思想是資源，最核心的就是 在 Try 階段，一定要把資源做好預(yù)留（加鎖，加版本號，加分布式鎖等方式，先把資源給占著），為什么一定要預(yù)留呢，不預(yù)留的話，在 Cancel 階段就無法補償了，也就違背了TCC設(shè)計的初衷。如果對于資源的掌控力度不夠，不建議使用TCC，如果資源沒辦法做預(yù)留，沒有樂觀鎖，沒有狀態(tài)等字段，沒法預(yù)留也就沒法用TCC

tcc 補償性 和 基于 消息的分布式事務(wù) 表

• 基于消息的分布式事務(wù)是強一致性的，會存在浪費資源;因為會存在等待，唯獨最大的好處就是強一致性，實際業(yè)務(wù)中，可能要去要對接支付寶支付，微信支付，銀聯(lián)支付等待，這種消息性的事務(wù)還是可以使用的

• TCC 強調(diào)的是在 try 的階段對資源做預(yù)留

• TCC 在確認(rèn)和取消階段釋放資源

• 如果是確認(rèn)階段，那么將資源刪掉就行了，如果是取消階段，那么我們需要將這些資源進行反向的補償。

• 與消息性事務(wù)，TCC 的時效性高

上述就是小編為大家分享的什么是微服務(wù)架構(gòu)及分布式事務(wù)的解決方案了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。