分布式事務，原來可以這麽玩？
阿新 • • 發佈：2018-10-21
圖片 數據量 sta mit 才會 串行 one star 可能
多個數據要同時操作，如何保證數據的完整性，以及一致性？
答 ： 事務 ，是常見的做法。
舉個栗子：
用戶下了一個訂單，需要修改 余額表 ， 訂單 表 ， 流水 表 ，於是會有類似的偽代碼：
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)的執行很快 於是整個執行過程的時間軸如下：
圖片描述(最多50字)
第一個事務執行200ms，提交1ms；
第二個事務執行120ms，提交1ms；
第三個事務執行80ms，提交1ms；
在什麽時候，會出現不一致？
答 ：第一個事務成功提交之後，最後一個事務成功提交之前，如果出現問題（例如服務器重啟，數據庫異常等），都可能導致數據不一致。圖片描述(最多50字)
畫外音：如上圖，最後202ms內出現異常，會出現不一致。
什麽是後置提交優化？
答 ：如果改變事務執行與提交的時序，變成 事務先執行，最後一起提交 。圖片描述(最多50字)
第一個事務執行200ms，第二個事務執行120ms，第三個事務執行80ms；
第一個事務提交1ms，第二個事務 提交 1ms，第三個事務 提交 1ms；
後置提交優化後，在什麽時候，會出現不一致？
答 ：問題的答案與之前相同，第一個事務成功提交之後，最後一個事務成功提交之前，如果出現問題（例如服務器重啟，數據庫異常等），都可能導致數據不一致。圖片描述(最多50字)
畫外音： 如上 圖，最後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();
這個小小的改動（改動成本極低），不能徹底解決多庫分布式事務數據一致性問題，但能大大降低數據不一致的概率，犧牲的是吞吐量。
對於一致性與吞吐量的折衷，還需要業務架構師謹慎權衡折衷。分布式事務，原來可以這麽玩？