分散式事務，原來可以這麼玩？
多個數據要同時操作，如何保證資料的完整性，以及一致性？
答 ： 事務 ，是常見的做法。
舉個栗子：
使用者下了一個訂單，需要修改 餘額表 ， 訂單 表 ， 流水 表 ，於是會有類似的虛擬碼：
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();
這個小小的改動（改動成本極低），不能徹底解決多庫分散式事務資料一致性問題，但能大大降低資料不一致的概率，犧牲的是吞吐量。
對於一致性與吞吐量的折衷，還需要業務架構師謹慎權衡折衷。
歡迎工作一到五年的Java工程師朋友們加入Java架構開發： 855835163 群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！