歡迎光臨
每天分享高質量文章

分佈式事務,原來可以這麼玩

點擊▲關註 “資料和雲”   給公眾號標星置頂

更多精彩 第一時間直達

多個資料要同時操作,如何保證資料的完整性,以及一致性?

事務,是常見的做法。

舉個慄子

用戶下了一個訂單,需要修改餘額表訂單流水,於是會有類似的偽代碼:

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會嵌套非常多層

畫外音:上面的例子還只考慮了餘額+訂單的一致性,就有2*2=4個分支,如果要考慮餘額+訂單+流水的一致性,則會有2*2*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();

這個小小的改動(改動成本極低),不能徹底解決多庫分佈式事務資料一致性問題,但能大大降低資料不一致的概率,犧牲的是吞吐量。

對於一致性與吞吐量的折衷,還需要業務架構師謹慎權衡折衷。

畫外音:還是那句話,一切脫離業務常見的架構設計,都是耍流氓。

思路比結論重要,希望大家有收穫。

 

轉載自:架構師之路

    赞(0)

    分享創造快樂