1. 程式人生 > >可能是CAP理論的最好解釋

可能是CAP理論的最好解釋

一篇非常,翻譯水平有限,不準確之處請參考原文,還請見諒。

Chapter 1: “Remembrance Inc” Your new venture :

Last night when your spouse appreciated you on remembering her birthday and bringing her a gift, a strange Idea strikes you. People are so bad in remembering things. And you’re sooo good at it. So why not start a venture that will put your talent to use? The more you think about it, the more you like it. In fact you even come up with a news paper ad which explains your idea

第一章:記憶公司

昨晚當你的妻子感激你記得她生日還給她買了禮物時,你突然冒出一個想法。人們的記性總是很糟而你又是如此善於記憶,所以為什麼不利用你的天賦幹出一番事業呢?你越想越覺得這個點子不錯。事實上你甚至想出一份新聞廣告來解釋你的想法。

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

記憶公司! - 不用記憶,從不忘記

您是否曾為健忘而感到沮喪?不用擔心,只需一通電話。當您需要記住什麼時,撥打555-55,告訴我們您想記住的東西。例如,來電讓我們知道您老闆的電話號,然後忘了這事。當您想要知道已忘了的東西時,撥打同樣的號碼,我們將告訴您老闆的電話號。費用:每次僅需0.1美元。

So, your typical phone conversation will look like this:

·Customer : Hey, Can you store my neighbor’s birthday?

·You: Sure.. when is it?

·Customer : 2nd of jan

·You: (write it down against the customer’s page in your paper note book )Stored. Call us any time for knowing your neighbor’s birthday again!

·Customer : Thank you!

·You: No problem! We charged your credit card with $0.1

所以您的通話通常是這樣的:

Ø客戶:嗨!能記一下我鄰居的生日嗎?

Ø你:當然可以,他生日是什麼時候?

Ø客戶:12

Ø你:(在筆記本上該客戶的那一頁記下)記好了!想知道他生日時隨時打給我們!

Ø客戶:謝謝!

Ø不客氣,您的信用卡將支付0.1美元。

Chapter 2 : You scale up:

Your venture gets funded by YCombinator. Your Idea is so simple, needs nothing but a paper notebook and phone, yet so effective that it spreads like wild fire. You start getting hundreds of call every day.

And there starts the problem. You see that more and more of your customers have to wait in the queue to speak to you. Most of them even hang up tired of the waiting tone. Besides when you were sick the other day and could not come to work you lost a whole day of business. Not to mention all those dissatisfied customers who wanted information on that day.
You decide it’s time for you to scale up and bring in your wife to help you.

第二章:公司擴張

你拿到了YC的投資。這個點子是如此簡單,只需紙筆和電話,但卻像燎原之火一樣發展迅猛。你每天逐漸有上百個來電。但問題也隨之而來。你發現越來越多的客戶要排隊等你應答。他們都受夠了等待。而且當你生病沒法工作時,你將損失一整天的生意,更不用說那些客戶的不滿。於是你決定:是時候把你的妻子拉過來幫忙了。

Your start with a simple plan:

1.You and your wife both get an extension phone

2.Customers still dial (555)–55-REMEM and need to remember only one number

3.A pbx will route the a customers call to whoever is free and equally

你的計劃很簡單:

1.你和你妻子都有分機號

2.客戶還是撥打原來的號碼

3.交換機將把客戶來電發給你們倆空閒的那位。

Chapter 3 : You have your first “Bad Service” :

Two days after you implemented the new system, you get a call from your trusted customer Jhon. This is how it goes:

·Jhon: Hey

·You: Glad you called “Remembrance Inc!”. What can I do for you?

·Jhon: Can you tell me when is my flight to New Delhi?

·You: Sure.. 1 sec sir
(You look up your notebook)
(wow! there is no entry for “flight date” in Jhon’s page)!!!!!

·You: Sir, I think there is a mistake. You never told us about your flight to delhi

·Jhon: What! I just called you guys yesterday!(cuts the call!)

第三章:第一次Bad Service

就在擴張後兩天,你接到了老客戶Jhon的來電:

ØJhon:嗨!

Ø你:感謝致電記憶公司,有什麼可以幫您?

ØJhon:能告訴我第一次飛新德里的時間嗎?

Ø你:當然可以,請稍等(你翻閱你的筆記本,在Jhon那頁卻沒發現航班這一項)

Ø先生,抱歉,我想您沒有告訴過我們您去新德里的航班資訊。

