分散式系統的CAP理論：
理論首先把分散式系統中的三個特性進行了如下歸納：
● 一致性（C）：在分散式系統中的所有資料備份，在同一時刻是否同樣的值。
● 可用性（A）：在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（可用性不僅包括讀，還有寫）
● 分割槽容忍性（P）：叢集中的某些節點在無法聯絡後，叢集整體是否還能繼續進行服務。

一致性與可用性的決擇：
而CAP理論就是說在分散式儲存系統中，最多隻能實現上面的兩點。而由於當前的網路硬體肯定
會出現延遲丟包等問題，所以分割槽容忍性是我們必須需要實現的。所以我們只能在一致性和可用
性之間進行權衡，沒有NoSQL系統能同時保證這三點。

 

 

 

對於web2.0網站來說，關聯式資料庫的很多主要特性卻往往無用武之地 
1.資料庫事務一致性需求 
很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。允許實現最終一致性。
2、資料庫的寫實時性和讀實時性需求 
對關聯式資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料的，但是對於
很多web應用來說，並不要求這麼高的實時性，比方說發一條訊息之 
後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動態是完全可以接受的。
3、對複雜的SQL查詢，特別是多表關聯查詢的需求 
任何大資料量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的資料分析型別的復?
覵QL報表查詢，特別是SNS型別的網站，從需求以及產品設計角 
度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁
查詢，SQL的功能被極大的弱化了。

高可用性就是高效能。 BASE提供了基本可用性。BASE是鹼，ACID是酸。

總結：
傳統的關係型資料庫在功能支援上通常很寬泛，從簡單的鍵值查詢，到複雜的多表聯合查詢再到
事務機制的支援。而與之不同的是，NoSQL系統通常注重效能和擴充套件性，而非事務機制（事務就是強一致性的體現。）。

傳統的SQL資料庫的事務通常都是支援ACID的強事務機制。A代表原子性，即在事務中執行多個
操作是原子性的，要麼事務中的操作全部執行，要麼一個都不執行;C代表一致性，即保證進行事
務的過程中整個資料加的狀態是一致的，不會出現資料花掉的情況;I代表隔離性，即兩個事務不
會相互影響，覆蓋彼此資料等;D表示持久化，即事務一量完成，那麼資料應該是被寫到安全的，
持久化儲存的裝置上（比如磁碟）。

NoSQL系統僅提供對行級別的原子性保證，也就是說同時對同一個Key下的資料進行的兩個操作，在實際執行的時候是會串
行的執行，保證了每一個Key-Value對不會被破壞。

Redis:BASE就是為了解決關聯式資料庫強一致性引起的問題而引起的可用性降低而提出的解決方案。
1.目前最快的KV資料庫,10W次/S, 滿足了高可用性。
2.Redis的k-v上的v可以是普通的值（基本操作：get/set/del） v可以是數值（除了基本操作之外還可以支援數值的計算） v可以是資料結構比如基於連結串列儲存的雙向迴圈list（除了基本操作之外還可以支援數值的計算，可以實現list的二頭pop,push）。
如果v是list，可以使用redis實現一個訊息佇列。如果v是set,可以基於redis實現一個tag系統。與mongodb不同的地方是後者的v可以支援文件，比如按照json的結構儲存。redis也可以對存入的Key-Value設定expire時間。
3.Redis的v的最大遠遠超過memcache。這也是實現訊息佇列的一個前提。

在NoSQL中，通常有兩個層次的一致性：第 一種是強一致性，既叢集中的所有機器狀態同步保持一致。第二種是最終一致性，既可以允
許短 暫的資料不一致，但資料最終會保持一致。我們先來講一下，在分散式叢集中，為什麼最終一致 性通常是更合理的選擇