- CAP的前世今生 -
1.1 起源
CAP理論，被戲稱為“帽子理論”，CAP是Eric Brewer在2000年ACM研讨會上出了一個想法：“一緻性、可用性和分區容錯性三者無法在分布式系統中被同時滿足，并且最多隻能滿足其中兩個！”
2002年，Seth Gilbert和Nancy Lynch采用反正法證明了猜想：“如果三者可同時滿足，則因為允許P的存在，一定存在Server之間的丢包，如此則不能保證C。” 在該證明中，對CAP的定義進行了更明确的聲明。
C：一緻性被稱為原子對象，任何的讀寫都應該看起來是“原子”，或串行的。寫後面的讀一定能讀到前面寫的内容，所有的讀寫請求都好像被全局排序。
A：對任何非失敗節點都應該在有限時間内給出請求的回應。（請求的可終止性）
P：允許節點之間丢失任意多的消息，當網絡分區發生時，節點之間的消息可能會完全丢失。
但是隻證明了CAP三者不可能同時滿足，并沒有證明任意二者都可滿足的問題；是以該證明被認為是一個收窄的結果，在之後10年裡受到各種質疑。
1.2 重新诠釋
2012年，Brewer和Lynch針對所有的質疑進行了回應，重新诠釋CAP。“3個中的2個”表述是不準确的，在某些分區極少發生的情況下，三者也能順暢地配合。CAP不僅僅是發生在整個系統中，可能是發生在某個子系統或系統的某個階段。把CAP理論的證明局限在原子讀寫的場景，并申明不支援資料庫事務之類的場景。一緻性場景不會引入使用者agent，隻是發生在背景叢集之内。把分區容錯歸結為一個對網絡環境的陳述，而非之前一個獨立條件。引入了活(liveness)和安全屬性(safety)，在一個更抽象的概念下研究分布式系統，并認為CAP是活性與安全屬性之間權衡的一個特例。其中的一緻性屬于liveness，可用性屬safety。
網絡存在同步、部分同步；一緻性性的結果也從僅存在一個到存在N個（部分一緻）；引入了通信周期round，保證N個一緻性結果。
總結：縮小CAP适用的定義，消除質疑的場景；展示了CAP在非單一一緻性結果下的廣闊的研究結果。 - CAP的分析 -
2.1 組成
Consistency：一緻性
Availability：可用性
Partition tolerance：分區容忍性
2.2 Consistency
從論文上看：操作之後的讀操作，必須傳回該值。
從百科上看：在分布式系統中的所有資料備份，在同一時刻是否同樣的值。
總結：在分布式系統中，C代表任何人在任何地點、任何時間，通路任何資料 結果都是一緻的。
2.3 Availability
從論文上看：隻要收到使用者的請求，伺服器就必須給出回應。
從百科上看：在叢集中一部分節點故障後，叢集整體是否還能響應用戶端的讀寫請求。
總結：在分布式系統中，A代表服務在任何時候都要是可用的、可通路。
2.4 Partition tolerance
從論文上看：直譯叫“分區容錯”，意思是區間通信可能失敗。
從百科上看：分區相當于對通信的時限要求。
總結：分區容錯=分區+容錯。分布式系統因為多執行個體部署，面臨多個子網絡，多個子網絡存在網絡通訊的需求；因為網絡通訊的不可靠性造成分區的存在。而分區的存在，不可避免出現資料和可用性問題，需要有容錯機制來處理。 - 實踐分析 -
3.1 A與P的差異
從上述的描述中，因為兩者都有容錯可用的描述，我們很容易将A 跟 P 混淆在一起。接下去，咱們從各個次元去分析C 與P的差異。
從關注點來說，A關注的是使用者對分布式系統的可用要求；P關注的是分布式系統執行個體間的網絡連通性。
從要求上來看，A從外部的視角，要求分布式系統在正常響應時間内一直可用；P從執行個體節點的視角出發，在遇到某節點或節點間通信故障的時候，要求分布式系統整體對節點的容錯及恢複性。
從閱聽人上分析，A針對的是使用者，P針對的是服務執行個體。
3.2 CP與AP
三者的組合，産生了AC、AP、CP三個組合。但在分布式環境中，多執行個體部署是基本條件，因為網絡的不可靠性，造成了P成了硬性條件。是以結果就轉化成了CP、AP兩個分支。
CP、AP分支代表的是硬性條件，在這個基礎上去追求利益化才是這個分支的本質問題。如果是粗暴的對另外一個選項直接放棄，那這個世界就太simple、easy了，而且也不符合咱們對系統的期望和基本使用。這就是2012年重新诠釋後CAP的最終狀态意義，“三選二”是一個僞命題。
基于這個2012年CAP的最終意義，咱們發現CP不是簡單的放棄A，而是保障CP的硬性條件去追求A。是以産生了過半寫入這樣非常經典的使用方式:過半寫入後，分布式節點可以根據少數服從多數完成資料的一緻性要求。是以産生了最大的效益
分布式執行個體的更高可用性，對所有執行個體不在全部寫入成功才認為是成功。
分布式執行個體的更快響應性，使用廣播快速擷取過半結果後直接認定結果。依靠補充手段實作資料的一緻性。
說完CP的改變，再說說AP的對應調整更新。咱們為了高可用放棄資料的一緻性，其實這個說法是不嚴謹，也是錯誤的。資料一緻性是系統的基本要求。那麼要怎麼了解AP，應該從髒讀、幻讀來說，場景允許資料的短暫不一緻，接受資料的最終一緻性。
資料的嚴謹性是系統的一個要求，但允許資料的一定延遲是AP存在的意義。
系統的高可用可以滿足更多的群體，從這個的目标上，是以AP是比較友好的
因為分布式系統，系統是多層面的組合型存在，是以我們并不會說一個系統是AP還是CP。我們是根據系統的業務場景去選擇CP和AP，但是高可用是網際網路分布式應用的特性，是以我們絕大部分情況是追求AP，盡量讓系統滿足更多的使用者。然後基于某些場景資料的強一緻性必要性去選擇CP。 - 總結 -
在分布式環境下，對cap的要求。不管cp 還是ap，并不是完全丢棄另一個，而是優先級問題；在滿足C或者A的基礎上去追求另外一個，結論如下： CP--在強一緻性的底線上追求可用性 (案例-過半寫入)。 AP—在高可用的基礎上追求資料的一緻性(案例-最終一緻性)。 系統以AP為基調，在一些資料高即時、一緻性場景使用CP進行補充。- 作者介紹 -
孫玄
畢業于浙江大學，奈學教育創始人兼CEO，前轉轉公司技術委員會主席，前58集團技術委員會主席，前百度資深研發工程師，騰訊雲TVP，阿裡雲MVP，線上直播大課《百萬架構師》品牌創始人。
林淮川
畢業于西安交通大學；奈學教育《百萬架構師訓練營》講師 和 企業級源碼内源負責人，前大樹金融進階架構師；前大樹金融技術委員會開創者；前大樹金融供應鍊金融技術總監；前天陽宏業交易事業部技術主管；多年網際網路金融行業（ToB）經驗。
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)