英文版：http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
中文版：http://blog.sina.com.cn/s/blog_493a8455010161hi.html

中文版原文如下：

1976年6月4號，周5，在遠(yuǎn)離音樂會大廳的一個(gè)樓上的房間內(nèi)，在位于Manchester的Lesser Free TradeHall，Sex Pistols樂隊(duì)（注：Sex Pistols的經(jīng)理人Malcolm McLaren2010.4.8去世）開始了他們的第一次演出（注：規(guī)模太小稱不上演唱會）。關(guān)于當(dāng)晚誰出席了那場演出有些混亂，部分是因?yàn)?周后的另一場音樂會，但最主要的還是因?yàn)椋@場演出被認(rèn)為是永久改變西方音樂文化的一場演出。這場演出是如此的重要且富有象征意義，以至于DavidNolan寫了一本書：《我發(fā)誓我在那里：那場改變了世界的演出》，對那些聲稱自己看過那場演出的人做出判斷。因?yàn)?月4號被認(rèn)為是punk搖滾的開始。

在這之前（大約是在1971年左右）曾有一些protopunk樂隊(duì)，例如New York Dolls和VeletUnderground，但從音樂民俗學(xué)來說，是SexPistols開啟了這場革命，在這場運(yùn)動中驅(qū)動了Buzzcocks樂隊(duì)的吉他，The Smiths樂隊(duì)哀怨的哭訴，TheFall樂隊(duì)的電子切音，Joy Division和SimplyRed樂隊(duì)華麗的升調(diào)（我猜你不了解所有的含義）（注：我缺乏搖滾方面的知識，這部分翻的不是很滿意，好在不影響大局，有punk搖滾知識的同學(xué)可以提供幫助）

2000年7月19號，周三，對主流文化來說并不（象前者一樣）具有同樣的重要性，但這個(gè)日子對互聯(lián)網(wǎng)公司來說，和25年SexPistols對音樂所做的一樣，具有同樣的影響。這就是Eric Brewer在ACM研討會上關(guān)于分布式計(jì)算的原則（Principlesof Distributed Computing）所做的開題演講 （keynote speech）。

SexPistols向同時(shí)代的人展示了幾乎無限制的擴(kuò)展遠(yuǎn)比學(xué)院派的結(jié)構(gòu)主義重要的多，給任何人3根弦以及一些許可就可以組建一支樂隊(duì)。EricBrewer，在那時(shí)被稱為Brewer猜想:

認(rèn)為當(dāng)應(yīng)用系統(tǒng)變得越來越web化，應(yīng)當(dāng)放棄對數(shù)據(jù)一致性（dataconsistency）的擔(dān)憂，因?yàn)橐氆@ 得這種新的分布式系統(tǒng)的高可用性（highavailability），確保數(shù)據(jù)一致性是我們無法做到的，這樣給予任 何人3臺服務(wù)器和一雙關(guān)注客戶體驗(yàn)的眼睛就可以建立一家互聯(lián)網(wǎng)公司.

(本人注：在互聯(lián)網(wǎng)架構(gòu)設(shè)計(jì)當(dāng)中，一般不會放棄可用性這一指標(biāo)，而可用性主要是通過冗余來實(shí)現(xiàn)的，所以不可避免的就會產(chǎn)生網(wǎng)絡(luò)分區(qū)，即選擇了可用性，也就選擇了分區(qū)容忍性，所以沒有辦法確保數(shù)據(jù)的一致性（這里是指強(qiáng)一致性）) 。

Brewer的信徒（當(dāng)天就有的和后來皈依的）包括像Amazon,EBay和Twitter這類公司

2年后，2002年，麻省理工（MIT）的Seth Gilbert和NancyLynch，理論上證明了Brewer猜想是正確的，就此Brewer定理（Theorem）誕生了。

Brewer（CAP）定理

那么到底Brewer的定理是什么，為何它足以和1976年Manchester的punk演出媲美？

