佳文分享：CAP定理
1976年6月4號，周5，在遠離音樂會大廳的一個樓上的房間內，在位于Manchester的Lesser Free Trade Hall ，Sex Pistols 樂隊（注：Sex Pistols的經理人Malcolm McLaren 2010.4.8去世）開始了他們的第一次演出（gig， 注：規模太小稱不上演唱會 ）。關于當晚誰出席了那場演出有些混亂，部分是由于6周后的還有一場音樂會，但最基本的還是由于，這場演出被覺得是永久改變西方音樂文化 的一場演出。這場演出是如此的重要且富有象征意義，以至于David Nolan寫了一本書：《我發誓我在那里：那場改變了世界的演出 》，對那些聲稱自己看過那場演出的人做出推斷。由于6月4號被覺得是punk搖滾的開始。
在這之前（大約是在1971年左右）曾有一些protopunk 樂隊，比如New York Dolls 和Velet Underground ，但從音樂民俗學來說，是Sex Pistals開啟了這場革命，在這場運動中驅動了Buzzcocks 樂隊的吉他，The Smiths 樂隊哀怨的哭訴，The Fall 樂隊的電子切音，Joy Division 和Simply Red 樂隊華麗的升調（我猜你不了解全部的含義）（注：我缺乏搖滾方面的知識，這部分翻的不是非常愜意，好在不影響大局，有punk搖滾知識的同學能夠提供幫助 ）
2000年7月19號，周三，對主流文化來說并不（象前者一樣）具有相同的重要性，但這個日子對互聯網公司來說，和25年Sex Pistols對音樂所做的一樣，具有相同的影響。這就是Eric Brewer 在ACM研討會上關于分布式計算的原則 （Principles of Distributed Computing）所做的開題演講 （keynote speech）。
Sex Pistols向同一時候代的人展示了差點兒無限制的狂躁遠比學院派的結構主義重要的多，給不論什么人3根弦以及一些許可就能夠組建一支樂隊。Eric Brewer，在那時被稱為Brewer猜想，覺得當應用系統變得越來越web化，應當放棄對數據一致性（data consistency）的擔憂，由于要想獲得這樣的新的分布式系統的高可用性（high availability），確保數據一致性是我們無法做到的，這樣給予不論什么人3臺server和一雙關注客戶體驗的眼睛就能夠建立一家互聯網公司。Brewer的信徒（當天就有的和后來皈依的）包含像Amazon , EBay 和Twitter 這類公司
2年后，2002年，麻省理工（MIT）的Seth Gilbert 和Nancy Lynch ，理論上證明 了Brewer猜想是正確的，就此Brewer定理（Theorem）誕生了。
Brewer（CAP）定理
那么究竟Brewer的定理是什么，為何它足以和1976年Manchester的punk演出媲美？
Brewer 在2000年的演講是基于他在UC Berkley的理論工作以及主持Inktomi （期間）的觀察，是通過數年前Brewer和其它人，在怎樣構建高伸縮性系統（highly scalable system）時所做出的各種折衷方案的討論（比如：SOSP（Symposium on Operating System Principles）的1997年的Cluster-Based Scalable Network Service 和1999年的Harvest, yield, and scalable tolerant system ）就像其它的很多思想，因此這個演講的內容并非全新的，它是很多聰明人的共同成果（我確信Brewer會非常快說明這一點）。
Brewer覺得在分布式的環境下設計和部署系統時，有3個核心的系統需求 （systemic requirements），以一種特殊的關系存在。（他主要是談論Web類的應用，但現在許多的公司業務是多網站／多國家的，因此該理論相同適用于你的數據中心/LAN/WAN的設計）
這3個核心的需求是：Consistency ，Availability 和Partition Tolerance ，賦予了該理論另外一個名字 － CAP 。
要想將該理論和現實的聯系起來，讓我們舉一個簡單的樣例：你想購買一套托爾斯泰 的《戰爭與和平 》，以便在明天開始的長假中有可讀的東西。然而你最喜歡的網上書店僅僅有一本庫存了。你進行搜索，確認書能夠在你出發前送到，然后將書增加你的購物車。接著你想起來另一些其它的東西要買，所以繼續瀏覽站點（你是否在站點僅僅買一件東西？當然要充分利用包裹的費用了）。但當你查看某個防曬霜的客戶反饋時，國內某個地方的某個人，進入站點，將那本書增加到自己的購物車，然后直接付款（他們急需解決桌子搖晃的問題，當中一條桌腳比其它的短的多）。
- Consistency
一個服務是一致的完整操作或全然不操作（A service that is consistent operates fully or not at all，精確起見列出原文，也有人將其簡稱為數據一致性）。Gilbert 和Lynch在他們的證明中使用“atomic”而不是consistent，技術上來講更準確，由于嚴格來說，當用在數據庫事務的屬性中時，consistent是指ACID 中的C，其含義是假設數據違反了某些預設的約束（preset constraints）就不能被持久化（persisted）。但假設你將其覺得是分布式系統中的一個預設約束：不同意同一數據有不同的值，那么我覺得這個抽象概念的漏洞就被堵住了（而且，假設Brewer使用atomic這個詞，就會被稱為AAP定理，那每次我們讀它的時候都會被送進醫院）（注：我預計是有口吃加白癡的嫌疑）。在前面購書的樣例中，你將書增加購物車或無法增加。支付成功或不成功。你無法部分增加或部分支付一本書。庫存中僅僅有一本書，當天僅僅有一個人能得到它。假設2個客戶都能夠完畢訂單流程（如完畢支付），那么倉庫中的和系統中的不一致性就會導致問題。在這個樣例中或許并非個大問題：某個人在假期中會非常無聊或擺弄防曬霜，但假設將其擴大到數千個不一致性，而且涉及到金錢（比如：金融交易中關于買賣的東西和交易記錄的內容不一致）就會是個大問題。或許我們能夠利用數據庫來解決一致性問題。在（購書的）訂單流程中的某個點降低《戰爭與和平》的庫存記錄。當其它的客戶到達這個點的時候，書架空了，訂單流程將會通知客戶，而不會進行到支付環節。這樣第一個操作順利完畢，第二個操作則不會完畢。數據庫非常適合這樣的情況，由于數據庫關注ACID屬性，而且通過隔離性（Isolation）來保證一致性，這樣當第一個客戶會使得庫存記錄減1，同一時候購物車的記錄加1，不論什么中間狀態同第二個客戶都是隔離的，當然第二個客戶必須等待幾百毫秒以便數據存儲達到一致狀態。
- Availability
可用性僅僅是意味著服務是可用的（能夠完畢如上的操作或不完畢）。當你購書時期望得到反饋，而不是瀏覽器報告站點無法連接的信息。Gilbert 和Lynch在其CAP定理的證明中非常好地指出了，可用性通常在你最須要的時刻背棄你。站點通常在業務最繁忙的時刻掛掉，由于站點壓力最大。一個他人無法訪問的服務對不論什么人都沒有價值。??
- Partition Tolerance
假設你的應用和數據庫執行在一個機器上（忽略規模的問題并假定你的代碼都沒問題），你的server是作為一種原子處理單元（atomic processor）：要么工作要么不工作（比如：假設down機就不可用，但也不會造成數據不一致問題）
一旦開始將數據和邏輯分布在不同的節點上，就有形成partition的風險。假定網線被切斷，partition就形成了，節點A無法和節點B通訊。因為Web提供的這樣的分布式能力，暫時的partition是一個常見的情況，如之前說所的，在全球化的有多個數據中心的公司中這并不罕見。
Gilbert 和Lynch是這樣定義partition tolerance的
除了整個網絡的故障外，其它的故障（集）都不能導致整個系統無法正確響應。(No set of failures less than total network failure is allowed to cause the system to respond incorrectly)
請注意Brewer的凝視，單節點partition就等同于servercrash，由于假設無法連接它，那它就和不存在一樣。
定理的重要性
CAP定理在應用系統規模化時最有效。在低壓力的情況下，小的延遲（以便數據庫達到一致的狀態）還不足以對整體的性能或用戶體驗造成影響。你所承擔的負載分布，可能都是出于系統管理的原因。？
但隨著活動的添加，吞吐量的上限（pinch-points）將會限制增長并產生錯誤。必須等待網頁的返回是一種情況，還有一種情況則是在你輸入信用卡信息后遇到 “HTTP 500 java.lang.schrodinger.purchasingerror”，你就想知道你是否付了錢但無法得到東西，還是沒付錢，或者這僅僅是交易中一個不重要的錯誤。誰知道呢？你不太可能繼續下去，非常有可能到別的地方購物，或更有可能給銀行打電話。
無論是那種情況對業務都沒有優點。Amazon聲稱 每0.1秒的響應延遲都會導致1％的銷售減少。Google說 他們注意到0.5秒的延遲會使流量降低15%。
我之前 曾就scalability寫過一些東西，不想在這里反復，僅僅想指出2點：第一點是，解決scale問題看起來是一個架構方面的問題，但最初的討論卻不是，而是業務決策。我已經非常厭倦聽到技術人員說，由于當前的流量，這樣或那樣的方案不能用。并非說技術人員錯了，通常他們講的非常正確，是由于從一開始所限定的scale 隱含地做了revenue決策－這一問題應該在業務分析時明白地決定下來。
第二點是，一旦你開始討論怎樣scale業務系統，大致會落到2種意識形態陣營中：數據庫派和非數據庫派。
對于數據庫派來說，毫無疑問，鐘愛數據庫技術，并傾向于談論optimistic locking 和sharding 這類的東西來解決scale問題，并將數據庫作為系統的核心。
非數據庫派會傾向于盡可能多的在數據庫環境（避免關系世界）之外管理數據以解決scale問題。
我覺得，能夠公平地說，前一派人對CAP定理的熱情肯定不如后一派（雖然他們在討論定理 ）。這是由于，假設你必須在consistency，availability，partition tolerance三者中放棄一個，大多數會選擇放棄consistency，而consistency是數據庫存在的理由。（選擇的）邏輯，無疑，是availability和partition tolerance可以使你賴以賺錢的系統生存下去，而不一致性感覺好像是你可以用好的設計來解決的問題。
和IT中的其它事情一樣，這不是非黑即白的問題。Eric Brewer在其PODC演講的第13頁slide中，當比較ACID和其非正式的相應物的BASE 時，甚至說“我覺得這是一個系列（spectrum）”（注：這里光譜有一個系列的含義，是指ACID和BASE是不正確立的）。假設你對這個主題感興趣（有些超出我在這里討論的范圍了），你能夠從一篇叫做，“Design and Evaluation of a Continuous Consistency Model for Replicated Service ”的論文開始，該文由Haifeng Yu和Amin Vahdat 編寫。大家不能夠將CAP解讀為暗示數據庫的消亡。
雖然這樣，兩方都認同scale的解決之道是分布式的并行計算，而不是以前覺得的超級計算機。90年代中期進行的Network of Workstations 項目受到了Eric Brewer的影響，并終于導致了CAP定理的誕生，由于他在一個關于Inktomi and the Internet Bubble 的介紹中說到，答案總是并行處理：
?
假設不通過并行的方式，你就沒有機會，在合適的時間內解決這個問題。和其它很多事情一樣。假設是個非常大的項目，會須要非常多人來完畢它。因此，假設想建造一個橋梁，就須要非常多建筑工人。這就是并行處理。因此問題會演變為“怎樣將并行處理和internet結合在一起”
圖片證明
這里有一個簡單的圖片證明，由于我發現用圖片會比較好理解。多數情況下我使用和Gilber 和Lynch同樣的術語，以便和他們的論文聯系起來。
?
上圖顯示了網絡中的兩個節點N1，N2。他們共享同一數據V（庫存中《戰爭與和平》的數量），其值為V0。N1上有一個算法A，我們能夠覺得A是安全，無bug，可預測和可靠的。N2上有一個相似的算法B。在這個樣例中，A寫入V的新值而B讀取V的值。
?
正常情況下（sunny-day scenario），步驟例如以下：(1)A寫入新的V值，我們稱作v1。(2)N1發送信息給N2，更新V的值。(3)如今B讀取的V值將會是V1。
假設網絡斷開（partions）（意味著從N1無法發送信息到N2）那么在第3步的時候，N2就會包括一個步一致的V值。
希望看上去非常明確。即使將其scale到幾百個事務（transaction）中，這也會成為一個大問題。假設M是一個異步消息，那么N1無法知道N2是否收到了消息。即使M是保證能發送的（guaranteed delivery），N1也無法知道是否消息由于partition事件的發生而延遲，或N2上的其它故障而延遲。即使將M作為同步（synchronous）信息也不能解決這個問題，由于那將會使得N1上A的寫操作和N1到N2的更新事件成為一個原子操作（atomic operation），而這將導致相同的等待問題，該問題我們已經討論過（或更糟）。Gilbert 和Lynch已經證明，使用其它的變種方式，即使是部分同步模型（每一個節點上使用安排好的時鐘）也無法保證原子性（atomicity）。
因此，CAP告訴我們，假設想讓A和B是高可用（highly available）的（比如，以最小的延遲（latency）提供服務）而且想讓全部的N1到Nn（n的值可以是數百甚至是上千）的節點可以冗余網絡的partitions（丟失信息，無法傳遞信息，硬件無法提供服務，處理失敗），那么有時我們就得面臨這種情況：某些節點覺得V的值是V0（一本《戰爭與和平》的庫存）而其它節點會覺得V的值是V1（《戰爭與和平》的庫存為0）
我們都希望全部的事情是結構化的，一致的且和諧的，就像70年代早期的prog rock 樂隊，但我們面臨的是一些punk風格的混亂。其實，雖然有可能會嚇到我們的祖母，但一旦你了解了它就還OK，由于2者能夠很愉快地在一起工作。
讓我們從事務（transactional）的角度高速分析一下。
?
假設我們有個事務（比如：一組環繞著persistent數據項V的工作單元）a，a1是寫操作，a2是讀操作。在一個local的系統中，能夠利用數據庫中的簡單鎖（simple locking）的機制方便地處理，隔離（isolating）a2中的讀操作，直到a1的寫成功完畢。然而，在分布式的模型中，須要考慮到N1和N2節點，中間的消息同步也要完畢才行。除非我們能夠控制a2何時發生，我們永遠無法保證a2能夠讀到a1寫入的數據。全部增加控制的方法（堵塞，隔離，中央化的管理，等等）會要么影響partition tolerance，要么影響a1(A)和a2(B)的可用性。
CAP選擇
當處理CAP的問題時，你會有幾個選擇。最明顯的是：
有一種架構的方法（approach）稱作BASE（B asically A vailable, S oft-state, E ventually consistent）支持終于一致概念的接受。BASE（注：化學中的含義是堿），如其名字所看到的，是ACID（注：化學中的含義是酸）的反面，但假設覺得不論什么架構應該全然基于一種（BASE）或全然基于還有一種（ACID），就大錯特錯了。這一點是須要謹記重點，尤其是這個行業的“一邊倒（oooh shiny，注：這個全然意譯了）”的習慣性的採用策略。這里，我要遵從Brewer教授自己的觀點，他就本文通過email表達了自己的觀點（comment）：
如您所指出的，術語BASE第一次出現是在1997年的SOSP文章中。那一年，我和我的學生在他們的辦公室中，一起造了這個詞。我承認這有些人為的因素，但ACID也是一樣的－－遠超人們所能意識到的，所以我們人為還行。Jim Gray和我討論了這些縮寫，他欣然認可ACID也有些扭曲（stretch）– A和D（的概念）有相當多的反復部分，C至多也是含糊不清的。但這對術語暗示了一系列的理念（idea of spectrum），這是PODC演講中的一個重要觀點，你正確地指出了這一點。
EBay的Dan Pritchett有一篇關于BASE的非常棒的介紹 （presentation）。
Guy Pardon， atomikos 的CTO寫了一篇他稱作“CAP解決之道（證實Brewer的錯誤） ”的文章，提出了一種架構方法，能夠達到Consistency, Availability和Partition-tolerance，當然附帶了一些說明（顯然你不可能在同一時刻滿足所有的3個要求）。值得一讀，Guy雄辯地表達了（在該領域）相反的觀點。
總結
在Consistency, Availability和Partition-tolerance中，你僅僅能保證2點，這是確實的，而且已經被這個星球上最成功的站點證實了。假設對站點是有效的，我看不出在企業環境中，在日常的工作中，不考慮相同的折衷設計的理由。假設業務方面明白表明不須要上規模（scale）那好，有簡單的解決方式，但這是值得討論的。在不論什么情況下，這些討論都是針對特定操作的適合的設計，而不是廬山（注：shebang取意譯）全貌。正如Brewer在其郵件中所說的：“唯一的我能夠增加的是同一服務的不同部分能夠選擇這一系列（spectrum）中的不同的點”有時，不管scale的代價怎樣，你絕對須要一致性 ，由于缺少它的風險太大了。
這些天，我說得有些過，說Amazon和EBay沒有scalability問題，我覺得他們的確有這類問題，但他們如今有辦法解決該問題。這也是為何他們能夠自由討論這些問題的解決辦法。不論他們如今是何規模（結合他們早就發布的數字）僅僅會越來越大。一旦規模上來，你的問題就會轉到（shift）諸如操作維護，監控，發布軟件的更新等等 － 當然（這些問題）都非常難解決，但值得，尤其當你因此獲得現金流（revenue stream）。
參考
轉載于:https://www.cnblogs.com/gcczhongduan/p/4085309.html
總結
以上是生活随笔為你收集整理的佳文分享：CAP定理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 配置猫抓，抓取网页视频
- 下一篇： 基础的数组/链表实现的队列