最終一致性分布式事務(wù)概述

????????強一致性分布式事務(wù)解決方案要求參與事務(wù)的各個節(jié)點的數(shù)據(jù)時刻保持一致，查詢?nèi)我夤?jié)點的數(shù)據(jù)都能得到最新的數(shù)據(jù)結(jié)果，這就導(dǎo)致在分布式場景，尤其是高并發(fā)場景下，系統(tǒng)的性能受到了影響。而最終一致性分布式事務(wù)解決方案并不要求參與事務(wù)的各個節(jié)點數(shù)據(jù)時刻保持一致，運行其存在中間狀態(tài)，只要一段時間后，能夠達到數(shù)據(jù)的最終一致狀態(tài)即可，在電商場景中使用比較多

典型方案

業(yè)界基于Base理論提出的最終一致性分布式事務(wù)解決方案有：

• TCC解決方案
• 可靠消息最終一致性解決方案
• 最大努力通知型解決方案

優(yōu)缺點

最終一致性分布式事務(wù)解決方案的優(yōu)點：

• 性能比較高，這是因為最終一致性分布式事務(wù)解決方案不要求數(shù)據(jù)時刻保持一致，不會因為長時間持有事務(wù)占用的資源而過度消耗過多的性能
• 具備可用性
• 適合高并發(fā)場景

最終一致性分布式事務(wù)解決方案的缺點：

• 因為數(shù)據(jù)存在短暫的不一致，所以在某個時刻查詢出的數(shù)據(jù)狀態(tài)可能會不一致
• 對于事務(wù)一致性要求特別高的場景不適用

服務(wù)模式

• 可查詢操作：需要服務(wù)操作具有可標識性，主要體現(xiàn)在服務(wù)的操作具有全局唯一的標識，可以是業(yè)務(wù)的單據(jù)編碼（如訂單號）也可以是系統(tǒng)分配的操作流水號，另外在可查詢的服務(wù)模式中，也要有完整的操作時間信息
• 冪等性操作：指對同一個方法，只要參數(shù)相同，無論執(zhí)行多少次都與第一次執(zhí)行時產(chǎn)生的影響相同，為了保證數(shù)據(jù)的最終一致性，系統(tǒng)會提供很多次重試操作，這個時候就需要接口實現(xiàn)冪等性操作
• TCC操作：這個模式下包括了3個階段，Try階段（嘗試業(yè)務(wù)執(zhí)行）、Confirm階段（確認業(yè)務(wù)階段）和cancel階段（取消業(yè)務(wù)執(zhí)行）

Try階段

1. 完成所有業(yè)務(wù)的一致性檢查
2. 預(yù)留必要的業(yè)務(wù)資源，并需要與其他操作隔離

Confirm階段

1. 此階段會真正執(zhí)行業(yè)務(wù)操作
2. 因為在Try階段完成了業(yè)務(wù)的一致性檢查，所有此階段不會做任務(wù)業(yè)務(wù)檢查
3. 只用Try階段預(yù)留的業(yè)務(wù)資源進行操作
4. 此階段的操作需要滿足冪等性

Cancel階段

1. 釋放Try階段預(yù)留的業(yè)務(wù)資源
2. 此階段的操作需要滿足冪等性

• 可補償操作：某些數(shù)據(jù)處于不正常的狀態(tài)，需要通過某種方式進行業(yè)務(wù)補償，使數(shù)據(jù)能夠達到最終一致性，這種因數(shù)據(jù)不正常而進行的補償操作，就是可補償操作服務(wù)模式

TCC解決方案

????????TCC是一種典型的解決分布式事務(wù)問題的方案，主要解決跨服務(wù)調(diào)用場景下得分布式事務(wù)問題，廣泛應(yīng)用于分布式事務(wù)場景

適用場景

????????用于具有強隔離性，嚴格一致性要的業(yè)務(wù)場景，也適用于執(zhí)行時間比較短的業(yè)務(wù)，對于電商場景中下得減庫存等業(yè)務(wù)，如果使用TCC分布式事務(wù)，則會經(jīng)歷Try、Confirm、Cancel三個階段

需要實現(xiàn)的服務(wù)模式

????????在TCC分布式事務(wù)解決方案中，需要實現(xiàn)的服務(wù)模式包括TCC操作，冪等操作、可補償操作、可查詢操作。

????????例如實現(xiàn)TCC分布式事務(wù)方案時，需要實現(xiàn)Try、Confirm、Cancel三個階段的業(yè)務(wù)邏輯，這就是TCC操作，在TCC操作的每個階段的方法都需要實現(xiàn)冪等性，這就是冪等操作，如果在執(zhí)行分布式事務(wù)過程中業(yè)務(wù)服務(wù)出現(xiàn)了異常情況，則需要支持重試階段，以達到事務(wù)補償?shù)哪康?#xff0c;這就是可補償操作，另外業(yè)務(wù)服務(wù)需要提供可以查詢自身內(nèi)部事務(wù)狀態(tài)的接口，以供其他服務(wù)調(diào)用，這就是可查詢操作

分支事務(wù)失敗的情況：

