NoSql(四) 在分佈式數據庫中CAP原理 CAP + BASE

1: 傳統的ACID是什麼? 

    A (Atomictiy[,ætə'mɪsɪti]) 原子性

    C (Consistency[kən'sɪstənsi])一致性

    I  (Isolation) 獨立性

    D (Durability) 持久性

2:  CAP

    C: Consistency 強一致性  例如:數據稍微不對一點, 例如點贊數10萬和10萬1千的區別

    A: Availabity 可用性  例如:網站不能掛

    P: Partition tolerance 分區容錯性  例如: 機房的數據要相同

3: CAP的三進二

    一個分佈式系統不可能同事很好的滿足 一致性, 可用性和分區容錯性三個需求, 最多隻能同時較好的滿足兩個.

   CA - 單點集羣, 滿足一致性, 可用性系統, 通常擴展性不是很強大

  CP - 滿足一致性, 分區容錯性 系統, 通常性能不好

  AP - 滿足可用, 分區容錯性的系統, 通常對一致性的要求略低

分區容錯性(P: Partition tolerance)是我們必須實現的!!

AP, 大多數網站架構的選擇, 因爲高可用非常重要!

CP,  Redis

一致性和高可用的抉擇!

數據庫事務一致性需求:    很多web實時系統並不要求嚴格的數據庫事務, 對讀一致性要求很低, 有些場合對寫一致性很低,允許實現最終一致性.

    數據庫的寫實時性和讀實時性需求:

            對於關係型數據庫來首說, 插入一條數據庫立刻查詢,是肯定可以讀出來這條數據的, 但是對於很多web應用來說,並不需要這麼高的實時性, 例如對方發一條信息之後, 過幾秒乃至十幾秒後, 我的訂閱者纔看到這條動態是完全可以接受的

4 BASE

BASE 其實是下面三個術語的縮寫,他是爲了解決關係型數據庫一致性的問題引起的可用性降低的解決方案

     基本可用 Basically Available 

     軟狀態 soft state

     最終一致 Eventually consistent

    它的思想是讓系統放鬆對某一時刻數據一致性的需求來換取系統整體伸縮性和性能上的改觀, 爲什麼這麼說呢, 原有就在於:

大型系統往往由於地域分佈和極高性能的要求, 不可能採用分佈式事務來完成這些指標, 要想獲得這些指標, 我們必須採用另一種方式來完成, 這裏BASE就是解決這個問題的方法

5 分佈式 + 集羣簡介

簡單來說: 分佈式, 不同的服務器部署不同的服務模塊, 他們之間通過rpc通信調用

               集羣, 不同服務器部署相同服務模塊