- 傳統的ACID分別是什麼： 原子性 一致性 獨立性 持久性
關係型數據庫遵循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理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。
而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以
分區容忍性是我們必須需要實現的。
所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
=======================================================================================================================
C:強一致性 A：高可用性 P：分佈式容忍性
CA 傳統Oracle數據庫
AP 大多數網站架構的選擇
CP Redis、Mongodb
注意：分佈式架構的時候必須做出取捨。
一致性和可用性之間取一個平衡。多餘大多數web應用，其實並不需要強一致性。
因此犧牲C換取P，這是目前分佈式數據庫產品的方向
=======================================================================================================================
一致性與可用性的決擇
對於web2.0網站來說，關係數據庫的很多主要特性卻往往無用武之地
數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低， 有些場合對寫一致性要求並不高。允許實現最終一致性。
數據庫的寫實時性和讀實時性需求
對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者纔看到這條動態是完全可以接受的。
對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。