微服務(wù)架構(gòu)分布式事務(wù)設(shè)計(jì)方案_第1頁
微服務(wù)架構(gòu)分布式事務(wù)設(shè)計(jì)方案_第2頁
微服務(wù)架構(gòu)分布式事務(wù)設(shè)計(jì)方案_第3頁
微服務(wù)架構(gòu)分布式事務(wù)設(shè)計(jì)方案_第4頁
微服務(wù)架構(gòu)分布式事務(wù)設(shè)計(jì)方案_第5頁
已閱讀5頁,還剩1頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1、微服務(wù)分布式事務(wù)概念澄清 事務(wù)補(bǔ)償機(jī)制: 在事務(wù)鏈中的任何一個(gè)正向事務(wù)操作, 都必須存在一個(gè)完全符合回滾規(guī)則的可逆事務(wù). CAP理論: CAP(Consistency, Availability, Partition Tolerance), 闡述了一個(gè)分布式系統(tǒng)的三個(gè)主要方面, 只能同時(shí)擇其二進(jìn)行實(shí)現(xiàn). 常見的有CP系統(tǒng), AP系統(tǒng). 冪等性: 簡單的說,業(yè)務(wù)操作支持重試, 不會(huì)產(chǎn)生不利影響. 常見的實(shí)現(xiàn)方式: 為消息額外增加唯一ID. BASE(Basically avaliable, soft state, eventually consistent): 是分布式事務(wù)實(shí)現(xiàn)的一種理論標(biāo)準(zhǔn).柔

2、性事務(wù) vs. 剛性事務(wù)剛性事務(wù)是指嚴(yán)格遵循ACID原則的事務(wù), 例如單機(jī)環(huán)境下的數(shù)據(jù)庫事務(wù).柔性事務(wù)是指遵循BASE理論的事務(wù), 通常用在分布式環(huán)境中, 常見的實(shí)現(xiàn)方式有: 兩階段提交(2PC), TCC補(bǔ)償型提交, 基于消息的異步確保型, 最大努力通知型.通常對本地事務(wù)采用剛性事務(wù), 分布式事務(wù)使用柔性事務(wù).最佳實(shí)踐先上結(jié)論, 再分別介紹分布式事務(wù)的各種實(shí)現(xiàn)方式. 如果業(yè)務(wù)場景需要強(qiáng)一致性, 那么盡量避免將它們放在不同服務(wù)中, 也就是盡量使用本地事務(wù), 避免使用強(qiáng)一致性的分布式事務(wù). 如果業(yè)務(wù)場景能夠接受最終一致性, 那么最好是使用基于消息的最終一致性的方案(異步確保型)來解決. 如果業(yè)務(wù)

3、場景需要強(qiáng)一致性, 并且只能夠進(jìn)行分布式服務(wù)部署, 那么最好是使用TCC方案而不是2PC方案來解決.注意: 以下每種方案都有不同的適用場合, 需要根據(jù)實(shí)際業(yè)務(wù)場景來選擇.兩階段提交(2PC)兩階段提交(Two Phase Commit, 2PC), 具有強(qiáng)一致性, 是CP系統(tǒng)的一種典型實(shí)現(xiàn).兩階段提交, 常見的標(biāo)準(zhǔn)是XA, JTA等. 例如Oracle的數(shù)據(jù)庫支持XA.示意圖圖的上半是兩階段提交成功的演示, 下半是兩階段提交失敗的演示. 關(guān)于兩階段提交網(wǎng)上有很多經(jīng)典的講解, 這里就不細(xì)說了, 可以參考前面的鏈接.缺點(diǎn) 兩階段提交中的第二階段, 協(xié)調(diào)者需要等待所有參與者發(fā)出yes請求, 或者一個(gè)

4、參與者發(fā)出no請求后, 才能執(zhí)行提交或者中斷操作. 這會(huì)造成長時(shí)間同時(shí)鎖住多個(gè)資源, 造成性能瓶頸, 如果參與者有一個(gè)耗時(shí)長的操作, 性能損耗會(huì)更明顯. 實(shí)現(xiàn)復(fù)雜, 不利于系統(tǒng)的擴(kuò)展, 不推薦.TCC (Try-Confirm-Cancle)TCC, 是基于補(bǔ)償型事務(wù)的AP系統(tǒng)的一種實(shí)現(xiàn), 具有最終一致性.下面以客戶購買商品時(shí)的付款操作為例進(jìn)行講解: Try:完成所有的業(yè)務(wù)檢查(一致性),預(yù)留必須業(yè)務(wù)資源(準(zhǔn)隔離性);體現(xiàn)在本例中, 就是確認(rèn)客戶賬戶余額足夠支付(一致性), 鎖住客戶賬戶, 商戶賬戶(準(zhǔn)隔離性). Confirm:使用Try階段預(yù)留的業(yè)務(wù)資源執(zhí)行業(yè)務(wù)(業(yè)務(wù)操作必須是冪等的),

