本文先介紹傳統關係數據庫中事務的ACID特性，再介紹分佈式系統中的經典理論——CAP定理和BASE理論。
事務
事務的定義：
事務（Transaction）是由一系列對系統中數據進行訪問與更新的操作所組成的一個程序執行邏輯單元（Unit），狹義上的事務特指數據庫事務。
事務的作用：
當多個應用程序併發訪問數據庫時，事務可以在這些應用程序之間提供一個隔離方法，以防止彼此的操作相互干擾。-事務爲數據庫操作序列提供了一個從失敗中恢復到正常狀態的方法，同時提供了數據庫即使在異常狀態下仍能保持數據一致性的方法。事務具有四個特性，分別是原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）,簡稱爲事務的ACID特性。
ACID
原子性
事務的原子性是指事務必須是一個原子的操作序列單元。事務中包含的各項操作在一次執行過程中，要麼全部執行，要麼全部不執行。任何一項操作失敗都將導致整個事務失敗，同時其他已經被執行的操作都將被撤銷並回滾。只有所有的操作全部成功，整個事務纔算是成功完成。
一致性
事務的一致性是指事務的執行不能破壞數據庫數據的完整性和一致性，一個事務在執行前後，數據庫都必須處於一致性狀態。換句話說，事務的執行結果必須是使數據庫從一個一致性狀態轉變到另一個一致性狀態。舉個例子銀行的轉賬操作就是一個事務。假設A和B原來賬戶都有100元。此時A轉賬給B50元，轉賬結束後，應該是A賬戶減去50元變成50元，B賬戶增加50元變成150元。A、B的賬戶總和還是200元。轉賬前後，數據庫就是從一個一致性狀態（A100元，B100元，A、B共200元）轉變到另一個一致性狀態（A50元，B150元，A、B共200元）。假設轉賬結束後只扣了A賬戶，沒有增加B賬戶，這時數據庫就處於不一致的狀態。隔離性事務的隔離性是指在併發環境中，併發的事務是相互隔離的，事務之間互不干擾。在標準的SQL規範中，定義的4個事務隔離級別，不同隔離級別對事務的處理不同。4個隔離級別分別是：未授權讀取、授權讀取、可重複讀取和串行化。下表展示了不同隔離級別下事務訪問數據的差異
以上4個級別的隔離性依次增強，分別解決不同的問題。事務隔離級別越高，就越能保證數據的完整性和一致性，但同時對併發性能的影響也越大。通常，對於絕大多數的應用來說，可以優先考慮將數據庫系統的隔離級別設置爲授權讀取，這能夠在避免髒讀的同時保證較好的併發性能。儘管這種事務隔離級別會導致不可重複讀、幻讀和第二類丟失更新等併發問題，但較爲科學的做法是在可能出現這類問題的個別場合中，由應用程序主動採用悲觀鎖或樂觀鎖來進行事務控制。持久性事務的持久性又稱爲永久性，是指一個事務一旦提交，對數據庫中對應數據的狀態變更就應該是永久性的。即使發生系統崩潰或機器宕機等故障，只要數據庫能夠重新啓動，那麼一定能夠將其恢復到事務成功結束時的狀態。
分佈式事務
事務在分佈式計算領域也得到了廣泛的應用。在單機數據庫中，我們很容易能夠實現一套滿足ACID特性的事務處理系統，但是在分佈式數據庫中，數據分散在各臺不同的機器上，如何對這些數據進行分佈式事務處理具有非常大的挑戰。 - 分佈式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於分佈式系統的不同節點之上。通常一個分佈式事務會涉及對多個數據源或業務系統的操作。舉個例子來說明分佈式事務。一個最典型的分佈式事務場景是跨行的轉賬操作。該操作涉及調用兩個異地的銀行服務。其中一個是本地銀行提供的取款服務，另一個是目標銀行提供的存款服務，這兩個服務本身是無狀態且相互獨立的，共同構成了一個完整的分佈式事務。取款和存款兩個步驟要麼都執行，要麼都不執行。否則，如果從本地銀行取款成功，但是因爲某種原因存款服務失敗了，那麼必須回滾到取款之前的狀態，否則就會導致數據不一致。從上面的例子可以看出，一個分佈式事務可以看作是由多個分佈式操作序列組成的，例如上面例子中的取款服務和存款服務，通常可以把這一系列分佈式的操作序列稱爲子事。由於分佈式事務中，各個子事務的執行是分佈式的，因此要實現一種能夠保證ACID特性的分佈式事務處理系統就顯得格外複雜。
CAP定理
CAP定理：一個分佈式系統不可能同時滿足一致性（C:Consistency）、可用性（A:Availability）和分區容錯性（P:Partition tolerance）這三個基本要求，最多隻能滿足其中的兩項。
一致性
在分佈式環境中，一致性是指數據在多個副本之間是否能夠保持一致的特性（這點跟ACID中的一致性含義不同）。對於一個將數據副本分佈在不同節點上的分佈式系統來說，如果對第一個節點的數據進行了更新操作並且更新成功後，卻沒有使得第二個節點上的數據得到相應的更新，於是在對第二個節點的數據進行讀取操作時，獲取的依然是更新前的數據（稱爲髒數據），這就是典型的分佈式數據不一致情況。在分佈式系統中，如果能夠做到針對一個數據項的更新操作執行成功後，所有的用戶都能讀取到最新的值，那麼這樣的系統就被認爲具有強一致性（或嚴格的一致性）。
可用性
可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠*有限的時間內返回結果，如果超過了這個時間範圍，那麼系統就被認爲是不可用的。『有限的時間內』是一個在系統設計之初就設定好的運行指標，不同的系統會有很大的差別。比如對於一個在線搜索引擎來說，通常在0.5秒內需要給出用戶搜索關鍵詞對應的檢索結果。而對應Hive來說，一次正常的查詢時間可能在20秒到30秒之間。『返回結果』是可用性的另一個非常重要的指標，它要求系統在完成對用戶請求的處理後，返回一個正常的響應結果。正常的響應結果通常能夠明確地反映出對請求的處理結果，及成功或失敗，而不是一個讓用戶感到困惑的返回結果。讓我們再來看看上面提到的在線搜索引擎的例子，如果用戶輸入指定的搜索關鍵詞後，返回的結果是一個系統錯誤，比如"OutOfMemoryErroe"或"System Has Crashed"等提示語，那麼我們認爲此時系統是不可用的。
分區容錯性
分區容錯性要求一個分佈式系統需要具備如下特性：分佈式系統在遇到任何網絡分區故障的時候，仍然能夠保證對外提供滿足一致性和可用性的服務，除非是整個網絡環境都發生了故障。網絡分區是指在分佈式系統中，不同的節點分佈在不同的**子網絡**（機房或異地網絡等）中，由於一些特殊的原因導致這些子網絡之間出現網絡不連通的狀況，但各個子網絡的**內部網絡是正常的**，從而導致整個系統的網絡環境被切分成了若干個孤立的區域。以上就是對CAP定理中一致性、可用性和分區容錯性的講解。既然一個分佈式系統無法同時滿足上述三個要求，而只能滿足其中的兩項，因此在對CAP定理應用時，我們就需要拋棄其中的一項，下表是拋棄CAP中任意一項特性的場景說明。
BASE理論
BASE是Basically Available(基本可用）、Soft state(軟狀態）和Eventually consistent(最終一致性）三個短語的簡寫。BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性，但每個應用都可以根據自身的業務特點，採用適當的方法來使系統達到最終一致性。接下來，我們着重對BASE中的三要素進行講解。
基本可用
基本可用是指分佈式系統在出現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價於系統不可用。一下就是兩個"基本可用"的例子。 - 響應時間上的損失：正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由於出現故障（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1~2秒。 -功能上的損失：正常情況下，在一個電子商務網站（比如淘寶）上購物，消費者幾乎能夠順利地完成每一筆訂單。但在一些節日大促購物高峯的時候（比如雙十一、雙十二），由於消費者的購物行爲激增，爲了保護系統的穩定性（或者保證一致性），部分消費者可能會被引導到一個降級頁面，如下：
rui如下：
軟狀態
軟狀態是指允許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同的數據副本之間進行數據同步的過程存在延時。
最終一致性
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。最終一致性是一種特殊的弱一致性：系統能夠保證在沒有其他新的更新操作的情況下，數據最終一定能夠達到一致的狀態，因此所有客戶端對系統的數據訪問都能夠獲取到最新的值。同時，在沒有發生故障的前提下，數據到達一致狀態的時間延遲，取決於網絡延遲、系統負載和數據複製方案設計等因素。在實際工程實踐中，最終一致性存在一下五類主要變種。 - 因果一致性(Causal consistency) -讀己之所寫(Read your writes) -會話一致性(Session consistency) -單調讀一致性(Monotonic read consistency) -單調寫一致性(Monotonic write consistency)以上就是最終一致性的五種常見的變種，在實際系統實踐中，可以將其中的若干個變種互相結合起來，以構建一個具有最終一致性特性的分佈式系統。
事實上，最終一致性並不是只有那些大型分佈式系統才涉及的特性，許多現代的關係型數據庫都採用了最終一致性模型。在現代關係型數據庫中（比如MySQL和PostgreSQL），大多都會採用同步或異步方式來實現主備數據複製技術。在同步方式中，數據的複製過程通常是更新事務的一部分，因此在事務完成後，主備數據庫的數據就會達到一致。而在異步方式中，備庫的更新往往會存在延時，這取決於事務日誌在主備數據庫之間傳輸的時間長短。如果傳輸時間過長或者甚至在日誌傳輸過程中出現異常導致無法及時將事務應用到備庫上，那麼很顯然，從備庫中讀取的數據將是舊的，因此就出現了數據不一致的情況。當然，無論是採用多次重試還是人爲數據訂正，關係型數據庫還是能夠保證最終數據達到一致，這就是系統提供最終一致性保證的經典案例。
參考資料
《從Paxos到ZooKeeper——分佈式一致性原理與實踐》
如果你想學習Java工程化、高性能及分佈式、高性能、深入淺出。性能調優、Spring，MyBatis，Netty源碼分析和大數據等知識點可以來找我。
而現在我就有一個平臺可以提供給你們學習，讓你在實踐中積累經驗掌握原理。主要方向是JAVA架構師。如果你想拿高薪，想突破瓶頸，想跟別人競爭能取得優勢的，想進BAT但是有擔心面試不過的，可以加我的Java架構進階羣：554355695
注：加羣要求
1、具有2-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。
3、如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加。
5.阿里Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶着大家全面、科學地建立自己的技術體系和技術認知！
6.小號加羣一律不給過，謝謝。