答：事務。
舉個例子：
使用者下了乙個訂單，需要修改餘額表，訂單表，流水表，於是會有類似的偽**：
start transaction;
curd table t_account; any exception rollback;
curd table t_order; any exception rollback;
curd table t_flow; any exception rollback;
commit;
事務，可保證資料的完整性以及一致性。
多庫環境下，事務的方案會有什麼潛在問題？
答：網際網路的業務特點，資料量較大，併發量較大，經常使用拆庫的方式提公升系統的效能。
如果進行了拆庫，餘額、訂單、流水可能分布在不同的資料庫上，甚至不同的資料庫例項上，此時就不能用資料庫原生事務來保證資料的一致性了。
答：補償事務是一種常見的實踐。
什麼是補償事務？
答：補償事務，是一種在業務端實施業務逆向操作事務。
舉個栗子：
修改餘額，事務為：
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();
補償事務有什麼缺點？
畫外音：上面的例子還只考慮了餘額+訂單的一致性，就有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;
乙個事務，分成執行與提交兩個階段：
於是整個執行過程的時間軸如下：
第乙個事務執行200ms，提交1ms；
第二個事務執行120ms，提交1ms；
第三個事務執行80ms，提交1ms；
在什麼時候，會出現不一致？
答：第乙個事務成功提交之後，最後乙個事務成功提交之前，如果出現問題(例如伺服器重啟，資料庫異常等)，都可能導致資料不一致。
畫外音：如上圖，最後202ms內出現異常，會出現不一致。
什麼是後置提交優化？
答：如果改變事務執行與提交的時序，變成事務先執行，最後一起提交。
第乙個事務執行200ms，第二個事務執行120ms，第三個事務執行80ms；
第乙個事務提交1ms，第二個事務提交1ms，第三個事務提交1ms；
後置提交優化後，在什麼時候，會出現不一致？
答：問題的答案與之前相同，第乙個事務成功提交之後，最後乙個事務成功提交之前，如果出現問題(例如伺服器重啟，資料庫異常等)，都可能導致資料不一致。
畫外音：如上圖，最後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();
這個小小的改動(改動成本極低)，不能徹底解決多庫分布式事務資料一致性問題，但能大大降低資料不一致的概率，犧牲的是吞吐量。
事務 分布式事務
事務 邏輯上的一組操作，要麼都成功要麼都失敗 事務的四個特性 acid 原子性，一致性，隔離性，永續性 事務的隔離級別 讀未提交 產生髒讀 讀已提交 不可重複讀 可重複讀 幻讀 mysql預設 序列化讀 效能最低 傳播行為 7個 七種傳播行為 required 支援當前事務，如果不存在，就新建乙個 ...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...