CAP定理

時間 2021-04-12

標籤 node web 數據庫編程服務器網絡架構併發負載均衡異步欄目 HTML 简体版

原文原文鏈接

CAP定理 node

1、CAP理論原理

一、CAP理論介紹

2000年7月，加州大學伯克利分校的Eric Brewer教授在ACM PODC會議上提出CAP猜測。2年後，麻省理工學院的Seth Gilbert和Nancy Lynch從理論上證實了CAP。以後，CAP理論正式成爲分佈式計算領域的公認定理。web

CAP理論:

一個分佈式系統最多隻能同時知足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。數據庫

二、CAP理論解釋

C:Consistency一致性

一致性指「all nodes see the same data at the same time」，即更新操做成功並返回客戶端完成後，全部節點在同一時間的數據徹底一致。編程

A: Availability可用性

可用性指「Reads and writes always succeed」，即服務一直可用，並且是正常響應時間。服務器

P: Partition tolerance分區容錯性

分區容錯性指「the system continues to operate despite arbitrary message loss or failure of part of the system」，即分佈式系統在遇到某節點或網絡分區故障的時候，仍然可以對外提供知足一致性和可用性的服務。網絡

2、CAP使用權衡

一、保留CA，放棄P

若是想避免分區容錯性問題的發生，一種作法是將全部的數據（與事務相關的）都放在一臺機器上。雖然沒法100%保證系統不會出錯，但不會碰到由分區帶來的負面效果。固然這個選擇會嚴重的影響系統的擴展性。架構

做爲一個分佈式系統，放棄P，即至關於放棄了分佈式，一旦併發性很高，單機服務根本不能承受壓力。併發

像不少銀行服務，確確實實就是捨棄了P，只用單臺小型機+ORACLE保證服務可用性。負載均衡

二、保留CP，放棄A

相對於放棄「分區容錯性「來講，其反面就是放棄可用性。一旦遇到分區容錯故障，那麼受到影響的服務須要等待必定的時間，所以在等待期間系統沒法對外提供服務。異步

做爲分佈式系統，有分區服務發生問題頗有可能，若是由於某些服務不能用，致使整個服務都不能用，這個根本不是好的分佈式系統。

三、保留AP，捨棄C

這裏所說的放棄一致性，並非徹底放棄數據一致性，而是放棄數據的強一致性。即放棄了同一時刻的數據一致性，而保留數據的最終一致性。

以網絡購物爲例，對只剩下一件庫存的商品，若是同時接受到了兩份訂單，那麼較晚的訂單將被告知商品告罄。

一般狀況下，不少分佈式服務系統都是採用該方案，保證可用性性，分佈式服務，由於某些分區服務發生問題，先容忍，最終經過一些折中的方法達到最終數據一致性。

CAP理論是分佈式數據庫中很重要的理論基礎。CAP即Consistnecy 一致性，Avaliability 可用性，Partition-tolerance分區容忍性的縮寫。在分佈式系統中，三者不可兼得，只能獲得其中之二。因此就有了三個分類：CA數據庫，CP數據庫，AP數據庫。

CA數據庫不考慮分區容忍性，對應現實中是數據庫就是普通的關係型數據庫RDBMS。

CP數據庫考慮的是一致性和分區容忍性，這種數據庫對分佈式系統內的通訊要求比較高，由於要保持數據的一致性，須要作大量的交互。

AP數據庫考慮的是實用性和分區容忍性，即外部訪問數據，能夠更快的獲得迴應。這時候，數據的一致性就可能得不到知足。好比一個數據，可能外部一個進程在改寫這個數據，同時另外一個進程在讀這個數據，此時，數據顯現是不一致的。可是有一點，就是數據庫會知足一個最終一致性的概念，即過程多是不一致的，可是到某一個終點，數據就會一致起來。

著名 CAP理論：在分佈式數據庫應用中，任何分佈式系統只可同時知足CAP其中兩點，沒法三者兼顧。

Consistency(一致性), 數據一致更新，全部數據變更都是同步的。

Availability(可用性), 好的響應性能。

Partition tolerance(分區容錯性) 可靠性。

CA 系統是要求高可用用而且實時一致性。單點數據庫是符合這種架構的，例如超市收銀系統，圖書管理系統。