5、如果執(zhí)行出現(xiàn)異常, 要進(jìn)行重試.在這里就是執(zhí)行客戶賬戶扣款, 商戶賬戶入賬操作. Cancle:釋放Try階段預(yù)留的業(yè)務(wù)資源, 在這里就是釋放客戶賬戶和商戶賬戶的鎖;如果任一子業(yè)務(wù)在Confirm階段有操作無法執(zhí)行成功, 會(huì)造成對業(yè)務(wù)活動(dòng)管理器的響應(yīng)超時(shí), 此時(shí)要對其他業(yè)務(wù)執(zhí)行補(bǔ)償性事務(wù). 如果補(bǔ)償操作執(zhí)行也出現(xiàn)異常, 必須進(jìn)行重試, 若實(shí)在無法執(zhí)行成功, 則事務(wù)管理器必須能夠感知到失敗的操作, 進(jìn)行l(wèi)og(用于事后人工進(jìn)行補(bǔ)償性事務(wù)操作或者交由中間件接管在之后進(jìn)行補(bǔ)償性事務(wù)操作).優(yōu)點(diǎn)對比與前面提到的兩階段提交法, 有兩大優(yōu)勢: TCC能夠?qū)Ψ植际绞聞?wù)中的各個(gè)資源進(jìn)行分別鎖定, 分別提交與釋

6、放,例如, 假設(shè)有AB兩個(gè)操作, 假設(shè)A操作耗時(shí)短, 那么A就能較快的完成自身的try-confirm-cancel流程, 釋放資源. 無需等待B操作. 如果事后出現(xiàn)問題, 追加執(zhí)行補(bǔ)償性事務(wù)即可. TCC是綁定在各個(gè)子業(yè)務(wù)上的(除了cancle中的全局回滾操作), 也就是各服務(wù)之間可以在一定程度上”異步并行”執(zhí)行.注意事項(xiàng) 事務(wù)管理器(協(xié)調(diào)器)這個(gè)節(jié)點(diǎn)必須以帶同步復(fù)制語義的高可用集群(HAC)方式部署. 事務(wù)管理器(協(xié)調(diào)器)還需要使用多數(shù)派算法來避免集群發(fā)生腦裂問題.適用場景 嚴(yán)格一致性 執(zhí)行時(shí)間短 實(shí)時(shí)性要求高舉例: 紅包, 收付款業(yè)務(wù).異步確保型通過將一系列同步的事務(wù)操作變?yōu)榛谙?zhí)行

7、的異步操作, 避免了分布式事務(wù)中的同步阻塞操作的影響.這個(gè)方案真正實(shí)現(xiàn)了兩個(gè)服務(wù)的解耦, 解耦的關(guān)鍵就是異步消息和補(bǔ)償性事務(wù).這里以一個(gè)例子作為講解:執(zhí)行步驟如下:1. MQ發(fā)送方發(fā)送遠(yuǎn)程事務(wù)消息到MQ Server;2. MQ Server給予響應(yīng), 表明事務(wù)消息已成功到達(dá)MQ Server.3. MQ發(fā)送方Commit本地事務(wù).4. 若本地事務(wù)Commit成功, 則通知MQ Server允許對應(yīng)事務(wù)消息被消費(fèi); 若本地事務(wù)失敗, 則通知MQ Server對應(yīng)事務(wù)消息應(yīng)被丟棄.5. 若MQ發(fā)送方超時(shí)未對MQ Server作出本地事務(wù)執(zhí)行狀態(tài)的反饋, 那么需要MQ Servfer向MQ發(fā)送方主

8、動(dòng)回查事務(wù)狀態(tài), 以決定事務(wù)消息是否能被消費(fèi).6. 當(dāng)?shù)弥镜厥聞?wù)執(zhí)行成功時(shí), MQ Server允許MQ訂閱方消費(fèi)本條事務(wù)消息.需要額外說明的一點(diǎn), 就是事務(wù)消息投遞到MQ訂閱方后, 并不一定能夠成功執(zhí)行. 需要MQ訂閱方主動(dòng)給予消費(fèi)反饋(ack) 如果MQ訂閱方執(zhí)行遠(yuǎn)程事務(wù)成功, 則給予消費(fèi)成功的ack, 那么MQ Server可以安全將事務(wù)消息移除; 如果執(zhí)行失敗, MQ Server需要對消息重新投遞, 直至消費(fèi)成功.注意事項(xiàng) 消息中間件在系統(tǒng)中扮演一個(gè)重要的角色, 所有的事務(wù)消息都需要通過它來傳達(dá), 所以消息中間件也需要支持 HAC 來確保事務(wù)消息不丟失. 根據(jù)業(yè)務(wù)邏輯的具體實(shí)現(xiàn)不同,還可能需要對消息中間件增加消息不重復(fù), 不亂序等其它要求.適用場景 執(zhí)行周期較長 實(shí)時(shí)性要求不高例如: 跨行轉(zhuǎn)賬/匯款業(yè)務(wù)(兩個(gè)服務(wù)分別在不同的銀行中) 退貨/退款業(yè)務(wù) 財(cái)務(wù), 賬單統(tǒng)計(jì)業(yè)務(wù)(先發(fā)送到消息中間件, 然后進(jìn)行批量記賬)最大努力通知型這是分布式事務(wù)中要求最低的一種, 也可以通過消息中間件實(shí)現(xiàn), 與前面異步確保型操作不同的一點(diǎn)是, 在消息由MQ Server投遞到消費(fèi)者之后,允許在達(dá)到最大重試次數(shù)之后

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論