推薦（免費）：redis

傳統(tǒng)的ACID分別是什么

A (Atomicity) 原子性
C (Consistency) 一致性
I (Isolation) 獨立性
D (Durability) 持久性
關系型數(shù)據(jù)庫遵循ACID規(guī)則，事務在英文中是transaction，和現(xiàn)實世界中的交易很類似，它有如下四個特性：

1、A (Atomicity) 原子性

??原子性很容易理解，也就是說事務里的所有操作要么全部做完，要么都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。比如銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。

2、C (Consistency) 一致性

??一致性也比較容易理解，也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài)，事務的運行不會改變數(shù)據(jù)庫原本的一致性約束。

3、I (Isolation) 獨立性

??所謂的獨立性是指并發(fā)的事務之間不會互相影響，如果一個事務要訪問的數(shù)據(jù)正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數(shù)據(jù)就不受未提交事務的影響。比如現(xiàn)有有個交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的

4、D (Durability) 持久性

持久性是指一旦事務提交后，它所做的修改將會永久的保存在數(shù)據(jù)庫上，即使出現(xiàn)宕機也不會丟失。

CAP

C:Consistency（強一致性）
A:Availability（可用性）
P:Partition tolerance（分區(qū)容錯性）或分布式容忍性
CAP理論就是說在分布式存儲系統(tǒng)中，最多只能實現(xiàn)上面的兩點。
強一致性：比如數(shù)據(jù)上是什么就是什么。在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。（等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本）
可用性：比如淘寶雙十一不可能用不了。在集群中一部分節(jié)點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）
分區(qū)容錯性：以實際效果而言，分區(qū)相當于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當前操作在C和A之間做出選擇。
舉例子：比如淘寶的包包
對于強一致性，我們要求這個包包的點贊數(shù)是141，絕對不能錯。必須精確的指導，但是在高并發(fā)的時候很難保證數(shù)據(jù)的統(tǒng)一
對于高可用性：可以有弱一致性，比如允許點贊數(shù)，瀏覽數(shù)的錯誤，但不能導致網(wǎng)站癱瘓。
所以大部分網(wǎng)站架構都使用AP。弱一致性+高可用性

Nosql來說，分區(qū)容忍性是必須實現(xiàn)的，分布式系統(tǒng)可能不在同城，比如淘寶，內(nèi)容分發(fā)是離你最近的。淘寶服務器可能有服務器放在杭州，有在上海和蘇州。
而由于當前的網(wǎng)絡硬件肯定會出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實現(xiàn)的。所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統(tǒng)能同時保證這三點。

CA 傳統(tǒng)Oracle數(shù)據(jù)庫
AP 大多數(shù)網(wǎng)站架構的選擇
CP Redis、Mongodb
注意：分布式架構的時候必須做出取舍。

一致性和可用性之間取一個平衡。多余大多數(shù)web應用，其實并不需要強一致性。因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向。

一致性與可用性的決擇
??對于web2.0網(wǎng)站來說，關系數(shù)據(jù)庫的很多主要特性卻往往無用武之地
數(shù)據(jù)庫事務一致性需求
??很多web實時系統(tǒng)并不要求嚴格的數(shù)據(jù)庫事務，對讀一致性的要求很低， 有些場合對寫一致性要求并不高。允許實現(xiàn)最終一致性。
數(shù)據(jù)庫的寫實時性和讀實時性需求
??對關系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的，但是對于很多web應用來說，并不要求這么高的實時性，比方說在微博發(fā)一條消息之后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態(tài)是完全可以接受的。
對復雜的SQL查詢，特別是多表關聯(lián)查詢的需求
??任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設計角 度，就避免了這種情況的產(chǎn)生。往往