微服務(wù)架構(gòu)分布式事務(wù)設(shè)計(jì)方案樣本

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).常見(jiàn)的有CP系統(tǒng)，AP系統(tǒng).幕等性：簡(jiǎn)單的說(shuō)，業(yè)務(wù)操作支持重試，不會(huì)產(chǎn)生不利影 響.常見(jiàn)的實(shí)現(xiàn)方式：為消息額外增加唯一 ID.BASE (Basically avaliable, soft state, eventually consistent):是分布式事務(wù)實(shí)現(xiàn)的一種理論標(biāo)準(zhǔn).柔性事務(wù)vs.剛性事

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

3、務(wù)部 署，那么最好是使用TCC方案而不是2PC方案來(lái)解決.注意：以下每種方案都有不同的適用場(chǎng)合，需要根據(jù)實(shí)際業(yè)務(wù)場(chǎng) 景來(lái)選擇.兩階段提交(2PC)兩階段提交(Two Phase Commit, 2PC),具有強(qiáng)一致性，是CP系 統(tǒng)的一種典型實(shí)現(xiàn).兩階段提交，常見(jiàn)的標(biāo)準(zhǔn)是XA, JTA等.例如Oracle的數(shù)據(jù)庫(kù)支 持XA.示意圖圖的上半是兩階段提交成功的演示，下半是兩階段提交失敗的演 示.關(guān)于兩階段提交網(wǎng)上有很多經(jīng)典的講解，這里就不細(xì)說(shuō)了， 能夠參考前面的鏈接.缺點(diǎn)兩階段提交中的第二階段，協(xié)調(diào)者需要等待所有參與者發(fā)出 yes請(qǐng)求，或者一個(gè)參與者發(fā)出no請(qǐng)求后，才能執(zhí)行提交或者中 斷操作.這會(huì)造成長(zhǎng)時(shí)間同時(shí)鎖住多個(gè)資源，造成性能瓶頸，如 果參與者有一個(gè)耗時(shí)長(zhǎng)的操作，性能損耗會(huì)更明顯.實(shí)現(xiàn)復(fù)雜，不利于系統(tǒng)的擴(kuò)展，不推薦.TCC (Try-Confirm-Cancle)TCC,是基于補(bǔ)償型事務(wù)的AP系統(tǒng)的一種實(shí)現(xiàn)，具有最終一致性.tr，V成功I數(shù)據(jù)庫(kù)1.主業(yè)務(wù)服務(wù)canceIXconfirmX從業(yè)務(wù)服篁昌噩魏3.中imnX成功 提交/回洛:業(yè)務(wù)活動(dòng)!業(yè)務(wù)活動(dòng)管理器活動(dòng)日志t