微服務(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ù)，通常用在分布式環(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)

4、時(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)，具有最終一致性.主業(yè)務(wù)服務(wù)數(shù)據(jù)庫(kù)啟動(dòng)業(yè)務(wù)活動(dòng)登記業(yè)務(wù)操作提交/回滾業(yè)務(wù)活動(dòng)業(yè)務(wù)活動(dòng)活動(dòng)日志L tryX成功2. tr汁成功3. confirmX成功4. confirmY 成功tryXcancelXconfirn數(shù)據(jù)庫(kù)tryYconfirmYcancelY從業(yè)務(wù)眼看數(shù)據(jù)庫(kù)_. 一卜面以客戶(hù)購(gòu)買(mǎi)商品時(shí)的付款操作 為例進(jìn)行講解： Try:完成所有的業(yè)務(wù)檢查（一致性），預(yù)留必須業(yè)務(wù)資

5、源（準(zhǔn)隔離性）；體現(xiàn)在本例中，就是確認(rèn)客戶(hù)賬戶(hù)余額足夠支付（一致性），鎖住客戶(hù)賬戶(hù)，商戶(hù)賬戶(hù) （準(zhǔn)隔離性）. Confirm:使用Try階段預(yù)留的業(yè)務(wù)資源執(zhí)行業(yè)務(wù)（業(yè)務(wù)操作必須是曷等的），如果執(zhí)行出現(xiàn)異 常，要進(jìn)行重試.在這里就是執(zhí)行客戶(hù)賬戶(hù)扣款，商戶(hù)賬戶(hù)入賬操作. Cancle:釋放Try階段預(yù)留的業(yè)務(wù)資源，在這里就是釋放客戶(hù)賬戶(hù)和商戶(hù)賬戶(hù)的鎖；如果任一子業(yè)務(wù)在Confirm階段有操作無(wú)法執(zhí)行成功，會(huì)造成對(duì)業(yè)務(wù)活動(dòng)管理器的 響應(yīng)超時(shí)，此時(shí)要對(duì)其他業(yè)務(wù)執(zhí)行補(bǔ)償性事務(wù).如果補(bǔ)償操作執(zhí)行也出現(xiàn)異常，必 須進(jìn)行重試，若實(shí)在無(wú)法執(zhí)行成功，則事務(wù)管理器必須能夠感知到失敗的操作，進(jìn)行10g（用于事后人工進(jìn)

6、行補(bǔ)償性事務(wù)操作或者交由中間件接管在之后進(jìn)行補(bǔ)償性事 務(wù)操作）.優(yōu)點(diǎn)對(duì)比與前面提到的兩階段提交法，有兩大優(yōu)勢(shì)： TCC能夠?qū)Ψ植际绞聞?wù)中的 各個(gè)資源進(jìn)彳f分別鎖定，分別提交與釋放，例如，假設(shè) 有AB兩個(gè)操作，假設(shè)A操作耗時(shí)短，那么A就能較快的完成自身的 try-confirm-cancel流程，釋放資源.無(wú)需等待B操作.如果事后出現(xiàn)問(wèn)題，追加執(zhí)行 補(bǔ)償性事務(wù)即可. TCC是綁定在各個(gè)子業(yè)務(wù)上的（除了 cancle中的全局回滾操作）,也就是各服務(wù)之間 可以在一定程度上“異步并行”執(zhí)行.注意事項(xiàng) 事務(wù)管理器（協(xié)調(diào)器）這個(gè)節(jié)點(diǎn)必須以帶同步復(fù)制語(yǔ)義的高可用集群（HAC）方式部署. 事務(wù)管理器（協(xié)調(diào)器）

7、還需要使用多數(shù)派算法來(lái)避免集群發(fā)生腦裂問(wèn)題.適用場(chǎng)景 嚴(yán)格一致性 執(zhí)行時(shí)間短 實(shí)時(shí)性要求高舉例：紅包，收付款業(yè)務(wù).異步確保型通過(guò)將一系列同步的事務(wù)操作變?yōu)榛谙?zhí)行的異步操作，避免了分布式事務(wù)中 的同步阻塞操作的影響.這個(gè)方案真正實(shí)現(xiàn)了兩個(gè)服務(wù)的解耦,解耦的關(guān)鍵就是異步消息和補(bǔ)償性事務(wù).這里以一個(gè)例子作為講解：.根據(jù)事努的狀由CamEit/fimbaE執(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 Ser

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