：
事務，是常見的做法。
餘額表，訂單表
，流水表
，於是會有類似的偽**：
● 如果對餘額表，訂單表，流水表的sql操作全部成功，則全部提交
● 如果任何乙個出現問題，則全部回滾
：網際網路的業務特點，資料量較大，併發量較大，經常使用
拆庫的方式提公升系統的效能。如果進行了拆庫，
餘額、訂單、流水可能分布在不同的資料庫
上，甚至不同的資料庫例項上，此時就不能用資料庫原生事務來保證資料的一致性了。 ：
補償事務
是一種常見的實踐。
業務逆向操作事務。
，事務為：
do_accountt
(uid, money){
compensate_accountt
(uid, money){
，補償事務是：compensate_ordert，刪除乙個訂單。
：多個資料庫例項上的多個事務，要保證一致性，可以進行「
後置提交優化
」。是用這樣乙個大事務保證一致性：
● 執行(curd)的時間很長
● 提交(commit)的執行很快
：第乙個事務成功提交之後，最後乙個事務成功提交之前，如果出現問題（例如伺服器重啟，資料庫異常等），都可能導致資料不一致。
：如果改變事務執行與提交的時序，變成
事務先執行，最後一起提交
：問題的答案與之前相同，第乙個事務成功提交之後，最後乙個事務成功提交之前，如果出現問題（例如伺服器重啟，資料庫異常等），都可能導致資料不一致。
圖，最後2ms內出現異常，會出現不一致。 ：
不一致出現的概率大大降低了。
：對事務吞吐量會有影響：
● 補償事務
● 後置提交優化
比結論重要，希望大家有收穫。
原文發布時間為：2018-10-16
」。
原來EXECL可以這麼玩
前幾天產品經理拿一堆execl的資料，問我能否按照特定的格式匯入到資料庫中，我當時不太確定。因為我是乙個c 程式設計師，問了一下旁邊的同時，告訴我說可以去寫乙個程式，呼叫execl的元件，我當時就愣了，就這麼乙個小東西，還要去寫那個玩意兒，而且寫起來還是挺麻煩的。之後偶然臨機一動發現原來mysql可...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...