Brewer 在2000年的演講是基于他在UCBerkley的理論工作以及主持Inktomi（期間）的觀察，是通過數(shù)年前Brewer和其他人，在如何構(gòu)建高伸縮性系統(tǒng)（highlyscalable system）時(shí)所做出的各種折衷方案的討論（例如：SOSP（Symposium on OperatingSystem Principles）的1997年的Cluster-Based Scalable NetworkService和1999年的Harvest, yield, and scalable tolerantsystem）就像其他的許多思想，因此這個(gè)演講的內(nèi)容并不是全新的，它是許多聰明人的共同成果（我確信Brewer會很快說明這一點(diǎn)）。

Brewer認(rèn)為在分布式的環(huán)境下設(shè)計(jì)和部署系統(tǒng)時(shí)，有3個(gè)核心的系統(tǒng)需求（systemicrequirements），以一種特殊的關(guān)系存在。（他主要是談?wù)揥eb類的應(yīng)用，但如今非常多的公司業(yè)務(wù)是多站點(diǎn)／多國家的，因此該理論同樣適用于你的數(shù)據(jù)中心/LAN/WAN的設(shè)計(jì)）這3個(gè)核心的需求是：Consistency(一致性)，Availability(可用性)和PartitionTolerance(分區(qū)容忍性)，賦予了該理論另外一個(gè)名字 － CAP。
(引用:在某時(shí)刻如果滿足AP，分隔的節(jié)點(diǎn)同時(shí)對外服務(wù)但不能相互通信，將導(dǎo)致狀態(tài)不一致，即不能滿足C；如果滿足CP，網(wǎng)絡(luò)分區(qū)的情況下為達(dá)成C，請求只能一直等待，即不滿足A；如果要滿足CA，在一定時(shí)間內(nèi)要達(dá)到節(jié)點(diǎn)狀態(tài)一致，要求不能出現(xiàn)網(wǎng)絡(luò)分區(qū)，則不能滿足P。)
要想將該理論和現(xiàn)實(shí)的聯(lián)系起來，讓我們舉一個(gè)簡單的例子：

你想購買一套托爾斯泰的《戰(zhàn)爭與和平》，以便在明天開始的長假中有可讀的東西。然而你最喜歡的網(wǎng)上書店只有一本庫存了。你進(jìn)行搜索，確認(rèn)書可以在你出發(fā)前送到，然后將書加入你的購物車。
接著你想起來還有一些其他的東西要買，所以繼續(xù)瀏覽網(wǎng)站（你是否在網(wǎng)站只買一件東西？當(dāng)然要充分利用包裹的費(fèi)用了）。但當(dāng)你查看某個(gè)防曬霜的客戶反饋時(shí)，國內(nèi)某個(gè)地方的某個(gè)人，進(jìn)入網(wǎng)站，將那本書加入到自己的購物車，然后直接付款（他們急需用一本書墊桌子）。

Consistency(數(shù)據(jù)一致性)

如果系統(tǒng)對一個(gè)寫操作返回成功，那么之后的讀請求都必須讀到這個(gè)新數(shù)據(jù)；如果返回失敗，那么所有讀操作都不能讀到這個(gè)數(shù)據(jù)，對調(diào)用者而言數(shù)據(jù)具有強(qiáng)一致性(strong consistency) (又叫原子性 atomic、線性一致性 linearizable consistency)（原文是：A service that is consistent operates fully ornot at all）。

