這篇文章主要講解了“web分布式系統(tǒng)CAP的概念是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“web分布式系統(tǒng)CAP的概念是什么”吧！
引言
CAP是分布式系統(tǒng)、特別是分布式存儲領(lǐng)域中被討論最多的理論，“ 什么是CAP定理？”在Quora 分布式系統(tǒng)分類下排名 FAQ 的 No.1。CAP在程序員中也有較廣的普及，它不僅僅是“C、A、P不能同時滿足，最多只能3選2”，以下嘗試綜合各方觀點，從發(fā)展歷史、工程實踐等角度講述CAP理論。希望大家透過本文對CAP理論有更多地了解和認識。
CAP定理
CAP由 Eric Brewer)在2000年P(guān)ODC會議上提出[1][2]，是Eric Brewer在Inktomi[3]期間研發(fā)搜索引擎、分布式web緩存時得出的關(guān)于數(shù)據(jù)一致性(consistency)、服務(wù)可用性(availability)、分區(qū)容錯性(partition-tolerance)的猜想：
It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance.
該猜想在提出兩年后被證明成立[4]，成為我們熟知的CAP定理：
數(shù)據(jù)一致性(consistency)：如果系統(tǒng)對一個寫操作返回成功，那么之后的讀請求都必須讀到這個新數(shù)據(jù)；如果返回失敗，那么所有讀操作都不能讀到這個數(shù)據(jù)，對調(diào)用者而言數(shù)據(jù)具有強一致性(strong consistency) (又叫原子性 atomic、線性一致性 linearizable consistency)[5]
服務(wù)可用性(availability)：所有讀寫請求在一定時間內(nèi)得到響應(yīng)，可終止、不會一直等待
分區(qū)容錯性(partition-tolerance)：在網(wǎng)絡(luò)分區(qū)的情況下，被分隔的節(jié)點仍能正常對外服務(wù)
在某時刻如果滿足AP，分隔的節(jié)點同時對外服務(wù)但不能相互通信，將導(dǎo)致狀態(tài)不一致，即不能滿足C；如果滿足CP，網(wǎng)絡(luò)分區(qū)的情況下為達成C，請求只能一直等待，即不滿足A；如果要滿足CA，在一定時間內(nèi)要達到節(jié)點狀態(tài)一致，要求不能出現(xiàn)網(wǎng)絡(luò)分區(qū)，則不能滿足P。
C、A、P三者最多只能滿足其中兩個，和FLP定理一樣，CAP定理也指示了一個不可達的結(jié)果(impossibility result)。
CAP的工程啟示
CAP理論提出7、8年后，NoSql圈將CAP理論當作對抗傳統(tǒng)關(guān)系型數(shù)據(jù)庫的依據(jù)、闡明自己放寬對數(shù)據(jù)一致性(consistency)要求的正確性[6]，隨后引起了大范圍關(guān)于CAP理論的討論。
CAP理論看似給我們出了一道3選2的選擇題，但在工程實踐中存在很多現(xiàn)實限制條件，需要我們做更多地考量與權(quán)衡，避免進入CAP認識誤區(qū)[7]。
1、關(guān)于 P 的理解
Partition字面意思是網(wǎng)絡(luò)分區(qū)，即因網(wǎng)絡(luò)因素將系統(tǒng)分隔為多個單獨的部分，有人可能會說，網(wǎng)絡(luò)分區(qū)的情況發(fā)生概率非常小啊，是不是不用考慮P，保證CA就好[8]。要理解P，我們看回CAP證明[4]中P的定義：
In order to model partition tolerance, the network will be allowed to lose arbitrarily many messages sent from one node to another.
網(wǎng)絡(luò)分區(qū)的情況符合該定義，網(wǎng)絡(luò)丟包的情況也符合以上定義，另外節(jié)點宕機，其他節(jié)點發(fā)往宕機節(jié)點的包也將丟失，這種情況同樣符合定義?，F(xiàn)實情況下我們面對的是一個不可靠的網(wǎng)絡(luò)、有一定概率宕機的設(shè)備，這兩個因素都會導(dǎo)致Partition，因而分布式系統(tǒng)實現(xiàn)中 P 是一個必須項，而不是可選項[9][10]。
對于分布式系統(tǒng)工程實踐，CAP理論更合適的描述是：在滿足分區(qū)容錯的前提下，沒有算法能同時滿足數(shù)據(jù)一致性和服務(wù)可用性[11]：
In a network subject to communication failures, it is impossible for any web service to implement an atomic read/write shared memory that guarantees a response to every request.
2、CA非0/1的選擇
P 是必選項，那3選2的選擇題不就變成數(shù)據(jù)一致性(consistency)、服務(wù)可用性(availability) 2選1？工程實踐中一致性有不同程度，可用性也有不同等級，在保證分區(qū)容錯性的前提下，放寬約束后可以兼顧一致性和可用性，兩者不是非此即彼[12]。
CAP定理證明中的一致性指強一致性，強一致性要求多節(jié)點組成的被調(diào)要能像單節(jié)點一樣運作、操作具備原子性，數(shù)據(jù)在時間、時序上都有要求。如果放寬這些要求，還有其他一致性類型：
序列一致性(sequential consistency)[13]：不要求時序一致，A操作先于B操作，在B操作后如果所有調(diào)用端讀操作得到A操作的結(jié)果，滿足序列一致性
最終一致性(eventual consistency)[14]：放寬對時間的要求，在被調(diào)完成操作響應(yīng)后的某個時間點，被調(diào)多個節(jié)點的數(shù)據(jù)最終達成一致
可用性在CAP定理里指所有讀寫操作必須要能終止，實際應(yīng)用中從主調(diào)、被調(diào)兩個不同的視角，可用性具有不同的含義。當P(網(wǎng)絡(luò)分區(qū))出現(xiàn)時，主調(diào)可以只支持讀操作，通過犧牲部分可用性達成數(shù)據(jù)一致。
工程實踐中，較常見的做法是通過異步拷貝副本(asynchronous replication)、quorum/NRW，實現(xiàn)在調(diào)用端看來數(shù)據(jù)強一致、被調(diào)端最終一致，在調(diào)用端看來服務(wù)可用、被調(diào)端允許部分節(jié)點不可用(或被網(wǎng)絡(luò)分隔)的效果[15]。
3、跳出CAP
CAP理論對實現(xiàn)分布式系統(tǒng)具有指導(dǎo)意義，但CAP理論并沒有涵蓋分布式工程實踐中的所有重要因素。
例如延時(latency)，它是衡量系統(tǒng)可用性、與用戶體驗直接相關(guān)的一項重要指標[16]。CAP理論中的可用性要求操作能終止、不無休止地進行，除此之外，我們還關(guān)心到底需要多長時間能結(jié)束操作，這就是延時，它值得我們設(shè)計、實現(xiàn)分布式系統(tǒng)時單列出來考慮。
延時與數(shù)據(jù)一致性也是一對“冤家”，如果要達到強一致性、多個副本數(shù)據(jù)一致，必然增加延時。加上延時的考量，我們得到一個CAP理論的修改版本PACELC[17]：如果出現(xiàn)P(網(wǎng)絡(luò)分區(qū))，如何在A(服務(wù)可用性)、C(數(shù)據(jù)一致性)之間選擇；否則，如何在L(延時)、C(數(shù)據(jù)一致性)之間選擇。
感謝各位的閱讀，以上就是“web分布式系統(tǒng)CAP的概念是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對web分布式系統(tǒng)CAP的概念是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！
重慶分公司
重慶分公司
