分佈式事務，原來能夠這麼玩？

多個數據要同時操做，如何保證數據的完整性，以及一致性？

答 ： 事務 ，是常見的作法。

舉個栗子：

用戶下了一個訂單，須要修改 餘額表 ， 訂單 表 ， 流水 表 ，因而會有相似的僞代碼：

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等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！