多個數(shù)據(jù)要同時操作衣洁，如何保證數(shù)據(jù)的完整性，以及一致性抖仅？
答?：?事務(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;
?●?如果對余額表智听，訂單表，流水表的SQL操作全部成功渡紫，則全部提交??●?如果任何一個出現(xiàn)問題到推，則全部回滾 事務(wù)，以保證數(shù)據(jù)的完整性以及一致性腻惠。
事務(wù)的方案會有什么潛在問題环肘？
答?：互聯(lián)網(wǎng)的業(yè)務(wù)特點，數(shù)據(jù)量較大集灌，并發(fā)量較大悔雹，經(jīng)常使用?拆庫?的方式提升系統(tǒng)的性能。如果進(jìn)行了拆庫欣喧，?余額腌零、訂單、流水可能分布在不同的數(shù)據(jù)庫?上唆阿，甚至不同的數(shù)據(jù)庫實例上益涧，此時就不能用數(shù)據(jù)庫原生事務(wù)來保證數(shù)據(jù)的一致性了。
高并發(fā)易落地的分布式事務(wù)驯鳖，是行業(yè)沒有很好解決的難題闲询，那怎么辦呢？
答?：?補償事務(wù)?是一種常見的實踐浅辙。
什么是補償事務(wù)扭弧？
答：補償事務(wù)，是一種在業(yè)務(wù)端實施?業(yè)務(wù)逆向操作事務(wù)?记舆。
舉個栗子：
修改余額?鸽捻，事務(wù)為：
int??Do_AccountT?(uid, money){
start transaction;
//余額改變money這么多
CURD table t_account with money for uid;
anyException rollback return NO;
commit;
return YES;
}
那么，修改余額，補償事務(wù)可以是：
int??Compensate_AccountT?(uid, money){
//做一個money的反向操作
return Do_AccountT(uid, -1*money){
}
同理御蒲，訂單操作衣赶，事務(wù)是：Do_OrderT，新增一個訂單厚满；
訂單操作?府瞄，補償事務(wù)是：Compensate_OrderT，刪除一個訂單痰滋。
要保證余額與訂單的一致性摘能，偽代碼：
// 執(zhí)行第一個事務(wù)
int flag = Do_AccountT();
if(flag=YES){
//第一個事務(wù)成功，則執(zhí)行第二個事務(wù)
flag= Do_OrderT();
if(flag=YES){
// 第二個事務(wù)成功敲街，則成功
return YES;
}
else{
// 第二個事務(wù)失敗，執(zhí)行第一個事務(wù)的補償事務(wù)
Compensate_AccountT();
}
}
補償事務(wù)有什么缺點严望？
●?不同的業(yè)務(wù)要寫不同的補償事務(wù)多艇，?不具備通用性?；
●?沒有考慮補償事務(wù)的失敗?像吻；
●?如果業(yè)務(wù)流程很復(fù)雜峻黍，?if/else會嵌套非常多層?；
畫外音：上面的例子還只考慮了余額+訂單的一致性拨匆，就有2*2=4個分支姆涩，如果要考慮余額+訂單+流水的一致性，則會有2*2*2=8個if/else分支惭每，復(fù)雜性呈指數(shù)級增長骨饿。
還有其它簡易一致性實踐么？
答?：多個數(shù)據(jù)庫實例上的多個事務(wù)台腥，要保證一致性宏赘，可以進(jìn)行“?后置提交優(yōu)化?”。
單庫?是用這樣一個大事務(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;
拆分成了多個庫后黎侈，大事務(wù)會變成三個小事務(wù)：
start transaction1;
//第一個庫事務(wù)執(zhí)行
CURD table t_account; any Exception rollback;
…
// 第一個庫事務(wù)提交
commit1;
start transaction2;
//第二個庫事務(wù)執(zhí)行
CURD table t_order; any Exception rollback;
…
// 第二個庫事務(wù)提交
commit2;
start transaction3;
//第三個庫事務(wù)執(zhí)行
CURD table t_flow; any Exception rollback;
…
// 第三個庫事務(wù)提交
commit3;
畫外音：再次提醒察署，這三個事務(wù)發(fā)生在三個庫，甚至3個不同實例的數(shù)據(jù)庫上峻汉。
一個事務(wù)贴汪，分成執(zhí)行與提交兩個階段：
?●?執(zhí)行(CURD)的時間很長??●?提交(commit)的執(zhí)行很快 于是整個執(zhí)行過程的時間軸如下：
第一個事務(wù)執(zhí)行200ms，提交1ms休吠；
第二個事務(wù)執(zhí)行120ms扳埂，提交1ms；
第三個事務(wù)執(zhí)行80ms蛛碌，提交1ms聂喇；
在什么時候，會出現(xiàn)不一致？
答?：第一個事務(wù)成功提交之后希太，最后一個事務(wù)成功提交之前克饶，如果出現(xiàn)問題（例如服務(wù)器重啟，數(shù)據(jù)庫異常等）誊辉，都可能導(dǎo)致數(shù)據(jù)不一致矾湃。
畫外音：如上圖，最后202ms內(nèi)出現(xiàn)異常堕澄，會出現(xiàn)不一致邀跃。
什么是后置提交優(yōu)化？
答?：如果改變事務(wù)執(zhí)行與提交的時序蛙紫，變成?事務(wù)先執(zhí)行拍屑，最后一起提交?。
第一個事務(wù)執(zhí)行200ms坑傅，第二個事務(wù)執(zhí)行120ms僵驰，第三個事務(wù)執(zhí)行80ms；
第一個事務(wù)提交1ms唁毒，第二個事務(wù)?提交?1ms蒜茴，第三個事務(wù)?提交?1ms；
后置提交優(yōu)化后浆西，在什么時候粉私，會出現(xiàn)不一致？
答?：問題的答案與之前相同近零，第一個事務(wù)成功提交之后诺核，最后一個事務(wù)成功提交之前，如果出現(xiàn)問題（例如服務(wù)器重啟秒赤，數(shù)據(jù)庫異常等）猪瞬，都可能導(dǎo)致數(shù)據(jù)不一致。
畫外音：?如上?圖入篮，最后2ms內(nèi)出現(xiàn)異常陈瘦，會出現(xiàn)不一致。
有什么區(qū)別和差異潮售？
答?：
●?串行事務(wù)方案?痊项，總執(zhí)行時間是303ms，最后202ms內(nèi)出現(xiàn)異常都可能導(dǎo)致不一致酥诽；
●?后置提交優(yōu)化方案?鞍泉，總執(zhí)行時間也是303ms，但最后2ms內(nèi)出現(xiàn)異常才會導(dǎo)致不一致肮帐；
雖然沒有徹底解決數(shù)據(jù)的一致性問題咖驮，但?不一致出現(xiàn)的概率大大降低了?边器。
畫外音：上面這個例子，概率降低了100倍托修。
后置提交優(yōu)化?忘巧，有什么不足？
答?：對事務(wù)吞吐量會有影響：
●?串行事務(wù)方案?睦刃，?第一個庫事務(wù)提交砚嘴，數(shù)據(jù)庫連接就釋放了?；
●?后置提交優(yōu)化方案?涩拙，?所有庫的連接际长，要等到所有事務(wù)執(zhí)行完才釋放?；
這就意味著兴泥，數(shù)據(jù)庫連接占用的時間增長了工育，系統(tǒng)整體的吞吐量降低了。
總結(jié)
分布式事務(wù)搓彻，兩種常見的實踐：
?●?補償事務(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();
這個小小的改動（改動成本極低）翅娶，不能徹底解決多庫分布式事務(wù)數(shù)據(jù)一致性問題，但能大大降低數(shù)據(jù)不一致的概率好唯，犧牲的是吞吐量。
對于一致性與吞吐量的折衷燥翅，還需要業(yè)務(wù)架構(gòu)師謹(jǐn)慎權(quán)衡折衷骑篙。
歡迎工作一到五年的Java工程師朋友們加入Java架構(gòu)開發(fā)： 855835163
群內(nèi)提供免費的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)森书、高性能及分布式靶端、Jvm性能調(diào)優(yōu)、Spring源碼凛膏，MyBatis杨名，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構(gòu)資料）合理利用自己每一分每一秒的時間來學(xué)習(xí)提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰猖毫！趁年輕台谍，使勁拼，給未來的自己一個交代吁断！