ØJhon:什麼!?我昨天就打給過你們!(結束通話了)

How did that happen? Could Jhon be lying? You think about it for a second and the reason hits you! Could Jhon’s call yesterday reached your wife? You go to your wife’s desk and check her notebook. Sure enough it’s there. You tell this to your wife and she realizes the problem too.

What a terrible flaw in your distributed design! Your distributed system is not consistent! There could always be a chance that a customer updates something which goes to either you or your wife and when the next call from the customer is routed to another person there will not be a consistent reply from Remembrance Inc!

怎麼可能發生這種事?Jhon在說謊嗎?你一下子想到了原因!可能Jhon昨天打給了你的妻子。於是你到她桌上檢查她的筆記本。沒錯,就是這個原因。你告訴了你妻子,她也意識到了這個問題。多麼糟糕的問題!你的分散式系統不是一致性的!客戶打給你或你妻子,再來電時卻是另一個人接的,你的記憶公司沒法給出一個一致性的答覆!

Chapter 4: You fix the Consistency problem:

Well, your competitors may ignore a bad service, but not you. You think all night in the bed when your wife is sleeping and come up with a beautiful plan in the morning. You wake up your wife and tell her:

” Darling this is what we are going to do from now”

·Whenever any one of us get a call for an update(when the customer wants us to remember something) before completing the call we tell the other person

·This way both of us note down any updates

·When there is call for search(When the customer wants information he has already stored) we don’t need to talk with the other person. Since both of us have the latest updated information in both of our note books we can just refer to it..

第四章:修復一致性問題

你的競爭者可能會忽視這個問題,你卻不會。你妻子入睡時你想了一整晚,終於在清晨時想出了一個美麗的方案。你叫醒她說:

親愛的,這是我們從今往後要做的事:

Ø不論我倆誰接到客戶要求記東西的電話,打完電話前我們要告訴另一個人

Ø這樣我倆都能記下任何的更新

Ø當客戶要求查詢時,我們不用互相問,因為我倆的筆記本上都記錄了所有更新。

There is only one problem though, you say, and that is an “update” request has to involve both of us and we cannot work in parallel during that time. For eg. when you get an update request and telling me to update too, i cannot take other calls. But that’s okay because most calls we get anyway are “search” (a customer updates once and asks many times) . Besides, we cannot give wrong information at any cost.

“Neat” your wife says, “but there is one more flaw in this system that you haven’t thought of. What if one of us doesn’t report to work on a particular day? On that day, then, we won’t be able to take “any” Update calls, because the other person cannot be updated! We will have Availability problem , i.e, for eg., if an update request comes to me I will never be able to complete that call because even though I have written the update in my note book, I can never update you. So I can never complete the call!”

但是還是有一個問題,客戶要求記東西的來電需要我們倆人同時處理,所以那段時間就沒法並行工作了。例如,當你接到儲存或更新請求時也會告訴我,於是我就不能接聽其他來電了。但是因為多數來電都是查詢的,所以也沒什麼大問題(客戶更新一次然後查詢多次)。而且,我們要不惜一切代價避免記錯東西。

很好!你的妻子說但是還有個問題你沒想到。要是我倆中的一個哪天不能來工作呢?在那天我們就不能一起接受更新的來電了,因為另一個人不能記下這個更新。所以我們會有可用性問題!例如,我接到更新來電時就沒法完成這個請求,因為即使我在我的本子上記下了,我也沒法告訴你。所以我沒法完成這個來電

Chapter 5: You come up with the greatest solution Ever:

You being to realize a little bit on why distributed system might not be as easy as you thought at first. Is it that difficult to come up with a solution that could be both “Consistent and Available”? Could be difficult for others, but not for you!! Then next morning you come up with a solution that your competitors cannot think of in their dreams! You wake your wife up eagerly again..

” look” , you tell her.. “This is what we can do to be consistent and available” . The plan is mostly similar to what I told you yesterday:

·i) Whenever any one of us get a call for an update(when the customer wants us to remember something) before completing the call, if the other person is available we tell the other person. This way both of us note down any updates

·ii) But if the other person is not available(doesn’t report to work) we send the other person an email about the update.

·iii) The next day when the other person comes to work after taking a day off, He first goes through all the emails, updates his note book accordingly.. before taking his first call.

第五章:最棒的解決方法

你有點兒意識到了為什麼分散式系統不像你一開始想的那樣簡單。想出一個既一致又可用的方案很難嗎?對其他人也許很難,但對你則不是!第二天早上,你想出了一個你的競爭者們做夢都想不到的解決方法。你再一次急切地叫醒了你妻子。