AP 知足可用性，分區容忍性的系統，一般可能對一致性要求低一些。例如博客系統。

CP 系統是要求知足一致性，分區容忍性，一般性能不是特別高。例如火車售票系統。

忠告：架構師不要將精力浪費在如何設計能知足三者的完美分佈式系統，而是應該進行取捨。

三、最終一致性的系統是符合AP理論架構，對可用和分區容錯要求較高，對數據實時一致要求較低。網絡論壇或weibo的系統架構都符合最終一致性的應用。

四、數據庫中間件服務時是對分佈式數據庫的一個管理系統，其中負載均衡和擴展性相對來講是它的核心所在。

分佈式的優勢是大大的，最明顯的就是能夠同時處理不少事情，能夠同時響應不少請求。

分佈式的缺點也是大大的。

機器之間須要花費很多時間精力來溝通，這就是分佈式的缺點。

溝通到機器認識在一個水平，數據狀態一致,這叫同步。
溝通的時候有部分消息沒有正確傳給對方，這叫信號丟失。
溝通的時候，發現機器A和機器B思路徹底不同，出現網絡中斷分離，這就等同於倆數據中心。

1.ACID

ACID，是指在數據庫管理系統（DBMS）中，事務(transaction)所具備的四個特性：原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation，又稱獨立性)、持久性(Durability)。

在數據庫系統中，一個事務是指：由一系列數據庫操做組成的一個完整的邏輯過程。例如銀行轉賬，從原帳戶扣除金額，以及向目標帳戶添加金額，這兩個數據庫操做的總和，構成一個完整的邏輯過程，不可拆分。這個過程被稱爲一個事務，具備ACID特性。

1)原子性(Atomicity)

一個事務(transaction)中的全部操做，要麼所有完成，要麼所有不完成，不會結束在中間某個環節。事務在執行過程當中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務歷來沒有執行過同樣。

2)一致性(Consistency)

事務的一致性指的是在一個事務執行以前和執行以後數據庫都必須處於一致性狀態。若是事務成功地完成，那麼系統中全部變化將正確地應用，系統處於有效狀態。若是在事務中出現錯誤，那麼系統中的全部變化將自動地回滾，系統返回到原始狀態。

3)隔離性(Isolation)

指的是在併發環境中，當不一樣的事務同時操縱相同的數據時，每一個事務都有各自的完整數據空間。由併發事務所作的修改必須與任何其餘併發事務所作的修改隔離。事務查看數據更新時，數據所處的狀態要麼是另外一事務修改它以前的狀態，要麼是另外一事務修改它以後的狀態，事務不會查看到中間狀態的數據。

4)持久性(Durability)

指的是隻要事務成功結束，它對數據庫所作的更新就必須永久保存下來。即便發生系統崩潰，從新啓動數據庫系統後，數據庫還能恢復到事務成功結束時的狀態。

事務的（ACID）特性是由關係數據庫管理系統（RDBMS，數據庫系統）來實現的。數據庫管理系統採用日誌來保證事務的原子性、一致性和持久性。日誌記錄了事務對數據庫所作的更新，若是某個事務在執行過程當中發生錯誤，就能夠根據日誌，撤銷事務對數據庫已作的更新，使數據庫退回到執行事務前的初始狀態。

2.CAP

一致性(Consistency)、可用性(Availability)和分區容忍性(Partitiontolerance)。CAP原理指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。這是 Brewer 教授於 2000 年提出的，後人也論證了 CAP 理論的正確性。

1)一致性（Consistency）：( 一樣數據在分佈式系統中全部地方都是被複製成相同。)

對於分佈式的存儲系統，一個數據每每會存在多份。簡單的說，一致性會讓客戶對數據的修改操做（增/刪/改），要麼在全部的數據副本（replica）所有成功，要麼所有失敗。即，修改操做對於一份數據的全部副本（整個系統）而言，是原子（atomic）的操做。

若是一個存儲系統能夠保證一致性，那麼則客戶讀寫的數據徹底能夠保證是最新的。不會發生兩個不一樣的客戶端在不一樣的存儲節點中讀取到不一樣副本的狀況。

2) 可用性（Availability）：( 全部在分佈式系統活躍的節點都可以處理操做且能響應查詢。)