本質(zhì)上講，TCC是一種應(yīng)用層實現(xiàn)的二階段提交協(xié)議，TCC方案的執(zhí)行流程如下

• Try階段：不會執(zhí)行任務(wù)業(yè)務(wù)邏輯，僅做業(yè)務(wù)的一致性檢查和預(yù)留相應(yīng)的資源，這些資源能夠和其他操作保持隔離
• confirm階段：當Try階段所有分支事務(wù)執(zhí)行成后開始執(zhí)行Confirm階段，通常情況下，采用TCC解決分布式事務(wù)時會任務(wù)Confirm階段是不會出錯的，也就是說，只要Try階段的操作執(zhí)行成功了，Confirm階段就一定會執(zhí)行成功，如果Confirm階段出錯了，就需要引入重試機制或者人工處理，對出錯的事務(wù)進行干預(yù)
• Cancel階段：在業(yè)務(wù)執(zhí)行異?；虺霈F(xiàn)錯誤的情況下，需要回滾事務(wù)的操作，執(zhí)行分支事務(wù)的取消操作，并且釋放Try階段預(yù)留的資源，通常情況下，采用TCC方法解決分布式事務(wù)時，同樣會認為Cacnel階段也是一定會執(zhí)行成功的，如果出現(xiàn)錯誤，就需要引入重試機制或者人工處理，對出錯的事務(wù)進行干預(yù)

方案的優(yōu)缺點

TCC方案的優(yōu)點

• 在應(yīng)用層實現(xiàn)具體的邏輯，鎖定資源的粒度變小，不會鎖定所有資源，提升了系統(tǒng)的性能
• Confirm階段和Cancel階段的方法具備冪等性，能夠保證分布式事務(wù)執(zhí)行完畢后數(shù)據(jù)的一致性
• TCC分布式解決方案有主業(yè)務(wù)發(fā)起整個事務(wù)，無論主業(yè)務(wù)還是分支事務(wù)所在的業(yè)務(wù)，都能部署為集群模式，從而解決了XA規(guī)范的單點故障問題

TCC方案的缺點

• 代碼需要耦合到業(yè)務(wù)中，每個參與分布式事務(wù)的業(yè)務(wù)方法都要拆成Try、Confirm、Cancel三個階段的方法，提高了開發(fā)的成本

需要注意的問題

????????使用TCC方案解決分布式事務(wù)問題時，需要注意空回滾、冪等和懸掛問題

空回滾問題

• 原因：出現(xiàn)空回滾的原因是一個分支事務(wù)所在的服務(wù)器宕機或者網(wǎng)絡(luò)發(fā)生異常，此分支事務(wù)調(diào)用失敗，此時并未執(zhí)行此分支的Try階段的方法，當服務(wù)器或者網(wǎng)絡(luò)恢復(fù)后，TCC分布式事務(wù)執(zhí)行回滾操作，會調(diào)用分支事務(wù)的Cancel階段的方法，如果Cancel階段的方法不能處理這種情況，就會出現(xiàn)空回滾的問題
• 解決方案：識別是否出現(xiàn)空回滾操作的方法是判斷是否執(zhí)行了Try階段的方法，如果執(zhí)行了Try階段的方法，就沒有空回滾，否則則出現(xiàn)空回滾

冪等問題

• 原因：由于服務(wù)器宕機、應(yīng)用崩潰或者網(wǎng)絡(luò)異常等原因，可能會出現(xiàn)方法調(diào)用超時的情況，為了保證方法的正常執(zhí)行，往往會在TCC方案中加入超時重試機制，因為超時重試有可能導(dǎo)致數(shù)據(jù)的不一致問題，所以需要保證分支事務(wù)的執(zhí)行以及TCC方案的Confirm階段和Cancel階段具備冪等性
• 解決方案：在分支事務(wù)記錄表中增加事務(wù)的執(zhí)行狀態(tài)，每次執(zhí)行分支事務(wù)以及Confirm階段和Cancel階段的方法時，都查詢次事務(wù)的執(zhí)行狀態(tài)，以此判斷事務(wù)的冪等性

懸掛問題

• 原因：TCC分布式事務(wù)中，通過RPC調(diào)用分支事務(wù)Try階段的方法時，會先注冊分支事務(wù)，在執(zhí)行RPC調(diào)用。如果此時發(fā)生服務(wù)器宕機，應(yīng)用崩潰或者網(wǎng)絡(luò)異常等情況，RPC調(diào)用就會超時，如果RPC調(diào)用超時，事務(wù)管理器會通知對于的資源管理器回滾事務(wù)，可能資源管理器回滾完事務(wù)后，RPC請求達到了參與分支事務(wù)所在的業(yè)務(wù)方法，因為此時事務(wù)以及回滾，所以在Try階段預(yù)留的資源就無法釋放了，這種情況下，就成為懸掛
• 解決方案：如果執(zhí)行了Confirm階段或者Cancel階段的方法，則Try階段的方法就不能再執(zhí)行了，具體方案是在執(zhí)行Try階段的方法時，判斷分支記錄表中是否存在同一全局事務(wù)下Confirm階段或者Cancel階段的事務(wù)記錄，如果存在，則不執(zhí)行Try階段的方法