看!你跟她說,這就是我們既一致又可用的做法,方案與我昨天告訴你的很像

Ø不論我倆誰接到客戶要求記東西的電話,打完電話前我們要告訴另一個人,這樣我倆都能記下任何的更新。

Ø但是如果另一個人請假不在,我們給他發一封更新的郵件。

Ø第二天他來工作時,在處理任何來電前先看一遍這些郵件,更新到他的本子上。

Genius! You wife says! I can’t find any flaws in this systems. Let’s put it to use.. Remembrance Inc! is now both Consistent and available!

天才啊!你的妻子說。這個方案想不到任何的問題的。咱們就這樣來吧!記憶公司現在既是一致的又是可用的!

Chapter 6: Your wife gets angry :

Everything goes well for a while. Your system is consistent. Your system works well even when one of you doesn’t report to work. But what if Both of you report to work and one of you doesn’t update the other person? Remember all those days you’ve been waking your wife up early with your Greatest-idea-ever-bullshit? * What if your wife decides to take calls but is too angry with you and decides not to update you for a day? Your idea totally breaks! Your idea so far is good for consistency and availability but is not Partition Tolerant!*
You can decide to be partition tolerant by deciding not to take any calls until you patch up with your wife.. Then your system will not be “available” during that time…

第六章:妻子的憤怒

一切都很順利。你的系統是一致的,當你倆中的一人不能工作時也能執行良好。但是假如你們都來工作了,但是卻沒把更新告訴另一個人呢?想想你吵醒你妻子,說你那些所謂的偉大的點子。要是哪天她接電話卻很生氣而不告訴你去更新呢?你的方法完全毀了。到目前為止,你的方法是一致而可用的,但卻不是分割槽容忍的。你可以在與你妻子和好前不接聽任何來電,於是你的系統在那段時間又是不可用的了

Chapter 7: Conclusion :

So Let’s look at CAP Theorem now. Its states that, when you are designing a distributed system you can get cannot achieve all three of Consistency, Availability and Partition tolerance. You can pick only two of:

·Consistency: You customers, once they have updated information with you, will always get the most updated information when they call subsequently. No matter how quickly they call back

·Availability: Remembrance Inc will always be available for calls until any one of you(you or your wife) report to work.

·Partition Tolerance: Remembrance Inc will work even if there is a communication loss between you and your wife!

第六章:總結

讓我們現在看一下CAP理論。它說:當你設計分散式系統時,你只能實現一致性、可用性和分割槽容忍中的兩者:

Ø一致性:你的客戶再次來電時總能查到他們剛來電更新的資訊,不論相隔多短

Ø可用性:不論你和你妻子誰來工作,記憶公司總能接聽來電,處理客戶請求

Ø分割槽容忍:即便你和你妻子失聯,記憶公司依然能正常運轉

Bonus : Eventual Consistency with a run around clerk :

Here is another food for thought. You can have a run around clerk, who will update other’s notebook when one of your’s or your wife’s note books is updated. The greatest benefit of this is that, he can work in background and one of your or your wife’s “update” doesn’t have to block, waiting for the other one to update. This is how many NoSql systems work, one node updates itself locally and a background process synchronizes all other nodes accordingly… The only problem is that you will lose consistency of some time. For eg., a customer’s call reaches your wife first and before the clerk has a chance to update your notebook , the customer’ calls back and it reaches you. Then he won’t get a consistent reply.. But that said, this is not at all a bad idea if such cases are limited. For eg., assuming a customer won’t forget things so quickly that he calls back in 5 minutes.

獎勵:最終一致性和東奔西跑的員工

你可以僱一個員工負責當一個本子上內容更新時去更新另一個本子。最大的好處就是,他能在後臺工作,你或你妻子更新時不用等待另一個完成更新。這就是許多NoSQL資料庫系統的工作方式。一個結點進行本地更新,後臺程序將更新內容同步到其他所有結點。唯一的問題是:你將會失去一定時間的一致性。例如,客戶先打給你妻子,在負責更新的員工未完成更新你的本子時,客戶打給了你。那麼他就無法得到一個一致性的回覆。但即便如此,在某些情況下倒也不算是個壞主意。例如,一個客戶不會忘東西忘得這麼快,一般五分鐘左右才會再次來電。

That’s CAP and eventual consistency for you in simple english :)

這就是給您的CAP理論和最終一致性的極簡解釋:)