CAP定理的示例分析

這篇文章給大家分享的是有關CAP定理的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

1.記憶公司

一個天才創意在你頭腦中產生：既然人們的記憶通常不好，而我偏偏擅長記憶，那我為什么不利用記憶天賦開創一番事業。

立馬行動， 你制作了【記憶公司】的開業廣告:

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

記憶公司的日常業務通話記錄：

• 客戶：喂，你好，你可以存儲我鄰居的生日嗎?

• 你：可以，您說。

• 客戶：1月2號

• 你：記錄(在筆記本這個客戶頁上記下信息), 好的，歡迎下次垂詢。

• 客戶：謝謝

• 你：請支付1元

2.業務擴張

憑借創意和人品，【記憶公司】的規模越做越大，而成本只需要筆記本和電話。

當你某天生病不能工作時，你會損失一天的收入;更不用說當天想要信息的客戶會因此發狂。

你有了新計劃：

1. 你和你老婆分別使用分機

2. (555)—55-REMEM 客服電話不變

3. 客服電話會轉到空閑的分機號

3.第一次業務宕機

有一天你收到老客戶羅志祥的電話，要求查詢"明天的約會安排";

你一臉蒙蔽，我不知道啊，你的記憶頁上沒這個信息啊; 客戶咣當掛斷了電話。

當天復盤， 猜想是昨天羅志祥把業務電話打到我老婆那里了，事實確實如此。

你們都意識到分機號帶來的新問題。

多么可怕的分布式設計中的缺陷!你的分布式系統是不一致的!總會有一個時機，客戶會將業務電話打到你們其中一個;在下一次撥號時，客戶就可能收到不一致的信息。

4.修復一致性問題

睡前吹風時間， 你想到一個主意：

•  當我們其中一個人接到客戶新的記憶業務，我們會在掛電話之前告訴另一個人

• 這樣我們都能在筆記本上記下新業務

• 當客戶查詢時，我們兩個都可以輕松應對

這里有一個問題：當其中一人收到新業務電話，兩人就不能并行工作了。

例如：當你收到新業務并告訴我記錄信息時， 我不能接其他電話。

但是這個問題也不大，因為大部分都是查詢業務(可以再撥電話重試)，我們首要的是確保信息正確。

你老婆進一步提出：如果某天你不在崗，我收到新業務，你的筆記本不能得到最新信息，這就會有可用性問題，  因為我沒能通知你，我就不能掛斷電話完成這單業務。

5. 更優方案

你慢慢理解了分布式系統中的“一致性”和“可用性”。你提出了更優方案：

1. 收到新業務電話， 掛電話前通知對方，這樣兩個人都能記下信息

2. 某天其中一人不在崗，另外一人收到新業務電話 ，給缺崗者發一封郵件

3. 第二天缺崗者上崗查收郵件，更新自己的筆記本。

Nice， 現在一致性和可用性都滿足了。

6. 老婆難養

使用優化方案，一切都很順利，你們的筆記本是一致的，當你們其中一人不在崗系統也能很好的運作。

但是， 凡事都有但是， 某天你們都在崗，但是你老婆嫌你碗沒洗干凈，今兒不想理你，收到新業務不通知你了，你的查詢業務就有問題了。

你的方案包含了“一致性”，“可用性”， 但是不滿足“分區容錯”。

為了滿足“分區容錯”， 你可以自我下線(直到你們修復關系)，讓你老婆一人接手業務，但是你的系統就不可用了。

7.結論

我們回過頭看CAP定理：在設計分布式系統時，“一致性Consistency ”“可用性Availability”“分區容錯Partition  Tolerance” 你只能滿足兩個。

?Consistency：一旦接受了客戶的新業務，在客戶后續查詢時必須得到最新的信息

?Availability：只要你們一人在崗，記憶公司就一直提供服務

?Partition Tolerance：你們夫妻二人鬧矛盾了，記憶公司依舊運作

有了這樣的場景，理解CP、AP、CA就不難了

雇傭工具人-->最終一致性

雇傭工具人，更新[未更新的人]的筆記本，相比你老婆實時通知你更新， 這個工具人有個好處是在后臺跑腿，你們兩個業務都不會阻塞。

這也是很多NoSql的工作方式：一個節點在本地更新，后臺進程同步到其他節點， 唯一存在的問題是少數時候丟失一致性。

你老婆收到新業務，工具人還沒來得及跑腿，客戶就立即回撥并轉到你的分機，你給出不一致的答復。這種情況有限，因為客戶不會如此迅速忘記事情。

這就是CAP定理和最終一致性的現實解釋。

感謝各位的閱讀！關于“CAP定理的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！