(本人注：在分布式系統(tǒng)當(dāng)中有A、B兩個(gè)節(jié)點(diǎn)，A、B兩個(gè)節(jié)點(diǎn)都要對同一個(gè)數(shù)據(jù)V進(jìn)行讀寫，數(shù)據(jù)一致性要求，A、B兩個(gè)節(jié)點(diǎn)對V的讀取都是同一個(gè)相同的值，很容易想到的解決方案就是將數(shù)據(jù)V放到一個(gè)公共的地方，如數(shù)據(jù)庫里面。A、B對公共節(jié)點(diǎn)進(jìn)行讀取這樣就能達(dá)到數(shù)據(jù)一致性的要求。但是這樣公共節(jié)點(diǎn)就成為了一個(gè)單點(diǎn)，有單點(diǎn)故障的危險(xiǎn)，如果公共節(jié)點(diǎn)失效了，那整個(gè)系統(tǒng)就失效了，這就犧牲了可用性。)
Gilbert和Lynch在他們的證明中使用“atomic”而不是consistent，技術(shù)上來講更準(zhǔn)確，因?yàn)閲?yán)格來說，當(dāng)用在數(shù)據(jù)庫事務(wù)的屬性中時(shí)，consistent是指ACID中的C，其含義是如果數(shù)據(jù)違反了某些預(yù)設(shè)的約束（presetconstraints）就不能被持久化（persisted）。
但如果你將其認(rèn)為是分布式系統(tǒng)中的一個(gè)預(yù)設(shè)約束：
不允許同一數(shù)據(jù)有不同的值，那么我認(rèn)為這個(gè)抽象概念的漏洞就被堵住了（而且，如果Brewer使用atomic這個(gè)詞，就會被稱為AAP定理，那每次我們讀它的時(shí)候都會被送進(jìn)醫(yī)院）（注：我估計(jì)是有口吃加白癡的嫌疑）。
在前面購書的例子中：

1. 你將書加入購物車或無法加入。支付成功或不成功。你無法部分加入或部分支付一本書。
2. 庫存中只有一本書，當(dāng)天只有一個(gè)人能得到它。

如果2個(gè)客戶都可以完成訂單流程（如完成支付），那么倉庫中的和系統(tǒng)中的不一致性就會導(dǎo)致問題。

在這個(gè)例子中也許并不是個(gè)大問題：某個(gè)人在假期中會很無聊或擺弄防曬霜，但如果將其擴(kuò)大到數(shù)千個(gè)不一致性，并且涉及到金錢（例如：金融交易中關(guān)于買賣的東西和交易記錄的內(nèi)容不一致）就會是個(gè)大問題。

也許我們可以利用數(shù)據(jù)庫來解決一致性問題。
在（購書的）訂單流程中的某個(gè)點(diǎn)減少《戰(zhàn)爭與和平》的庫存記錄。當(dāng)其他的客戶到達(dá)這個(gè)點(diǎn)的時(shí)候，書架空了，訂單流程將會通知客戶，而不會進(jìn)行到支付環(huán)節(jié)。
這樣第一個(gè)操作順利完成，第二個(gè)操作則不會完成。數(shù)據(jù)庫非常適合這種情況，因?yàn)閿?shù)據(jù)庫關(guān)注ACID屬性，并且通過隔離性（Isolation）來保證一致性，這樣當(dāng)?shù)谝粋€(gè)客戶會使得庫存記錄減1，同時(shí)購物車的記錄加1，任何中間狀態(tài)同第二個(gè)客戶都是隔離的，當(dāng)然第二個(gè)客戶必須等待幾百毫秒以便數(shù)據(jù)存儲達(dá)到一致狀態(tài)。

Availability(可用性)

可用性只是意味著服務(wù)是可用的（可以完成如上的操作或不完成）。

(本人注：可用性要求服務(wù)在任何時(shí)該都是可用的，這就要求系統(tǒng)當(dāng)中不應(yīng)該有單點(diǎn)的存在，通?？捎眯远际峭ㄟ^冗余的方式來實(shí)現(xiàn)的， 在實(shí)際評估可用性的時(shí)候都是通過幾個(gè)9來表示的，如3個(gè)9就要求系統(tǒng) 在一年當(dāng)中99.9%是可用的，100%的可用性是不可能存在的。)
當(dāng)你購書時(shí)期望得到反饋，而不是瀏覽器報(bào)告網(wǎng)站無法連接的信息。Gilbert和Lynch在其CAP定理的證明中很好地指出了，可用性通常在你最需要的時(shí)刻背棄你。網(wǎng)站通常在業(yè)務(wù)最繁忙的時(shí)刻掛掉，因?yàn)榫W(wǎng)站壓力最大。一個(gè)他人無法訪問的服務(wù)對任何人都沒有價(jià)值。

