多個數(shù)據(jù)要同時操作，如何保證數(shù)據(jù)的完整性，以及一致性?

答：事務，是常見的做法。

[[247728]]

舉個栗子：

用戶下了一個訂單，需要修改余額表，訂單表，流水表，于是會有類似的偽代碼：

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操作全部成功，則全部提交
• 如果任何一個出現(xiàn)問題，則全部回滾

事務，以保證數(shù)據(jù)的完整性以及一致性。

事務的方案會有什么潛在問題?

答：互聯(lián)網(wǎng)的業(yè)務特點，數(shù)據(jù)量較大，并發(fā)量較大，經(jīng)常使用拆庫的方式提升系統(tǒng)的性能。如果進行了拆庫，余額、訂單、流水可能分布在不同的數(shù)據(jù)庫上，甚至不同的數(shù)據(jù)庫實例上，此時就不能用數(shù)據(jù)庫原生事務來保證數(shù)據(jù)的一致性了。

高并發(fā)易落地的分布式事務，是行業(yè)沒有很好解決的難題，那怎么辦呢?

答：補償事務是一種常見的實踐。

什么是補償事務?

答：補償事務，是一種在業(yè)務端實施業(yè)務逆向操作事務。

舉個栗子：

修改余額，事務為：

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，刪除一個訂單。

要保證余額與訂單的一致性，偽代碼：

// 執(zhí)行第一個事務 
int flag = Do_AccountT(); 
if(flag=YES){ 
    //第一個事務成功，則執(zhí)行第二個事務 
    flag= Do_OrderT(); 
    if(flag=YES){ 
        // 第二個事務成功，則成功 
        return YES; 
    } 
    else{ 
        // 第二個事務失敗，執(zhí)行第一個事務的補償事務 
        Compensate_AccountT(); 
    } 
} 

補償事務有什么缺點?

• 不同的業(yè)務要寫不同的補償事務，不具備通用性;
• 沒有考慮補償事務的失敗;
• 如果業(yè)務流程很復雜，if/else會嵌套非常多層;

畫外音：上面的例子還只考慮了余額+訂單的一致性，就有2*2=4個分支，如果要考慮余額+訂單+流水的一致性，則會有2*2*2=8個if/else分支，復雜性呈指數(shù)級增長。

還有其它簡易一致性實踐么?

答：多個數(shù)據(jù)庫實例上的多個事務，要保證一致性，可以進行“后置提交優(yōu)化”。

單庫是用這樣一個大事務保證一致性：

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; 
         //第一個庫事務執(zhí)行 
         CURD table t_account; any Exception rollback; 
         … 
// 第一個庫事務提交 
commit1; 
 
start transaction2; 
         //第二個庫事務執(zhí)行 
         CURD table t_order; any Exception rollback; 
         … 
// 第二個庫事務提交 
commit2; 
 
start transaction3; 
         //第三個庫事務執(zhí)行 
         CURD table t_flow; any Exception rollback; 
         … 
// 第三個庫事務提交 
commit3; 

畫外音：再次提醒，這三個事務發(fā)生在三個庫，甚至3個不同實例的數(shù)據(jù)庫上。

一個事務，分成執(zhí)行與提交兩個階段：

• 執(zhí)行(CURD)的時間很長
• 提交(commit)的執(zhí)行很快

于是整個執(zhí)行過程的時間軸如下：

• 第一個事務執(zhí)行200ms，提交1ms;
• 第二個事務執(zhí)行120ms，提交1ms;
• 第三個事務執(zhí)行80ms，提交1ms;

在什么時候，會出現(xiàn)不一致?

答：第一個事務成功提交之后，最后一個事務成功提交之前，如果出現(xiàn)問題(例如服務器重啟，數(shù)據(jù)庫異常等)，都可能導致數(shù)據(jù)不一致。

畫外音：如上圖，最后202ms內(nèi)出現(xiàn)異常，會出現(xiàn)不一致。

什么是后置提交優(yōu)化?

答：如果改變事務執(zhí)行與提交的時序，變成事務先執(zhí)行，最后一起提交。

• 第一個事務執(zhí)行200ms，第二個事務執(zhí)行120ms，第三個事務執(zhí)行80ms;
• 第一個事務提交1ms，第二個事務提交1ms，第三個事務提交1ms;

后置提交優(yōu)化后，在什么時候，會出現(xiàn)不一致?

答：問題的答案與之前相同，第一個事務成功提交之后，最后一個事務成功提交之前，如果出現(xiàn)問題(例如服務器重啟，數(shù)據(jù)庫異常等)，都可能導致數(shù)據(jù)不一致。

畫外音：如上圖，最后2ms內(nèi)出現(xiàn)異常，會出現(xiàn)不一致。

有什么區(qū)別和差異?

答：

• 串行事務方案，總執(zhí)行時間是303ms，最后202ms內(nèi)出現(xiàn)異常都可能導致不一致;
• 后置提交優(yōu)化方案，總執(zhí)行時間也是303ms，但最后2ms內(nèi)出現(xiàn)異常才會導致不一致;

雖然沒有徹底解決數(shù)據(jù)的一致性問題，但不一致出現(xiàn)的概率大大降低了。

畫外音：上面這個例子，概率降低了100倍。

后置提交優(yōu)化，有什么不足?

答：對事務吞吐量會有影響：

• 串行事務方案，第一個庫事務提交，數(shù)據(jù)庫連接就釋放了;
• 后置提交優(yōu)化方案，所有庫的連接，要等到所有事務執(zhí)行完才釋放;

這就意味著，數(shù)據(jù)庫連接占用的時間增長了，系統(tǒng)整體的吞吐量降低了。

總結

分布式事務，兩種常見的實踐：

• 補償事務
• 后置提交優(yōu)化

把

trx1.exec(); trx1.commit(); 
trx2.exec(); trx2.commit(); 
trx3.exec(); trx3.commit(); 

優(yōu)化為：

trx1.exec(); trx2.exec(); trx3.exec(); 
trx1.commit(); trx2.commit(); trx3.commit(); 

這個小小的改動(改動成本極低)，不能徹底解決多庫分布式事務數(shù)據(jù)一致性問題，但能大大降低數(shù)據(jù)不一致的概率，犧牲的是吞吐量。

對于一致性與吞吐量的折衷，還需要業(yè)務架構師謹慎權衡折衷。

畫外音：還是那句話，一切脫離業(yè)務常見的架構設計，都是耍流氓。

思路比結論重要，希望大家有收獲。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】

戳這里，看該作者更多好文