分布式事務一致性，事務補償實戰

一、事務記錄補償表設計

三、業務補償函式

@override

public
void compensation(bidpaymentdetailconfirmrecord confirmrecord, providerusersession usersession) throws
exception 
bidpaymentsdetail detail =bidpaymentsdetailservice.selectbyprimarykey(detailid);
bidpayments payments =bidpaymentsservice.selectbyprimarykey(detail.getpaymentid());
if(payments == null
)         trctrack trctrack =trctrackprovider.selectbyprimarykey(payments.gettrackid());
if(trctrack == null
)         cstcustomer customer =cstcustomerprovider.selectbyprimarykey(trctrack.getcustomerid());
if(customer == null
)         
final bidcontract bidcontract =bidcontractservice.geteffectcontract(trctrack.getid());
try                        
break
;                    
case 24:
//1、定金首期款
bidpaymentsdetailservice.intentiontodownpayment(payments, trctrack.getid(),
usersession.getebsbizid(), bidcontract.getcontractno());
break
;                    
case 30:
//建立收款確認跟進記錄
bidpaymentsdetailservice.insertreceivedamountaction(trctrack, customer, detail, usersession);
break
;                }
confirmrecord.setstatus(2);        //
設定為已補償
} else
} catch
(exception e) 
}

微服務架構 最終一致性 事務補償

原創 魔鏡的技術心經 分布式事務產生的原因 隨著微服務架構的流行，讓分布式事務問題日益突出，那麼常見的分布式事務解決方案有哪些呢？如何理解最終一致性和它的事務補償機制呢？剛性事務 強一致性 如上圖，這是個標準的全域性事務，事務管理器控制著全域性事務，管理事務的生命週期，並通過xa協議與資源管理器協調...

Rocket分布式事務一致性解決方案

在轉賬業務中，有兩步，乙個是操作使用者a扣錢，乙個是操作使用者b加錢 如果在同乙個資料庫中進行，可以保證這兩步操作，要麼同時成功，要麼同時不成功。這樣就保證了轉賬的資料一致性。但是如果使用者a的資料在集群a中，使用者b在集群b中呢？因為他們不在同乙個事務中 如使用者a扣款成功，但使用者b加錢失敗了 ...

分布式事務最終一致性的簡單案例

最近專案中遇到乙個場景。為了減少單庫的資料量，系統採用了分庫的方式，分為1個主庫和n個分庫。現在，在分庫中的a表，需要收斂成乙個彙總的資料，並寫入主庫中的b表。需要保證分庫更改a表的處理狀態和插入主庫b表兩個動作具有原子性，那麼，這就涉及到了跨庫的分布式事務的一致性問題。經過一番學習了解，由於該場景...