Partition Tolerance（分區(qū)容忍性）

如果你的應(yīng)用和數(shù)據(jù)庫運(yùn)行在一個(gè)機(jī)器上（忽略規(guī)模的問題并假定你的代碼都沒問題），你的服務(wù)器是作為一種原子處理單元（atomicprocessor）：要么工作要么不工作（例如：如果down機(jī)就不可用，但也不會造成數(shù)據(jù)不一致問題）一旦開始將數(shù)據(jù)和邏輯分布在不同的節(jié)點(diǎn)上，就有形成partition的風(fēng)險(xiǎn)。假定網(wǎng)線被切斷，partition就形成了，節(jié)點(diǎn)A無法和節(jié)點(diǎn)B通訊。由于Web提供的這種分布式能力，臨時(shí)的partition是一個(gè)常見的情況，如之前說所的，在全球化的有多個(gè)數(shù)據(jù)中心的公司中這并不罕見。Gilbert 和Lynch是這樣定義partitiontolerance的,

除了整個(gè)網(wǎng)絡(luò)的故障外，其他的故障（集）都不能導(dǎo)致整個(gè)系統(tǒng)無法正確響應(yīng)。(No set of failuresless than total network failure is allowed to cause the system torespondincorrectly)，

(本人注：分布式系統(tǒng)主要是用來解決大規(guī)模的應(yīng)用，在大規(guī)模應(yīng)用當(dāng)中，不可能由單一主機(jī)提供全部服務(wù)，即在分布式系統(tǒng)當(dāng)中，分區(qū)是必然存在的。分區(qū)容忍性是指在發(fā)生網(wǎng)絡(luò)分區(qū)的時(shí)候，我們該怎么辦？強(qiáng)調(diào)在發(fā)生網(wǎng)絡(luò)分區(qū)的時(shí)候系統(tǒng)也要能夠提供正確的響應(yīng)。
要實(shí)現(xiàn)分區(qū)容忍性通常要求在本地保存一份數(shù)據(jù)副本或者是將所有的服務(wù)都放到同一臺機(jī)器上面，這樣就不會發(fā)生網(wǎng)絡(luò)分區(qū)的情況（這樣做嚴(yán)重影響了可擴(kuò)展性，當(dāng)前系統(tǒng)是不是在分布式環(huán)境下也是一個(gè)值得商權(quán)的問題），所以在CAP當(dāng)中的P是必選項(xiàng)，我們只有在CP，和AP當(dāng)中做出選擇。)
請注意Brewer的注釋，單節(jié)點(diǎn)partition就等同于服務(wù)器crash，因?yàn)槿绻麩o法連接它，那它就和不存在一樣.

定理的重要性

CAP定理在應(yīng)用系統(tǒng)規(guī)模化時(shí)最有效。在低壓力的情況下，小的延遲（以便數(shù)據(jù)庫達(dá)到一致的狀態(tài)）還不足以對總體的性能或用戶體驗(yàn)造成影響。你所承擔(dān)的負(fù)載分布，可能都是出于系統(tǒng)管理的原因？

但隨著活動的增加，吞吐量的上限（pinch-points）將會限制增長并產(chǎn)生錯誤。必須等待網(wǎng)頁的返回是一種情況，另一種情況則是在你輸入信用卡信息后遇到“HTTP 500 java.lang.schrodinger.purchasingerror”，你就想知道你是否付了錢但無法得到東西，還是沒付錢，或者這只是交易中一個(gè)不重要的錯誤。誰知道呢？你不太可能繼續(xù)下去，很有可能到別的地方購物，或更有可能給銀行打電話。

不管是那種情況對業(yè)務(wù)都沒有好處。Amazon聲稱每0.1秒的響應(yīng)延遲都會導(dǎo)致1％的銷售降低。Google說他們注意到0.5秒的延遲會使流量減少15%。

