分布式事務，原來可以這么玩？
多個數據要同時操作，如何保證數據的完整性，以及一致性?
答：事務，是常見的做法。
舉個栗子：
用戶下了一個訂單，需要修改余額表，訂單表，流水表，于是會有類似的偽代碼：
- 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();
這個小小的改動(改動成本極低)，不能徹底解決多庫分布式事務數據一致性問題，但能大大降低數據不一致的概率，犧牲的是吞吐量。
對于一致性與吞吐量的折衷，還需要業務架構師謹慎權衡折衷。
畫外音：還是那句話，一切脫離業務常見的架構設計，都是耍流氓。
思路比結論重要，希望大家有收獲。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
