nosql&數據庫CAP
1.nosql：非關係型數據庫
1.1分類
- 鍵值存儲數據庫：特定的鍵指向特定的數據，如redis、Voldemor、Oracle BDB。
- 列存儲數據庫：一個鍵指向多個列，用來應對分佈式存儲的海量數據，HBase、Riak。
- 文檔型數據庫：MongoDB、CouchDB
- 圖形數據庫：比如用來存儲人際關係網絡，Neo4J、InfoCrid、Infinite Graph
2.CAP
2.1 CAP是什麼
C(Consistency強一致性):系統在執行過某項操作後仍然處於一致的狀態。直接的說就是更新操作執行成功後所有的用戶都應該讀到最新的值。用戶A改了某個數據的值，用戶B去讀數據，必須要讀到A修改後的值。
A(Availability可用性)：每一個操作總是能夠在一定的時間內返回結果。簡單的說就是，用戶訪問數據庫必須有迴應，數據庫不能卡死或崩掉。
P(Partition tolerance分區容錯性)：指當出現網絡分區的情況時（即系統中的一部分節點無法和其他節點進行通信）分離的系統也能夠正常運行。簡單的說，數據庫中的服務器節點需要相互通信，保證彼此的數據都是一致的。當某一個節點和其他的節點斷開了，他依然要能夠運行（這時它本地保存的數據也許就和其他的節點慢慢的不一樣了）
2.2 CAP理論
一個分佈式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個要求，最多隻能同時較好的滿足其中的兩個。
爲什麼不能同時滿足3個呢？因爲在邏輯上就會矛盾。
比如：
某一個數據庫節點s1，由於網絡分片導致s1和其他節點之間所有的通訊都斷開了，用戶A去更新數據庫中的數據X，然後用戶B去從s1中讀取數據X的值（按照P的要求，s1需要可以繼續運行），這時候讀到的數據X就不會是最新的了，就無法滿足C的要求。
此時，可以選擇：
- 放棄C：不要強一致性，數據就不要最新的。
- 放棄A：數據庫暫時不給返回數據X的值，等到s1恢復了通信，數據X一致了以後再應答。
- 放棄P：不要搞分區，就搞一臺機器。
三類：
CAP
- CA-單點集羣，滿足一致性，可用性的系統，通常在可擴展性上不太強。傳統Oracle、mysql數據庫。
- CP-滿足一致性，分區容錯的系統，通常可用性不是特別高。redis、mongodb
- AP-滿足可用性，分區容錯性的系統，通常可能對一致性要求低。Tokyo Cabinet、SimpleDB、couchDB、Riak。
3. ACID&BASE
3.1 傳統SQL的ACID：
傳統的SQL數據庫的事務通常都是支持ACID的強事務機制:
- A代表原子性，即在事務中執行多個操作是原子性的，要麼事務中的操作全部執行，要麼一個都不執行;
- C代表一致性，即保證進行事務的過程中整個數據加的狀態是一致的，不會出現數據花掉的情況;
- I代表隔離性，即兩個事務不會相互影響，覆蓋彼此數據等;
- D表示持久化，即事務一但完成，那麼數據應該是被寫到安全的，持久化存儲的設備上（比如磁盤）
3.2 nosql中的BASE：
BASE其實就是下面三個術語的縮寫：
- 基本可用（Basically Available）
- 軟性事務（Soft state）
- 最終一致（Eventually consistent）
番外：分佈式&集羣
分佈式：不同的多臺服務器上面部署不同的服務模塊（工程），他們之間通過RPC/RMI之間通信和調用，對外提供服務和組內協作。
集羣：不同的多臺服務器上面部署相同的模塊，通過分佈式調度軟件進行統一的調度，對外提供服務和訪問。