分布式事務(wù)，原來(lái)可以這么玩？

作者：58沈劍 2018-10-28 17:54:00


分布式 多個(gè)數(shù)據(jù)要同時(shí)操作，如何保證數(shù)據(jù)的完整性，以及一致性呢?答案是事務(wù)，這是常見(jiàn)的做法。

10多年的南崗網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。營(yíng)銷型網(wǎng)站的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整南崗建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“南崗網(wǎng)站設(shè)計(jì)”,“南崗網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

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

答：事務(wù)，是常見(jiàn)的做法。

舉個(gè)栗子：

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

  
 
 
 

   
  
  
  
start transaction; 
   
  
  
  
 CURD table t_account;  any Exception rollback; 
   
  
  
  
 CURD table t_order;      any Exception rollback; 
   
  
  
  
 CURD table t_flow;        any Exception rollback; 
   
  
  
  
commit; 
  
 
 
 

• 如果對(duì)余額表，訂單表，流水表的SQL操作全部成功，則全部提交
• 如果任何一個(gè)出現(xiàn)問(wèn)題，則全部回滾

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

事務(wù)的方案會(huì)有什么潛在問(wèn)題?

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

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

答：補(bǔ)償事務(wù)是一種常見(jiàn)的實(shí)踐。

什么是補(bǔ)償事務(wù)?

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

舉個(gè)栗子：

修改余額，事務(wù)為：

  
 
 
 

   
  
  
  
int Do_AccountT(uid, money){ 
   
  
  
  
    start transaction; 
   
  
  
  
         //余額改變money這么多 
   
  
  
  
         CURD table t_account with money for uid; 
   
  
  
  
         anyException rollback return NO; 
   
  
  
  
    commit; 
   
  
  
  
    return YES; 
   
  
  
  
} 
   
  
  
  
  
  
 
 
 

那么，修改余額，補(bǔ)償事務(wù)可以是：

  
 
 
 

   
  
  
  
int Compensate_AccountT(uid, money){ 
   
  
  
  
         //做一個(gè)money的反向操作 
   
  
  
  
         return Do_AccountT(uid, -1*money){ 
   
  
  
  
} 
  
 
 
 

同理，訂單操作，事務(wù)是：Do_OrderT，新增一個(gè)訂單;

訂單操作，補(bǔ)償事務(wù)是：Compensate_OrderT，刪除一個(gè)訂單。

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

  
 
 
 

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

補(bǔ)償事務(wù)有什么缺點(diǎn)?

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

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

還有其它簡(jiǎn)易一致性實(shí)踐么?

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

單庫(kù)是用這樣一個(gè)大事務(wù)保證一致性：

  
 
 
 

   
  
  
  
start transaction; 
   
  
  
  
 CURD table t_account;  any Exception rollback; 
   
  
  
  
 CURD table t_order;      any Exception rollback; 
   
  
  
  
 CURD table t_flow;        any Exception rollback; 
   
  
  
  
commit; 
  
 
 
 

拆分成了多個(gè)庫(kù)后，大事務(wù)會(huì)變成三個(gè)小事務(wù)：

  
 
 
 

   
  
  
  
start transaction1; 
   
  
  
  
         //第一個(gè)庫(kù)事務(wù)執(zhí)行 
   
  
  
  
         CURD table t_account; any Exception rollback; 
   
  
  
  
         … 
   
  
  
  
// 第一個(gè)庫(kù)事務(wù)提交 
   
  
  
  
commit1; 
   
  
  
  
 
   
  
  
  
start transaction2; 
   
  
  
  
         //第二個(gè)庫(kù)事務(wù)執(zhí)行 
   
  
  
  
         CURD table t_order; any Exception rollback; 
   
  
  
  
         … 
   
  
  
  
// 第二個(gè)庫(kù)事務(wù)提交 
   
  
  
  
commit2; 
   
  
  
  
 
   
  
  
  
start transaction3; 
   
  
  
  
         //第三個(gè)庫(kù)事務(wù)執(zhí)行 
   
  
  
  
         CURD table t_flow; any Exception rollback; 
   
  
  
  
         … 
   
  
  
  
// 第三個(gè)庫(kù)事務(wù)提交 
   
  
  
  
commit3; 
  
 
 
 

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

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

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

于是整個(gè)執(zhí)行過(guò)程的時(shí)間軸如下：

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

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

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

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

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

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

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

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

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

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

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

答：

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

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

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

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

答：對(duì)事務(wù)吞吐量會(huì)有影響：

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

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

總結(jié)

分布式事務(wù)，兩種常見(jiàn)的實(shí)踐：

• 補(bǔ)償事務(wù)
• 后置提交優(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(); 
  
 
 
 

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

對(duì)于一致性與吞吐量的折衷，還需要業(yè)務(wù)架構(gòu)師謹(jǐn)慎權(quán)衡折衷。

畫外音：還是那句話，一切脫離業(yè)務(wù)常見(jiàn)的架構(gòu)設(shè)計(jì)，都是耍流氓。

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

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

網(wǎng)頁(yè)名稱：分布式事務(wù)，原來(lái)可以這么玩？
文章源于：http://uogjgqi.cn/article/dhshodi.html