可用性很簡單，顧名思義，就是指在客戶端想要訪問數據的時候，能夠獲得響應。可是注意，系統可用（Available）並不表明存儲系統全部節點提供的數據是一致的。這種狀況，咱們仍然說系統是可用的。每每咱們會對不一樣的應用設定一個最長響應時間，超過這個響應時間的服務咱們仍然稱之爲不可用的。

3) 分區容忍性（Partition Tolerance）：( 分區容錯性: 在兩個複製系統之間，若是發生了計劃以外的網絡鏈接問題，對於這種狀況，有一套容錯性設計來保證。)

若是你的存儲系統只運行在一個節點上，要麼系統整個崩潰，要麼所有運行良好。一旦針對同一服務的存儲系統分佈到了多個節點後，整個存儲系統就存在分區的可能性。好比，兩個存儲節點之間聯通的網絡斷開（不管長時間或者短暫的），就造成了分區。通常來說，爲了提升服務質量，同一份數據放置在不一樣城市很是正常的。所以節點之間造成分區也很正常。

Gilbert 和Lynch將分區容忍性定義以下：除所有網絡節點所有故障之外，全部子節點集合的故障都不容許致使整個系統不正確響應。即便部分的組件不可用，施加的操做也能夠完成。

一個數據存儲系統不可能同時知足上述三個特性，只能同時知足其兩個特性，也就是： CA,CP,AP。能夠這麼說，當前全部的數據存儲解決方案，均可以歸類的上述三種類型。

CA 知足數據的一致性和高可用性，但沒有可擴展性，如傳統的關係型數據，基本上知足是這個解決方案，如ORACLE , MYSQL 的單節點，知足數據的一致性和高可用性。

CP 知足數據的一致性和分區性，如Oracle RAC ，Sybase 集羣。雖然Oracle RAC具有一點的擴展性，但當節點達到必定數目時，性能（也便可用性）就會降低很快，而且節點之間的網絡開銷還在，須要實時同步各節點之間的數據。

AP 在性能和可擴展性方面表現不錯，但在數據一致性方面會用犧牲，各節點的之間數據同步沒有哪麼快，但能保存數據的最終一致性。當前熱炒的NOSQL大多類是典型的AP類型數據庫。

綜合上述，架構師不要企圖設計一套同是知足CAP三方面的數據庫。只能在根據業務場景，對數據存儲要求有所折衷。

3.BASE

接受最終一致性的理論支撐是BASE模型，BASE全稱是BasicallyAvailable（基本可用）, Soft-state（軟狀態/柔性事務）, Eventually Consistent（最終一致性）。BASE模型在理論邏輯上是相反於ACID（原子性Atomicity、一致性Consistency、隔離性Isolation、持久性Durability）模型的概念，它犧牲高一致性，得到可用性和分區容忍性。

最終一致性：

最終一致性是指：通過一段時間之後，更新的數據會到達系統中的全部相關節點。這段時間就被稱之爲最終一致性的時間窗口

CAP和ACID一致性區別

ACID一致性是有關數據庫規則，若是數據表結構定義一個字段值是惟一的，那麼一致性系統將解決全部操做中致使這個字段值非惟一性的狀況，若是帶有一個外鍵的一行記錄被刪除，那麼其外鍵相關記錄也應該被刪除，這就是ACID一致性意思。

CAP理論的一致性是保證一樣一個數據在全部不一樣服務器上的拷貝都是相同的，這是一種邏輯保證，而不是物理，由於光速限制，在不一樣服務器上這種複製是須要時間的，集羣經過阻止客戶端查看不一樣節點上還未同步的數據維持邏輯視圖。

CAP原理指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。所以在進行分佈式架構設計時，必須作出取捨。而對於分佈式數據系統，分區容忍性是基本要求，不然就失去了價值。所以設計分佈式數據系統，就是在一致性和可用性之間取一個平衡。對於大多數web應用，其實並不須要強一致性，所以犧牲一致性而換取高可用性，是目前多數分佈式數據庫產品的方向。(通常狀況下CAP理論認爲你不能擁有上述三種中兩種，這是一個實踐總結：當有網絡分區狀況下，也就是分佈式系統中，你不能又要有完美一致性和100%的可用性，只能這二者選擇一個。在單機系統中，你則須要在一致性和延遲性latency之間權衡)

