redis總結(一)--cap原理和base
1cap原理
1.1來自http://www.ruanyifeng.com/blog/2018/07/cap.html的解釋
1.1.1先看 Partition tolerance，中文叫做"分割槽容錯"。
大多數分散式系統都分佈在多個子網路。每個子網路就叫做一個區（partition）。分割槽容錯的意思是，區間通訊可能失敗。比如，一臺伺服器放在中國，另一臺伺服器放在美國，這就是兩個區，它們之間可能無法通訊。
上圖中，G1 和 G2 是兩臺跨區的伺服器。G1 向 G2 傳送一條訊息，G2 可能無法收到。系統設計的時候，必須考慮到這種情況。
一般來說，分割槽容錯無法避免，因此可以認為 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到。
來自百度解釋：分割槽容錯性（P）：以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇（具體網址https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99/5712863?fr=aladdin）
1.1.2Consistency
Consistency 中文叫做"一致性"。意思是，寫操作之後的讀操作，必須返回該值。舉例來說，某條記錄是 v0，使用者向 G1 發起一個寫操作，將其改為 v1。
接下來，使用者的讀操作就會得到 v1。這就叫一致性。
問題是，使用者有可能向 G2 發起讀操作，由於 G2 的值沒有發生變化，因此返回的是 v0。G1 和 G2 讀操作的結果不一致，這就不滿足一致性了
為了讓 G2 也能變為 v1，就要在 G1 寫操作的時候，讓 G1 向 G2 傳送一條訊息，要求 G2 也改成 v1。
這樣的話，使用者向 G2 發起讀操作，也能得到 v1。
來自百度解釋：一致性（C）：在分散式系統中的所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本）（具體網址https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99/5712863?fr=aladdin）
1.1.3可用性
Availability 中文叫做"可用性"，意思是隻要收到使用者的請求，伺服器就必須給出迴應。
使用者可以選擇向 G1 或 G2 發起讀操作。不管是哪臺伺服器，只要收到請求，就必須告訴使用者，到底是 v0 還是 v1，否則就不滿足可用性。
來自百度解釋：可用性（A）：在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性）（具體網址https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99/5712863?fr=aladdin）
1.1.4Consistency 和 Availability 的矛盾
一致性和可用性，為什麼不可能同時成立？答案很簡單，因為可能通訊失敗（即出現分割槽容錯）。
如果保證 G2 的一致性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有資料同步後，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性不。
如果保證 G2 的可用性，那麼勢必不能鎖定 G2，所以一致性不成立。
綜上所述，G2 無法同時做到一致性和可用性。系統設計時只能選擇一個目標。如果追求一致性，那麼無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性。
2BASE
BASE就是為了解決關係資料庫強一致性引起的問題而引起的可用性降低而提出的解決方案。
BASE是下面三個術語的縮寫：
-
基本可用（Basically Available）
-
軟狀態（Soft state）
-
最終一致（Eventually consistent）
-
目前最快的KV資料庫,10W次/S, 滿足了高可用性。
-
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時間。
-
Redis的v的最大遠遠超過memcache。這也是實現訊息佇列的一個前提