多是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

因此您的通話一般是這樣的：

Ø  客戶：嗨！能記一下我鄰居的生日嗎？

Ø  你：固然能夠，他生日是何時？

Ø  客戶：1月2日

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

Ø  客戶：謝謝！

Ø  不客氣，您的信用卡將支付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理論和最終一致性的極簡解釋：）