分佈式系統的CAP理論：
理論首先把分佈式系統中的三個特性進行了以下概括：
● 一致性（C）：在分佈式系統中的全部數據備份，在同一時刻是否一樣的值。
● 可用性（A）：在集羣中一部分節點故障後，集羣總體是否還能響應客戶端的讀寫請求。（可用性不只包括讀，還有寫）
● 分區容忍性（P）：集羣中的某些節點在沒法聯繫後，集羣總體是否還能繼續進行服務。
一致性與可用性的決擇：
而CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。而因爲當前的網絡硬件確定
會出現延遲丟包等問題，因此分區容忍性是咱們必須須要實現的。因此咱們只能在一致性和可用
性之間進行權衡，沒有NoSQL系統能同時保證這三點。web
對於web2.0網站來講，關係數據庫的不少主要特性卻每每無用武之地
1.數據庫事務一致性需求
不少web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。容許實現最終一致性。
二、數據庫的寫實時性和讀實時性需求
對關係數據庫來講，插入一條數據以後馬上查詢，是確定能夠讀出來這條數據的，可是對於
不少web應用來講，並不要求這麼高的實時性，比方說發一條消息之
後，過幾秒乃至十幾秒以後，個人訂閱者纔看到這條動態是徹底能夠接受的。
三、對複雜的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中，一般有兩個層次的一致性：第 一種是強一致性，既集羣中的全部機器狀態同步保持一致。第二種是最終一致性，既能夠允
許短 暫的數據不一致，但數據最終會保持一致。咱們先來說一下，在分佈式集羣中，爲何最終一致 性一般是更合理的選擇
redis