redis介紹分散式資料庫CAP原理

傳統的ACID分別是什麼

A (Atomicity) 原子性

C (Consistency) 一致性

I (Isolation) 獨立性

D (Durability) 永續性

關係型資料庫遵循ACID規則,事務在英文中是transaction,和現實世界中的交易很類似,它有如下四個特性:

1、A (Atomicity) 原子性

原子性很容易理解,也就是說事務裡的所有操作要麼全部做完,要麼都不做,事務成功的條件是事務裡的所有操作都成功,只要有一個操作失敗,整個事務就失敗,需要回滾。比如銀行轉賬,從A賬戶轉100元至B賬戶,分為兩個步驟:1)從A賬戶取100元;2)存入100元至B賬戶。這兩步要麼一起完成,要麼一起不完成,如果只完成第一步,第二步失敗,錢會莫名其妙少了100元。

2、C (Consistency) 一致性

一致性也比較容易理解,也就是說資料庫要一直處於一致的狀態,事務的執行不會改變資料庫原本的一致性約束。

3、I (Isolation) 獨立性

所謂的獨立性是指併發的事務之間不會互相影響,如果一個事務要訪問的資料正在被另外一個事務修改,只要另外一個事務未提交,它所訪問的資料就不受未提交事務的影響。比如現在有個交易是從A賬戶轉100元至B賬戶,在這個交易還未完成的情況下,如果此時B查詢自己的賬戶,是看不到新增加的100元的

4、D (Durability) 永續性

永續性是指一旦事務提交後,它所做的修改將會永久地儲存在資料庫上,即使出現宕機也不會丟失。

CAP

C:Consistency(強一致性)

A:Availability(可用性)

P:Partition tolerance(分割槽容錯性)或分散式容忍性

CAP理論就是說在分散式儲存系統中,最多隻能實現上面的兩點。

強一致性:比如資料上是什麼就是什麼。在分散式系統中的所有資料備份,在同一時刻是否同樣的值。(等同於所有節點訪問同一份最新的資料副本)

可用性:比如淘寶雙十一不可能用不了。在叢集中一部分節點故障後,叢集整體是否還能響應客戶端的讀寫請求。(對資料更新具備高可用性)

分割槽容錯性:以實際效果而言,分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性,就意味著發生了分割槽的情況,必須就當前操作在C和A之間做出選擇。

舉例子:比如淘寶的包包

對於強一致性,我們要求這個包包的點贊數是141,絕對不能錯。必須精確地指導,但是在高併發的時候很難保證資料的統一

對於高可用性:可以有弱一致性,比如允許點贊數,瀏覽數的錯誤,但不能導致網站癱瘓。

所以大部分網站架構都使用AP。弱一致性+高可用性

Nosql來說,分割槽容忍性是必須實現的,分散式系統可能不在同城,比如淘寶,內容分發是離你最近的。淘寶伺服器可能有伺服器放在杭州,有在上海和蘇州。

而由於當前的網路硬體肯定會出現延遲丟包等問題,所以分割槽容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡,沒有NoSQL系統能同時保證這三點。

CA 傳統Oracle資料庫

AP 大多數網站架構的選擇

CP Redis、Mongodb

注意:分散式架構的時候必須做出取捨。

一致性和可用性之間取一個平衡。對於大多數web應用,其實並不需要強一致性。因此犧牲C換取P,這是目前分散式資料庫產品的方向。

一致性與可用性的抉擇

對於web2。0網站來說,關係資料庫的很多主要特性卻往往無用武之地

資料庫事務一致性需求

很多web實時系統並不要求嚴格的資料庫事務,對讀一致性的要求很低, 有些場合對寫一致性要求並不高。允許實現最終一致性。

資料庫的寫實時性和讀實時性需求

對關係資料庫來說,插入一條資料之後立刻查詢,是肯定可以讀出來這條資料的,但是對於很多web應用來說,並不要求這麼高的實時性,比方說在微博發一條訊息之後,過幾秒乃至十幾秒之後,我的訂閱者才看到這條動態是完全可以接受的。

對複雜的SQL查詢,特別是多表關聯查詢的需求

任何大資料量的web系統,都非常忌諱多個大表的關聯查詢,以及複雜的資料分析型別的報表查詢,特別是SNS型別的網站,從需求以及產品設計角 度,就避免了這種情況的產生。往往更多的只是單表的主鍵查詢,以及單表的簡單條件分頁查詢,SQL的功能被極大地弱化了。

CAP理論的核心是:一個分散式系統不可能同時很好的滿足一致性,可用性和分割槽容錯性這三個需求,最多隻能同時較好的滿足兩個。

因此,根據 CAP 原理將 NoSQL 資料庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類:

CA - 單點叢集,滿足一致性,可用性的系統,通常在可擴充套件性上不太強大。

CP - 滿足一致性,分割槽容忍比的系統,通常效能不是特別高。

AP - 滿足可用性,分割槽容忍性的系統,通常可能對一致性要求低一些。

BASE

BASE就是為了解決關係資料庫強一致性引起的問題而引起的可用性降低而提出的解決方案。

BASE其實是下面三個術語的縮寫:

基本可用(Basically Available)

軟狀態(Soft state)

最終一致(Eventually consistent)

它的思想是透過讓系統放鬆對某一時刻資料一致性的要求來換取系統整體伸縮性和效能上改觀。為什麼這麼說呢,緣由就在於大型系統往往由於地域分佈和極高效能的要求,不可能採用分散式事務來完成這些指標,要想獲得這些指標,我們必須採用另外一種方式來完成,這裡BASE就是解決這個問題的辦法

分散式+叢集簡介

分散式系統(distributed system)

由多臺計算機和通訊的軟體元件透過計算機網路連線(本地網路或廣域網)組成。分散式系統是建立在網路之上的軟體系統。正是因為軟體的特性,所以分散式系統具有高度的內聚性和透明性。因此,網路和分散式系統之間的區別更多的在於高層軟體(特別是作業系統),而不是硬體。分散式系統可以應用在在不同的平臺上如:PC、工作站、區域網和廣域網上等。

簡單來講:

分散式:不同的多臺伺服器上面部署不同的服務模組(工程),他們之間透過RPC/RMI之間通訊和呼叫,對外提供服務和組內協作。

叢集:不同的多臺伺服器上面部署相同的服務模組,透過分散式排程軟體進行統一的排程,對外提供服務和訪問。