我之前曾就scalability寫過一些東西，不想在這里重復(fù)，只想指出2點(diǎn)：
第一點(diǎn)是，解決scale問題看起來是一個(gè)架構(gòu)方面的問題，但最初的討論卻不是，而是業(yè)務(wù)決策。我已經(jīng)很厭倦聽到技術(shù)人員說，因?yàn)楫?dāng)前的流量，這樣或那樣的方案不能用。并不是說技術(shù)人員錯了，通常他們講的非常正確，是由于從一開始所限定的scale隱含地做了revenue決策－這一問題應(yīng)該在業(yè)務(wù)分析時(shí)明確地決定下來。

第二點(diǎn)是，一旦你開始討論如何scale業(yè)務(wù)系統(tǒng)，大致會落到2種意識形態(tài)陣營中：
數(shù)據(jù)庫派和非數(shù)據(jù)庫派。
對于數(shù)據(jù)庫派來說，毫無疑問，鐘愛數(shù)據(jù)庫技術(shù)，并傾向于談?wù)搊ptimistic locking和sharding這類的東西來解決scale問題，并將數(shù)據(jù)庫作為系統(tǒng)的核心。

非數(shù)據(jù)庫派會傾向于盡可能多的在數(shù)據(jù)庫環(huán)境（避免關(guān)系世界）之外管理數(shù)據(jù)以解決scale問題。

我認(rèn)為，可以公平地說，前一派人對CAP定理的熱情肯定不如后一派（盡管他們在討論定理）。這是因?yàn)?，如果你必須在consistency，availability，partition tolerance三者中放棄一個(gè)，大多數(shù)會選擇放棄consistency，而consistency是數(shù)據(jù)庫存在的理由。（選擇的）邏輯，無疑，是availability和partition tolerance能夠使你賴以賺錢的系統(tǒng)生存下去，而不一致性感覺好像是你可以用好的設(shè)計(jì)來解決的問題。

和IT中的其他事情一樣，這不是非黑即白的問題。EricBrewer在其PODC演講的第13頁slide中，當(dāng)比較ACID和其非正式的對應(yīng)物的BASE時(shí)，甚至說“我認(rèn)為這是一個(gè)系列（spectrum）”（注：這里光譜有一個(gè)系列的含義，是指ACID和BASE是不對立的）。如果你對這個(gè)主題感興趣（有些超出我在這里討論的范圍了），你可以從一篇叫做，“Designand Evaluation of a Continuous Consistency Model for ReplicatedService ”的論文開始，該文由Haifeng Yu和Amin Vahdat編寫。大家不可以將CAP解讀為暗示數(shù)據(jù)庫的消亡。

盡管這樣，雙方都認(rèn)同scale的解決之道是分布式的并行計(jì)算，而不是曾經(jīng)認(rèn)為的超級計(jì)算機(jī)。90年代中期進(jìn)行的Network ofWorkstations項(xiàng)目受到了Eric Brewer的影響，并最終導(dǎo)致了CAP定理的誕生，因?yàn)樗谝粋€(gè)關(guān)于Inktomi andthe Internet Bubble 的介紹中說到，答案總是并行處理：

如果不通過并行的方式，你就沒有機(jī)會，在合適的時(shí)間內(nèi)解決問題。和其他許多事情一樣。如果是個(gè)很大的項(xiàng)目，會需要很多人來完成它。因此，如果想建造一個(gè)橋梁，就需要很多建筑工人。這就是并行處理。因此問題會演變?yōu)椤叭绾螌⒉⑿刑幚砗蚷nternet結(jié)合在一起”

圖片證明

這里有一個(gè)簡單的圖片證明，因?yàn)槲野l(fā)現(xiàn)用圖片會比較好理解。多數(shù)情況下我使用和Gilber和Lynch相同的術(shù)語，以便和他們的論文聯(lián)系起來。

CAP理論基礎(chǔ)

CAP理論基礎(chǔ)

CAP理論基礎(chǔ)

