事務就是提供一種「要麼什麼都不做，要麼做全套（all or nothing）」機制。
a：原子性(atomicity)：你買東西要麼交錢收貨一起都執行，要麼發不出貨，就退錢。
乙個事務(transaction)中的所有操作，要麼全部完成，要麼全部不完成，不會結束在中間某個環節。
事務在執行過程中發生錯誤，會被回滾（rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
c：一致性(consistency)：你買東西，買之前和買之後東西是一樣的，如果在買的過程，你不給錢，老闆就把東西收回放到原來位置。
事務的一致性指的是在乙個事務執行之前和執行之後資料庫都必須處於一致性狀態。
如果事務成功地完成，那麼系統中所有變化將正確地應用，系統處於有效狀態。
如果在事務**現錯誤，那麼系統中的所有變化將自動地回滾，系統返回到原始狀態。
i：隔離性(isolation)：你買東西這個事情，是不影響其他人的。
指的是在併發環境中，當不同的事務同時操縱相同的資料時，每個事務都有各自的完整資料空間。
由併發事務所做的修改必須與任何其他併發事務所做的修改隔離。事務檢視資料更新時，資料所處的狀態要麼是另一事務修改它之前的狀態，要麼是另一事務修改它之後的狀態，事務不會檢視到中間狀態的資料。
d：永續性(durability)：你買東西的時候需要記錄在賬本上，即使老闆忘記了那也有據可查。
指的是只要事務成功結束，它對資料庫所做的更新就必須永久儲存下來。
即使發生系統崩潰，重新啟動資料庫系統後，資料庫還能恢復到事務成功結束時的狀態。
資料庫在提交事務的時候突然斷電，那麼它是怎麼樣恢復的呢？
本地事務資料庫斷電的這種情況，它是怎麼保證資料一致性的呢？我們使用sql server來舉例，我們知道我們在使用 sql server 資料庫是由兩個檔案組成的，乙個資料庫檔案和乙個日誌檔案，通常情況下，日誌檔案都要比資料庫檔案大很多。資料庫進行任何寫入操作的時候都是要先寫日誌的，同樣的道理，我們在執行事務的時候資料庫首先會記錄下這個事務的redo操作日誌，然後才開始真正運算元據庫，在操作之前首先會把日誌檔案寫入磁碟，那麼當突然斷電的時候，即使操作沒有完成，在重新啟動資料庫時候，資料庫會根據當前資料的情況進行undo回滾或者是redo前滾，這樣就保證了資料的強一致性。
為什麼要提到這個知識點呢？ 因為分布式系統的核心就是處理各種異常情況，這也是分布式系統複雜的地方，因為分布式的網路環境很複雜，這種「斷電」故障要比單機多很多，所以我們在做分布式系統的時候，最先考慮的就是這種情況。這些異常可能有 機器宕機、網路異常、訊息丟失、訊息亂序、資料錯誤、不可靠的tcp、儲存資料丟失、其他異常等等...
一次大的操作由不同的小操作組成，這些小的操作分布在不同的伺服器上，且屬於不同的應用，分布式事務需要保證這些小操作要麼全部成功，要麼全部失敗。分布式事務就是為了保證不同資料庫的資料一致性。
當我們的單個資料庫的效能產生瓶頸的時候，我們可能會對資料庫進行分割槽，這裡所說的分割槽指的是物理分割槽，分割槽之後可能不同的庫就處於不同的伺服器上了，這個時候單個資料庫的acid已經不能適應這種情況了，而在這種acid的集群環境下，再想保證集群的acid幾乎是很難達到，或者即使能達到那麼效率和效能會大幅下降，最為關鍵的是再很難擴充套件新的分割槽了，這個時候如果再追求集群的acid會導致我們的系統變得很差，這時我們就需要引入乙個新的理論原則來適應這種集群的情況，就是 cap 原則或者叫cap定理，那麼cap定理指的是什麼呢？
c：強一致性——在很高強度下保持資料一致，對某個指定的客戶端來說，讀操作能返回最新的寫操作。
a：高可用性——在併發量很高情況下依然可用，非故障的節點在合理的時間內返回合理的響應(不是錯誤和超時的響應)。可用性的兩個關鍵乙個是合理的時間，乙個是合理的響應。合理的時間指的是請求不能無限被阻塞，應該在合理的時間給出返回。合理的響應指的是系統應該明確返回結果並且結果是正確的。
p：分割槽容錯性——整個系統中某個元件故障時整個系統仍然可用而不是崩潰，比如這裡集群有多台機器，有台機器網路出現了問題，但是這個集群仍然可以正常工作。
注意：三者不能共有，如果感興趣可以搜尋 cap 的證明，在分布式系統中，網路無法 100% 可靠，分割槽其實是乙個必然現象。p必須保證。c和a之間二選一。因為要做到強一致性，需要在必要的地方加資料鎖，必然會影響效能。
cpap
案例1：乙個公司之內，使用者的資產可能分為好多個部分，比如餘額，積分，優惠券等等，在公司內部有可能積分功能由乙個微服務團隊維護，優惠券又是另外的團隊維護，這樣的話就無法保證積分扣減了之後，優惠券能否扣減成功。
案例2：對於乙個支付寶的轉賬業務來說，你給朋友轉錢，有可能你的資料庫是在北京，而你的朋友的錢是存在上海，所以我們依然無法保證他們能同時成功。
1 補償性策略，在服務執行失敗時，不進行回滾，因為一旦回滾，其他子系統的資料也要跟著更新改變，不利於維護，所以重複執行某個失敗的業務，如果數次不成功，傳送系統資訊，簡訊，以及伺服器日誌，後期通過人工處理該異常訂單
2 在訊息中介軟體中啟用訊息事務，當乙個訊息消費失敗時，回滾該訊息，等待重新消費。可以參考訊息佇列章節。
分布式事物
1 分布式事務 在單機應用上，我們使用事務是很方便的，因為所有的業務邏輯都在本地，資料庫事務就能解決 acid 問題，特別是使用一些j2ee的框架，每一層的業務邏輯都給我們安排得妥妥當當的。當系統已經被拆分部署到多個伺服器例項上時，一般每個伺服器都只負責維護乙個子系統一張 數張表。與單機相比，業務還...
XA 分布式事物
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...
分布式事物理解
1.單機事物理解 具有acid特性才能算是事物，a 原子性 即 事物的組成部分 要麼全部執行，要麼都不執行。原子性通過undo 實現，即事物執行過程中的步驟對應幾個版本，版本對應響應的undo回滾段，資料狀態的每次變化都會儲存在undo日誌裡。執行中某一步驟出了問題要回滾 通過該步驟前一段步驟對應的...