聊聊微服務架構及分佈式事務解決方案

事務的四中隔離級別

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 屬性執行

分佈式事務

1. 分佈式事務是在分佈架構，微服務的架構下出現的，分佈式事務就是將多個節點的事務當作一個總體處理。
2. 分佈式事務通常有事務參與者，資源服務器，事務管理器等組成
3. 分佈式事務出現的場景有哪些 eg. 下訂單，減庫存，支付
4. 分佈式事務強調的不是事務，它依賴於每一個單點的事務機制，它強調的是事務的分佈式。到底如何解決分佈式事務

實現思路

• 2PC 3PC，也說 兩段式，3段式 事務
• 基於XA 的分佈式事務
• 基於消息的最終一致性方案
• TCC 編程是補償事務(比較經常使用的一種分佈式解決方案)

兩段式事務 2PC

看圖，首先是一個事務管理器，第一個階段事務管理器先給兩個資源管理器發送 prepare 命令，若是兩個資源管理器的其中一個沒有ready, 那麼就要等待了，等兩個資源管理器都給事務管理器回覆 ready 命令，那麼第一個階段就完事了；接下來進入第二個階段，事務管理器給兩個資源管理器發送 commit 命令，若是兩個資源管理器都接收到命令並提交了 committed
那麼事務這一組事務OK，可是若是其中一個沒有 committed ，那就出問題了。這個2PC 的分佈式事務還有其餘諸多的問題。

咱們來看一下 3PC

• 三段式提交3PC:三段式事務就是在 兩段式事務的 預備 和 提交 中間加了一層 "預" 狀態，準備以前，給資源服務器發送一個預，問一下 資源服務器，大家都準備好了嗎，資源服務器回覆 ：都準備好了，資源服務器就緒了，提交以前，在問一次，大家都準備好提交了嗎，資源服務器回覆：都準備好了了，事務管理器收到準備好了的確認後發生提交請求。

2PC 和 3PC 在正式分佈式系統中通常不會使用

基於XA 的分佈式事務

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

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 的時效性高

https://github.com/changmingxie/tcc-transaction

 ————————————————
版權聲明：本文爲CSDN博主「戈裏」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處連接及本聲明。
原文連接：https://blog.csdn.net/Andy86869/article/details/88430069