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

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

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

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