最終一致性分布式事務概述

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

典型方案

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

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

優(yōu)缺點

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

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

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

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

服務模式

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

Try階段

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

Confirm階段

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

Cancel階段

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

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

TCC解決方案

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

適用場景

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

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

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

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

分支事務失敗的情況：

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

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

方案的優(yōu)缺點

TCC方案的優(yōu)點

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

TCC方案的缺點

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

需要注意的問題

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

空回滾問題

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

冪等問題

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

懸掛問題

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