固然，犧牲一致性，並非徹底無論數據的一致性，不然數據是混亂的，那麼系統可用性再高分佈式再好也沒有了價值。犧牲一致性，只是再也不要求關係型數據庫中的強一致性，而是隻要系統能達到最終一致性便可，考慮到客戶體驗，這個最終一致的時間窗口，要儘量的對用戶透明，也就是須要保障「用戶感知到的一致性」。一般是經過數據的多份異步複製來實現系統的高可用和數據的最終一致性的，「用戶感知到的一致性」的時間窗口則取決於數據複製到一致狀態的時間。

最終一致性(eventually consistent)

對於一致性，能夠分爲從客戶端和服務端兩個不一樣的視角。從客戶端來看，一致性主要指的是多併發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。一致性是由於有併發讀寫纔有的問題，所以在理解一致性的問題時，必定要注意結合考慮併發讀寫的場景。

從客戶端角度，多進程併發訪問時，更新過的數據在不一樣進程如何獲取的不一樣策略，決定了不一樣的一致性。對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到，這是強一致性。若是能容忍後續的部分或者所有訪問不到，則是弱一致性。若是通過一段時間後要求能訪問到更新後的數據，則是最終一致性。

最終一致性根據更新數據後各進程訪問到數據的時間和方式的不一樣，又能夠區分爲：

因果一致性。若是進程A通知進程B它已更新了一個數據項，那麼進程B的後續訪問將返回更新後的值，且一次寫入將保證取代前一次寫入。與進程A無因果關係的進程C的訪問遵照通常的最終一致性規則。

「讀己之所寫（read-your-writes）」一致性。當進程A本身更新一個數據項以後，它老是訪問到更新過的值，毫不會看到舊值。這是因果一致性模型的一個特例。

會話（Session）一致性。這是上一個模型的實用版本，它把訪問存儲系統的進程放到會話的上下文中。只要會話還存在，系統就保證「讀己之所寫」一致性。若是因爲某些失敗情形令會話終止，就要創建新的會話，並且系統的保證不會延續到新的會話。

單調（Monotonic）讀一致性。若是進程已經看到過數據對象的某個值，那麼任何後續訪問都不會返回在那個值以前的值。

單調寫一致性。系統保證來自同一個進程的寫操做順序執行。要是系統不能保證這種程度的一致性，就很是難以編程了。

上述最終一致性的不一樣方式能夠進行組合，例如單調讀一致性和讀己之所寫一致性就能夠組合實現。而且從實踐的角度來看，這二者的組合，讀取本身更新的數據，和一旦讀取到最新的版本不會再讀取舊版本，對於此架構上的程序開發來講，會少不少額外的煩惱。

從服務端角度，如何儘快將更新後的數據分佈到整個系統，下降達到最終一致性的時間窗口，是提升系統的可用度和用戶體驗很是重要的方面。對於分佈式數據系統：

N — 數據複製的份數
W — 更新數據是須要保證寫完成的節點數
R — 讀取數據的時候須要讀取的節點數

若是W+R>N，寫的節點和讀的節點重疊，則是強一致性。例如對於典型的一主一備同步複製的關係型數據庫，N=2,W=2,R=1，則無論讀的是主庫仍是備庫的數據，都是一致的。

若是W+R<=N，則是弱一致性。例如對於一主一備異步複製的關係型數據庫，N=2,W=1,R=1，則若是讀的是備庫，就可能沒法讀取主庫已經更新過的數據，因此是弱一致性。

對於分佈式系統，爲了保證高可用性，通常設置N>=3。不一樣的N,W,R組合，是在可用性和一致性之間取一個平衡，以適應不一樣的應用場景。

若是N=W,R=1，任何一個寫節點失效，都會致使寫失敗，所以可用性會下降，可是因爲數據分佈的N個節點是同步寫入的，所以能夠保證強一致性。
若是N=R,W=1，只須要一個節點寫入成功便可，寫性能和可用性都比較高。可是讀取其餘節點的進程可能不能獲取更新後的數據，所以是弱一致性。這種狀況下，若是W<(N+1)/2，而且寫入的節點不重疊的話，則會存在寫衝突