因此，CAP告訴我們，如果想讓A和B是高可用（highlyavailable）的（例如，以最小的延遲（latency）提供服務(wù)）并且想讓所有的N1到Nn（n的值可以是數(shù)百甚至是上千）的節(jié)點(diǎn)能夠冗余網(wǎng)絡(luò)的partitions（丟失信息，無法傳遞信息，硬件無法提供服務(wù)，處理失?。?，那么有時(shí)我們就得面臨這樣的情況：某些節(jié)點(diǎn)認(rèn)為V的值是V0（一本《戰(zhàn)爭與和平》的庫存）而其他節(jié)點(diǎn)會認(rèn)為V的值是V1（《戰(zhàn)爭與和平》的庫存為0）

我們都希望所有的事情是結(jié)構(gòu)化的，一致的且和諧的，就像70年代早期的progrock樂隊(duì)，但我們面臨的是一些punk風(fēng)格的混亂。事實(shí)上，盡管有可能會嚇到我們的祖母，但一旦你了解了它就還OK，因?yàn)?者可以非常愉快地在一起工作。

讓我們從事務(wù)（transactional）的角度快速分析一下。

CAP理論基礎(chǔ)

CAP選擇

當(dāng)處理CAP的問題時(shí)，你會有幾個(gè)選擇。最明顯的是：

1. 放棄Partition Tolerance：如果你想避免partition問題發(fā)生，你就必須要阻止其發(fā)生。一種做法是將所有的東西（與事務(wù)相關(guān)的）都放到一臺機(jī)器上?；蛘叻旁谙駌ack這類的atomically-failling單元上。無法100%地保證，因?yàn)檫€是有可能部分失敗，但你不太可能碰到由partition問題帶來的負(fù)面效果。當(dāng)然，這個(gè)選擇會嚴(yán)重影響scale限制。
2. 放棄Availability：相對于放棄partition tolerance來說，其反面就是放棄availability。一旦遇到partition事件，受影響的服務(wù)需要等待數(shù)據(jù)一致，因此在等待期間就無法對外提供服務(wù)。在多個(gè)節(jié)點(diǎn)上控制這一點(diǎn)會相當(dāng)復(fù)雜，而且恢復(fù)的節(jié)點(diǎn)需要處理邏輯，以便平滑地返回服務(wù)狀態(tài)。
3. 放棄Consistency：或者如同Werner Vogels所提倡的，接受事情會變得“最終一致（EventuallyConsistent）”（2008年12月更新）。Vogels的文章值得一讀。他比我在這里討論了更多的操作方面的細(xì)節(jié)。許多的不一致性并不比你想的需要更多的工作（意味著持續(xù)的consistency或許并不是我們所需要的）。在購書的例子中，如果一本庫存的書，接到了2個(gè)訂單，第二個(gè)就會成為備份訂單。只要告知客戶這種情況（請記住這是一種罕見的情況），也許每個(gè)人都會高興的。
4. 引入（jump）BASE.有一種架構(gòu)的方法（approach）稱作BASE（Basically Available,Soft-state,Eventuallyconsistent）支持最終一致概念的接受。
   BASE（注：化學(xué)中的含義是堿），如其名字所示，是ACID（注：化學(xué)中的含義是酸）的反面，但如果認(rèn)為任何架構(gòu)應(yīng)該完全基于一種（BASE）或完全基于另一種（ACID），就大錯特錯了。這一點(diǎn)是需要謹(jǐn)記重點(diǎn)，尤其是這個(gè)行業(yè)的“一邊倒（ooohshiny，注：這個(gè)完全意譯了）”的習(xí)慣性的采用策略。這里，我要遵從Brewer教授自己的觀點(diǎn)，他就本文通過email表達(dá)了自己的觀點(diǎn)（comment）：

如您所指出的，術(shù)語BASE第一次出現(xiàn)是在1997年的SOSP文章中。那一年，我和我的學(xué)生在他們的辦公室中，一起造了這個(gè)詞。我承認(rèn)這有些人為的因素，但ACID也是一樣的－－遠(yuǎn)超人們所能意識到的，所以我們?nèi)藶檫€行。JimGray和我討論了這些縮寫，他欣然認(rèn)可ACID也有些扭曲（stretch）–A和D（的概念）有相當(dāng)多的重復(fù)部分，C至多也是含糊不清的。但這對術(shù)語暗示了一系列的理念（idea ofspectrum），這是PODC演講中的一個(gè)重要觀點(diǎn)，你正確地指出了這一點(diǎn)。

