CAP、BASE理論

一、CAP理論來源

這個定理起源于加州大學柏克萊分校（University of California, Berkeley）的計算機科學家埃裡克·布魯爾在2000年的分布式計算原理研讨會（PODC）上提出的一個猜想。在2002年，麻省理工學院（MIT）的賽斯·吉爾伯特和南希·林奇發表了布魯爾猜想的證明，使之成為一個定理。

吉爾伯特和林奇證明的CAP定理比布魯爾設想的某種程度上更加狹義。定理讨論了在兩個互相沖突的請求到達彼此連接配接不通的兩個不同的分布式節點的時候的處理方案。

二、CAP理論概念

在理論計算機科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer's theorem），它指出對于一個分布式計算系統來說不可能同時滿足以下三點：

• 一緻性（Consistency） 在分布式系統中的所有資料備份，在同一時刻是否是同樣的值。（等同于所有節點通路同一份最新的資料副本）

• 可用性（Availability） 在叢集中一部分節點故障後，叢集整體是否還能響應用戶端的讀寫請求。（每次請求都能擷取到非錯的響應——但是不保證擷取的資料為最新資料）
• 分區容錯性（Partition tolerance）（以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限内達成資料一緻性，就意味着發生了分區的情況，必須就目前操作在C和A之間做出選擇）

根據定理，分布式系統隻能滿足三項中的兩項而不可能滿足全部三項。了解CAP理論的最簡單方式是想象兩個節點分處分區兩側。允許至少一個節點更新狀态會導緻資料不一緻，即喪失了C性質。如果為了保證資料一緻性，将分區一側的節點設定為不可用，那麼又喪失了A性質。除非兩個節點可以互相通信，才能既保證C又保證A，這又會導緻喪失P性質。

CAP原則的精髓就是要麼AP，要麼CP，要麼AC，但是不存在CAP。如果在某個分布式系統中資料無副本， 那麼系統必然滿足強一緻性條件， 因為隻有獨一資料，不會出現資料不一緻的情況，此時C和P兩要素具備，但是如果系統發生了網絡分區狀況或者當機，必然導緻某些資料不可以通路，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足。

是以在進行分布式架構設計時，必須做出取舍。目前一般是通過分布式緩存中各節點的最終一緻性來提高系統的性能，通過使用多節點之間的資料異步複制技術來實作叢集化的資料一緻性。通常使用類似memcached之類的NOSQL作為實作手段。雖然memcached也可以是分布式叢集環境的，但是對于一份資料來說，它總是存儲在某一台memcached伺服器上。如果發生網絡故障或是伺服器當機，則存儲在這台伺服器上的所有資料都将不可通路。由于資料是存儲在記憶體中的，重新開機伺服器，将導緻資料全部丢失。當然也可以自己實作一套機制，用來在分布式memcached之間進行資料的同步和持久化，但是實作難度是非常大的。

三、可用的抉擇

CAP理論就是說在分布式存儲系統中，最多隻能實作上面的兩點。而由于網絡硬體肯定會出現延遲丢包等問題，是以分區容錯性是我們必須需要實作的。是以我們隻能在一緻性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。對于web2.0網站來說，關系資料庫的很多主要特性卻往往無用武之地。

1、資料庫事務一緻性需求

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

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

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

3、對複雜的SQL查詢，特别是多表關聯查詢的需求

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

四、與NoSQL的關系

傳統的關系型資料庫在功能支援上通常很寬泛，從簡單的鍵值查詢，到複雜的多表聯合查詢再到事務機制的支援。而與之不同的是，NoSQL系統通常注重性能和擴充性，而非事務機制（事務就是強一緻性的展現）。

傳統的SQL資料庫的事務通常都是支援ACID的強事務機制。A代表原子性，即在事務中執行多個操作是原子性的，要麼事務中的操作全部執行，要麼一個都不執行；C代表一緻性，即保證進行事務的過程中整個資料庫的狀态是一緻的，不會出現資料花掉的情況；I代表隔離性，即兩個事務不會互相影響，覆寫彼此資料等；D表示持久化，即事務一旦完成，那麼資料應該是被寫到安全的，持久化存儲的裝置上（比如磁盤）。

NoSQL系統僅提供對行級别的原子性保證，也就是說同時對同一個Key下的資料進行的兩個操作，在實際執行的時候是會串行的執行，保證了每一個Key-Value對不會被破壞。

五、與BASE的關系

BASE是Basically Available（基本可用）、Soft state（軟狀态）和Eventually consistent（最終一緻性）三個短語的簡寫。

BASE是對CAP中一緻性和可用性權衡的結果，其來源于對大規模網際網路系統分布式實踐的結論，是基于CAP定理逐漸演化而來的，其核心思想是即使無法做到強一緻性（Strong consistency），但每個應用都可以根據自身的業務特點，采用适當的方式來使系統達到最終一緻性（Eventual consistency）。接下來我們着重對BASE中的三要素進行詳細講解。

基本可用：指分布式系統在出現不可預知故障的時候，允許損失部分可用性。注意，這絕不等價于系統不可用，以下兩個就是“基本可用”的典型例子：

（1）響應時間上的損失：正常情況下，一個線上搜尋引擎需要0.5秒内傳回給使用者相應的查詢結果，但由于出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1~2秒。

（2）功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峰的時候，由于消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。