這篇文章給大家分享的是有關CAP定理的示例分析的內(nèi)容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
創(chuàng)新互聯(lián)專注于黃驊網(wǎng)站建設服務及定制,我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供黃驊營銷型網(wǎng)站建設,黃驊網(wǎng)站制作、黃驊網(wǎng)頁設計、黃驊網(wǎng)站官網(wǎng)定制、小程序開發(fā)服務,打造黃驊網(wǎng)絡公司原創(chuàng)品牌,更為您提供黃驊網(wǎng)站排名全網(wǎng)營銷落地服務。
一個天才創(chuàng)意在你頭腦中產(chǎn)生:既然人們的記憶通常不好,而我偏偏擅長記憶,那我為什么不利用記憶天賦開創(chuàng)一番事業(yè)。
立馬行動, 你制作了【記憶公司】的開業(yè)廣告:
Remembrance Inc! - Never forget, even without remembering!
Ever felt bad that you forget so much? Don’t worry. Help is just a phone away!
When you need to remember something, just call 555—55-REMEM and tell us what you need to remember. For eg., call us and let us know of your boss’s phone number, and forget to remember it. when you need to know it back.. call back the same number[(555)—55-REMEM ] and we’ll tell you what’s your boss’s phone number.
Charges : only $0.1 per request
記憶公司的日常業(yè)務通話記錄:
客戶:喂,你好,你可以存儲我鄰居的生日嗎?
你:可以,您說。
客戶:1月2號
你:記錄(在筆記本這個客戶頁上記下信息), 好的,歡迎下次垂詢。
客戶:謝謝
你:請支付1元
憑借創(chuàng)意和人品,【記憶公司】的規(guī)模越做越大,而成本只需要筆記本和電話。
當你某天生病不能工作時,你會損失一天的收入;更不用說當天想要信息的客戶會因此發(fā)狂。
你有了新計劃:
1. 你和你老婆分別使用分機
2. (555)—55-REMEM 客服電話不變
3. 客服電話會轉(zhuǎn)到空閑的分機號
有一天你收到老客戶羅志祥的電話,要求查詢"明天的約會安排";
你一臉蒙蔽,我不知道啊,你的記憶頁上沒這個信息啊; 客戶咣當掛斷了電話。
當天復盤, 猜想是昨天羅志祥把業(yè)務電話打到我老婆那里了,事實確實如此。
你們都意識到分機號帶來的新問題。
多么可怕的分布式設計中的缺陷!你的分布式系統(tǒng)是不一致的!總會有一個時機,客戶會將業(yè)務電話打到你們其中一個;在下一次撥號時,客戶就可能收到不一致的信息。
睡前吹風時間, 你想到一個主意:
當我們其中一個人接到客戶新的記憶業(yè)務,我們會在掛電話之前告訴另一個人
這樣我們都能在筆記本上記下新業(yè)務
當客戶查詢時,我們兩個都可以輕松應對
這里有一個問題:當其中一人收到新業(yè)務電話,兩人就不能并行工作了。
例如:當你收到新業(yè)務并告訴我記錄信息時, 我不能接其他電話。
但是這個問題也不大,因為大部分都是查詢業(yè)務(可以再撥電話重試),我們首要的是確保信息正確。
你老婆進一步提出:如果某天你不在崗,我收到新業(yè)務,你的筆記本不能得到最新信息,這就會有可用性問題, 因為我沒能通知你,我就不能掛斷電話完成這單業(yè)務。
你慢慢理解了分布式系統(tǒng)中的“一致性”和“可用性”。你提出了更優(yōu)方案:
1. 收到新業(yè)務電話, 掛電話前通知對方,這樣兩個人都能記下信息
2. 某天其中一人不在崗,另外一人收到新業(yè)務電話 ,給缺崗者發(fā)一封郵件
3. 第二天缺崗者上崗查收郵件,更新自己的筆記本。
Nice, 現(xiàn)在一致性和可用性都滿足了。
使用優(yōu)化方案,一切都很順利,你們的筆記本是一致的,當你們其中一人不在崗系統(tǒng)也能很好的運作。
但是, 凡事都有但是, 某天你們都在崗,但是你老婆嫌你碗沒洗干凈,今兒不想理你,收到新業(yè)務不通知你了,你的查詢業(yè)務就有問題了。
你的方案包含了“一致性”,“可用性”, 但是不滿足“分區(qū)容錯”。
為了滿足“分區(qū)容錯”, 你可以自我下線(直到你們修復關系),讓你老婆一人接手業(yè)務,但是你的系統(tǒng)就不可用了。
我們回過頭看CAP定理:在設計分布式系統(tǒng)時,“一致性Consistency ”“可用性Availability”“分區(qū)容錯Partition Tolerance” 你只能滿足兩個。
?Consistency:一旦接受了客戶的新業(yè)務,在客戶后續(xù)查詢時必須得到最新的信息
?Availability:只要你們一人在崗,記憶公司就一直提供服務
?Partition Tolerance:你們夫妻二人鬧矛盾了,記憶公司依舊運作
有了這樣的場景,理解CP、AP、CA就不難了
雇傭工具人,更新[未更新的人]的筆記本,相比你老婆實時通知你更新, 這個工具人有個好處是在后臺跑腿,你們兩個業(yè)務都不會阻塞。
這也是很多NOSQL的工作方式:一個節(jié)點在本地更新,后臺進程同步到其他節(jié)點, 唯一存在的問題是少數(shù)時候丟失一致性。
你老婆收到新業(yè)務,工具人還沒來得及跑腿,客戶就立即回撥并轉(zhuǎn)到你的分機,你給出不一致的答復。這種情況有限,因為客戶不會如此迅速忘記事情。
這就是CAP定理和最終一致性的現(xiàn)實解釋。
感謝各位的閱讀!關于“CAP定理的示例分析”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!