EBay的DanPritchett有一篇關(guān)于BASE的很棒的介紹 （presentation）。

Guy Pardon，atomikos的CTO寫了一篇他稱作“CAP解決之道（證實(shí)Brewer的錯誤）”的文章，提出了一種架構(gòu)方法，可以達(dá)到Consistency,Availability和Partition-tolerance，當(dāng)然附帶了一些說明（顯然你不可能在同一時(shí)刻滿足全部的3個(gè)要求）。值得一讀，Guy雄辯地表達(dá)了（在該領(lǐng)域）相反的觀點(diǎn)。

總結(jié)

在Consistency,Availability和Partition-tolerance中，你只能保證2點(diǎn)，這是確實(shí)的，并且已經(jīng)被這個(gè)星球上最成功的網(wǎng)站證實(shí)了。如果對網(wǎng)站是有效的，我看不出在企業(yè)環(huán)境中，在日常的工作中，不考慮同樣的折衷設(shè)計(jì)的理由。如果業(yè)務(wù)方面明確表明不需要上規(guī)模（scale）那好，有簡單的解決方案，但這是值得討論的。在任何情況下，這些討論都是針對特定操作的適合的設(shè)計(jì)，而不是廬山（注：shebang取意譯）全貌。正如Brewer在其郵件中所說的：“唯一的我可以加入的是同一服務(wù)的不同部分可以選擇這一系列（spectrum）中的不同的點(diǎn)”有時(shí)，無論scale的代價(jià)如何，你絕對需要一致性，因?yàn)槿鄙偎娘L(fēng)險(xiǎn)太大了。

這些天，我說得有些過，說Amazon和EBay沒有scalability問題，我認(rèn)為他們的確有這類問題，但他們現(xiàn)在有辦法解決該問題。這也是為何他們可以自由討論這些問題的原因。不論他們現(xiàn)在是何規(guī)模（結(jié)合他們早就公布的數(shù)字）只會越來越大。一旦規(guī)模上來，你的問題就會轉(zhuǎn)到（shift）諸如操作維護(hù)，監(jiān)控，發(fā)布軟件的更新等等－ 當(dāng)然（這些問題）都很難解決，但值得，尤其當(dāng)你因此獲得現(xiàn)金流（revenue stream）。

參考

1. HP接納CAPd定理，白皮書的標(biāo)題為分布式數(shù)據(jù)沒有免費(fèi)的午餐
2. Sussex大學(xué)計(jì)算機(jī)科學(xué)講義，關(guān)于分布式事務(wù)和網(wǎng)絡(luò)partitions
3. Jens Alfke的關(guān)于數(shù)據(jù)庫，scaling和Twitter的好文
4. Pat Helland的關(guān)于分布式事務(wù)和SOA的Microsoft論文，叫做數(shù)據(jù)在外和數(shù)據(jù)在外 ，他隨后將其和CAP理論關(guān)聯(lián)了起來
5. 另一套計(jì)算機(jī)科學(xué)方面課程slides ，這一次是來自Virginia的George Mason大學(xué)，是關(guān)于分布式軟件系統(tǒng)和CAP定理以及ACID和BASE兩大陣營的對比
6. 在英國1976年6月4號被認(rèn)為是Punk搖滾誕生的日子。感謝Charlie Dellacona指出在美國Ramones普遍認(rèn)為是從1974年就開啟了這一運(yùn)動，盡管他們正式的punk唱片是在同時(shí)發(fā)行的
7. 感謝Hiroshi Yuki，提供了本文的日文版譯本
8. 感謝哦Daniel Cohen，提供了分為兩 部分的希伯來版譯本
9. 感謝Wang Qi，提供了本文的中文版譯本