推薦（免費）：redis
傳統的ACID分別是什麼
A (Atomicity) 原子性
C (Consistency) 一致性
I (Isolation) 獨立性
D (Durability) 持久性
關係型資料庫遵循ACID規則，事務在英文中是transaction，和現實世界中的交易很類似，它有以下四個特性：
1、A (Atomicity) 原子性
原子性很容易理解，也就是說事務裡的所有操作要麼全部做完，要麼都不做，事務成功的條件是事務裡的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。例如銀行轉賬，從A帳戶轉100元至B帳戶，分成兩個步驟：1）從A帳戶取100元；2）存入100元至B帳戶。這兩步驟不是一起完成，就是一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。
2、C (Consistency) 一致性
一致性也比較容易理解，也就是說資料庫要一直處於一致的狀態， 交易的運作不會改變資料庫原本的一致性限制。
3、I (Isolation) 獨立性
所謂的獨立性是指並發的事務之間不會互相影響，如果一個事務要存取的資料正在被另一個事務修改，只要另外一個事務未提交，它所存取的資料就不受未提交事務的影響。例如現有有個交易是從A帳戶轉100元至B帳戶，在這個交易還未完成的情況下，如果此時B查詢自己的帳戶，是看不到新增加的100元的
4、D (Durability) 持久性
持久性是指一旦交易提交後，它所做的修改將會永久的保存在資料庫上 ，即使出現宕機也不會遺失。
CAP
C:Consistency（強一致性）
A:Availability（可用性）
P:Partition tolerance（分區容錯性）或分散式容忍性
CAP理論就是說在分散式儲存系統中，最多只能實現上面的兩點。
強一致性：例如資料上是什麼就是什麼。 在分散式系統中的所有資料備份，在同一時刻是否相同的值。 （等同於所有節點存取同一份最新的資料副本）
可用性：例如淘寶雙十一不可能用不了。 在叢集中一部分節點故障後，叢集整體是否還能回應客戶端的讀寫請求。 （對資料更新具備高可用性）
分區容錯性：以實際效果而言，分區相當於對通訊的時限要求。 系統如果無法在時限內達成資料一致性，就表示發生了分割區的情況，必須就目前操作在C和A之間做出選擇。
舉例子：例如淘寶的包包
對於強一致性，我們要求這個包包的按讚數是141，絕對不能錯。必須精確的指導，但是在高並發的時候很難保證資料的統一
對於高可用性：可以有弱一致性，例如允許按讚數，瀏覽數的錯誤，但不能導致網站癱瘓。
所以大部分網站架構都使用AP。弱一致性 高可用性
Nosql來說，分區容忍性是必須實現的，分散式系統可能不在同城，例如淘寶，內容分發是離你最近的。淘寶服務器可能有伺服器放在杭州，有在上海和蘇州。
而由於目前的網路硬體肯定會出現延遲丟包等問題，所以分割區容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
CA 傳統Oracle資料庫
AP 大多數網站架構的選擇
CP Redis、Mongodb
注意：分散式架構的時候必須做出取捨。
一致性和可用性之間取一個平衡。多餘大多數web應用，其實不需要強一致性。因此犧牲C換取P，這是目前分散式資料庫產品的方向。
一致性與可用性的決擇
對於web2.0網站來說，關係資料庫的許多主要特性卻往往無用武之地
資料庫事務一致性需求
很多web實時系統並不要求嚴格的資料庫事務，對讀取一致性的要求很低， 有些場合對寫一致性要求並不高。允許實現最終一致性。
資料庫的寫即時性和讀實時性需求
對關係資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料的，但是對於很多web應用來說，並不要求這麼高的即時性，比方說在微博發一條訊息之後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動態是完全可以接受的。
對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
經典CAP圖
CAP理論的核心是：一個分散式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，最多只能同時較好的滿足兩個。
因此，根據CAP 原理將NoSQL 資料庫分成了滿足CA 原則、滿足CP 原則和滿足AP 原則三大類：
CA - 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。
CP - 滿足一致性，分割區容忍必的系統，通常效能不是特別高。
AP - 滿足可用性，分割容忍性的系統，通常可能對一致性要求低一些。
BASE
BASE就是為了解決關聯式資料庫強一致性所造成的問題而造成的可用性降低而提出的解決方案。
BASE其實是下面三個術語的縮寫：
基本上可用（Basically Available）
軟狀態（Soft state）
最終一致（Eventually consistent）## 它的想法是透過讓系統放鬆對某一時刻資料一致性的要求來換取系統整體伸縮性和效能上改觀。為什麼這麼說呢，緣由就在於大型系統往往由於地域分佈和極高性能的要求，不可能採用分佈式事務來完成這些指標，要想獲得這些指標，我們必須採用另一種方式來完成，這裡BASE就是解決這個問題的方法
分散式叢集簡介
分散式系統（distributed system）
由多台電腦和通訊的軟體元件透過電腦網絡連線（本地網路或廣域網路）組成。分散式系統是建立在網路之上的軟體系統。正是因為軟體的特性，所以分散式系統具有高度的內聚性和透明性。因此，網路和分散式系統之間的差異更多的在於高層軟體（特別是作業系統），而不是硬體。分散式系統可以應用在不同的平台上如：PC、工作站、區域網路和廣域網路上等。
簡單來講：
分散式：不同的多台伺服器上面部署不同的服務模組（工程），他們之間透過RPC/RMI之間通訊和調用，對外提供服務和群組內協作。 叢集：不同的多台伺服器上面部署相同的服務模組，透過分散式調度軟體進行統一的調度，對外提供服務和存取。
以上是redis講解分散式資料庫CAP原理的詳細內容。更多資訊請關注PHP中文網其他相關文章！
