多個資料要同時操作,如何保證資料的完整性,以及一緻性?
答:事務,是常見的做法。
舉個栗子:
使用者下了一個訂單,需要修改餘額表,訂單表,流水表,于是會有類似的僞代碼:
start transaction;
CURD table t_account; any Exception rollback;
CURD table t_order; any Exception rollback;
CURD table t_flow; any Exception rollback;
commit;
如果對餘額表,訂單表,流水表的SQL操作全部成功,則全部送出
如果任何一個出現問題,則全部復原
事務,以保證資料的完整性以及一緻性。
事務的方案會有什麼潛在問題?
答:網際網路的業務特點,資料量較大,并發量較大,經常使用拆庫的方式提升系統的性能。如果進行了拆庫,餘額、訂單、流水可能分布在不同的資料庫上,甚至不同的資料庫執行個體上,此時就不能用資料庫原生事務來保證資料的一緻性了。
高并發易落地的分布式事務,是行業沒有很好解決的難題,那怎麼辦呢?
答:補償事務是一種常見的實踐。
什麼是補償事務?
答:補償事務,是一種在業務端實施業務逆向操作事務。
修改餘額,事務為:
int Do_AccountT(uid, money){
start transaction;
//餘額改變money這麼多
CURD table t_account with money for uid;
anyException rollback return NO;
commit;
return YES;
}
那麼,修改餘額,補償事務可以是:
int Compensate_AccountT(uid, money){
//做一個money的反向操作
return Do_AccountT(uid, -1*money){
}
同理,訂單操作,事務是:Do_OrderT,新增一個訂單;
訂單操作,補償事務是:Compensate_OrderT,删除一個訂單。
要保證餘額與訂單的一緻性,僞代碼:
// 執行第一個事務
int flag = Do_AccountT();
if(flag=YES){
//第一個事務成功,則執行第二個事務
flag= Do_OrderT();
if(flag=YES){
// 第二個事務成功,則成功
return YES;
}
else{
// 第二個事務失敗,執行第一個事務的補償事務
Compensate_AccountT();
}
}
補償事務有什麼缺點?
不同的業務要寫不同的補償事務,不具備通用性;
沒有考慮補償事務的失敗;
如果業務流程很複雜,if/else會嵌套非常多層;
畫外音:上面的例子還隻考慮了餘額+訂單的一緻性,就有22=4個分支,如果要考慮餘額+訂單+流水的一緻性,則會有22*2=8個if/else分支,複雜性呈指數級增長。
還有其它簡易一緻性實踐麼?
答:多個資料庫執行個體上的多個事務,要保證一緻性,可以進行“後置送出優化”。
單庫是用這樣一個大事務保證一緻性:
start transaction;
CURD table t_account; any Exception rollback;
CURD table t_order; any Exception rollback;
CURD table t_flow; any Exception rollback;
commit;
拆分成了多個庫後,大事務會變成三個小事務:
start transaction1;
//第一個庫事務執行
CURD table t_account; any Exception rollback;
…
// 第一個庫事務送出
commit1;
start transaction2;
//第二個庫事務執行
CURD table t_order; any Exception rollback;
…
// 第二個庫事務送出
commit2;
start transaction3;
//第三個庫事務執行
CURD table t_flow; any Exception rollback;
…
// 第三個庫事務送出
commit3;
畫外音:再次提醒,這三個事務發生在三個庫,甚至3個不同執行個體的資料庫上。
一個事務,分成執行與送出兩個階段:
執行(CURD)的時間很長
送出(commit)的執行很快
于是整個執行過程的時間軸如下:
第一個事務執行200ms,送出1ms;
第二個事務執行120ms,送出1ms;
第三個事務執行80ms,送出1ms;
在什麼時候,會出現不一緻?
答:第一個事務成功送出之後,最後一個事務成功送出之前,如果出現問題(例如伺服器重新開機,資料庫異常等),都可能導緻資料不一緻。
畫外音:如上圖,最後202ms内出現異常,會出現不一緻。
什麼是後置送出優化?
答:如果改變事務執行與送出的時序,變成事務先執行,最後一起送出。
第一個事務執行200ms,第二個事務執行120ms,第三個事務執行80ms;
第一個事務送出1ms,第二個事務送出1ms,第三個事務送出1ms;
後置送出優化後,在什麼時候,會出現不一緻?
答:問題的答案與之前相同,第一個事務成功送出之後,最後一個事務成功送出之前,如果出現問題(例如伺服器重新開機,資料庫異常等),都可能導緻資料不一緻。
畫外音:如上圖,最後2ms内出現異常,會出現不一緻。
有什麼差別和差異?
答:
串行事務方案,總執行時間是303ms,最後202ms内出現異常都可能導緻不一緻;
後置送出優化方案,總執行時間也是303ms,但最後2ms内出現異常才會導緻不一緻;
雖然沒有徹底解決資料的一緻性問題,但不一緻出現的機率大大降低了。
畫外音:上面這個例子,機率降低了100倍。
後置送出優化,有什麼不足?
答:對事務吞吐量會有影響:
- 串行事務方案,第一個庫事務送出,資料庫連接配接就釋放了;
- 後置送出優化方案,所有庫的連接配接,要等到所有事務執行完才釋放;
這就意味着,資料庫連接配接占用的時間增長了,系統整體的吞吐量降低了。
總結
分布式事務,兩種常見的實踐:
- 補償事務
- 後置送出優化
把
trx1.exec(); trx1.commit();
trx2.exec(); trx2.commit();
trx3.exec(); trx3.commit();
優化為:
trx1.exec(); trx2.exec(); trx3.exec();
trx1.commit(); trx2.commit(); trx3.commit();
這個小小的改動(改動成本極低),不能徹底解決多庫分布式事務資料一緻性問題,但能大大降低資料不一緻的機率,犧牲的是吞吐量。
對于一緻性與吞吐量的折衷,還需要業務架構師謹慎權衡折衷。
畫外音:還是那句話,一切脫離業務常見的架構設計,都是耍流氓。
思路比結論重要,希望大家有收獲。
架構師之路-分享可落地的技術文章