雲計算平臺是非常巨大的分佈式系統，需要處理龐大的處理請求，因此任何小概率事件在此平臺中都必然發生。
DBMS強調ACID：原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性 (Durability)。其中的一致性強調當程序員定義的事務完成時，數據庫處於一致的狀態，如對於轉帳來說，事務完成時必須是A少了多少錢B就多了多 少錢。而對於很多互聯網應用來說，對於一致性和隔離性的要求可以降低，而可用性(Availability)的要求則更爲明顯。從而產生了兩種弱一致性的 理論：BASE和CAP。
BASE：Basically Availble --基本可用；Soft-state --；Eventual Consistency --最終一致性
CAP： Consistency 一致性；Availability 可用性； Tolerance of network Partition 分區容忍性（可理解爲部分節點故障或節點之間連接故障下系統仍可正常工作）。Brewer提出的該經驗理論認爲這三個目標最多隻能達成兩個，而另一個則需 要通過其他方式來彌補。
如果網絡中不存在分區，客戶端和存儲系統在同一環境中，通過分佈式事務機制可以保證一致性和可用性。但在大型網絡 系統中，分區是必然存在的，因此一般的選擇只能是在一致性和可用性之間權衡和折衷。如Ebay的經驗儘可能保證可用性，但採用周密調整數據庫操作的次序、 異步恢復事件，以及數據覈對（reconciliation）或者集中決算（settlement batches）等方式來幫助系統達到最終一致性。
實際互聯網系統往往都是ACID和BASE兩種系統的結合，例如用戶身份數據、交易數據通常採取ACID準則。
Guy Pardon認爲，CAP理論認爲三者不能同時達到是假定CAP被滿足是在at the same moment in time，如果放棄這個假定就可以得到三者都滿足的方案。但是在我看來，其方案也只是在可用性和一致性之間的折衷而已。放棄了讀寫一致性，讀到的可能只是 cache中的快照而不是最新值；通過在系統無分區時才執行寫入隊列來保證數據更新一致性，而結果則是異步獲得，相當於是對寫入可用性要求的一種降低。
數據一致性通常指關聯數據之間的邏輯關係是否正確和完整。而數據存儲的一致性模型則可以認爲是存儲系統和數據使用者之間的一種約定。如果使用者遵 循這種約定，則可以得到系統所承諾的訪問結果。
常用的一致性模型有：
a、嚴格一致性（linearizability, strict/atomic Consistency）：讀出的數據始終爲最近寫入的數據。這種一致性只有全局時鐘存在時纔有可能，在分佈式網絡環境不可能實現。
b、順序一致性（sequential consistency）：所有使用者以同樣的順序看到對同一數據的操作，但是該順序不一定是實時的。
c、因果一致性（causal consistency）：只有存在因果關係的寫操作纔要求所有使用者以相同的次序看到，對於無因果關係的寫入則並行進行，無次序保證。因果一致性可以看 做對順序一致性性能的一種優化，但在實現時必須建立與維護因果依賴圖，是相當困難的。
d、管道一致性（PRAM/FIFO consistency）：在因果一致性模型上的進一步弱化，要求由某一個使用者完成的寫操作可以被其他所有的使用者按照順序的感知到，而從不同使用者中 來的寫操作則無需保證順序，就像一個一個的管道一樣。 相對來說比較容易實現。
e、弱一致性（weak consistency）：只要求對共享數據結構的訪問保證順序一致性。對於同步變量的操作具有順序一致性，是全局可見的，且只有當沒有寫操作等待處理時 纔可進行，以保證對於臨界區域的訪問順序進行。在同步時點，所有使用者可以看到相同的數據。
f、 釋放一致性（release consistency）：弱一致性無法區分使用者是要進入臨界區還是要出臨界區， 釋放一致性使用兩個不同的操作語句進行了區分。需要寫入時使用者acquire該對象，寫完後release，acquire-release之間形成了 一個臨界區，提供 釋放一致性也就意味着當release操作發生後，所有使用者應該可以看到該操作。
g、最終一致性（eventual consistency）：當沒有新更新的情況下，更新最終會通過網絡傳播到所有副本點，所有副本點最終會一致，也就是說使用者在最終某個時間點前的中間 過程中無法保證看到的是新寫入的數據。可以採用最終一致性模型有一個關鍵要求：讀出陳舊數據是可以接受的。
h、delta consistency：系統會在delta時間內達到一致。這段時間內會存在一個不一致的窗口，該窗口可能是因爲log shipping的過程導致。
最終一致性的幾種具體實現：
1、讀不舊於寫一致性（Read-your-writes consistency）：使用者讀到的數據，總是不舊於自身上一個寫入的數據。
2、會話一致性（Session consistency）：比讀不舊於寫一致性更弱化。使用者在一個會話中才保證讀寫一致性，啓動新會話後則無需保證。
3、單讀一致性（Monotonic read consistency）：讀到的數據總是不舊於上一次讀到的數據。
4、單寫一致性（Monotonic write consistency）：寫入的數據完成後才能開始下一次的寫入。
5、寫不舊於讀一致性（Writes-follow-reads consistency）：寫入的副本不舊於上一次讀到的數據，即不會寫入更舊的數據。
Werner Vogels認爲：在很多互聯網應用中，單讀一致性＋讀不舊於寫一致性可以提供足夠的一致性了。
Werner Vogels基於NWR模型來分析一致性，該模型決定了亞馬遜雲計算技術架構的方向。
N－副本個數，W－每次同步寫入的副本個數，R－每次讀出副本個數。認爲只要W+R>N，就可以達到很強一致性。例如同步方式 N=2,W=2,R=1，則始終是一致的；而如果是異步方式，則每次同步寫入的W只有1，就不能保證一致性。如果W<N，則需要採取lazy的方式 後續將更新同步給其他N-W個副本。
要保證強一致性，那麼如果每次不能寫夠W份時，此次寫操作必須失敗，系統變得不可用。
