「翻译」一个简明CAP定理介绍
- 第一章: 你的新公司“Remembrance 公司”
- 第二章: 公司扩张
- 第三章: 你的第一个“差评”
- 第四章: 解决一致性（Consistency）问题
- 第五章：有史以来最好的解决方案
- 第六章：你的妻子生气了
- 第七章：结论
- 番外: 保证最终一致性的跑腿柜员
- 译者读后感
CAP理论总是听过，可我总是讲不清它。或许是我还没遇到那么深刻的场景让我深思吧,当然这也不影响我学习它。这篇从现实生活入手介绍CAP的文章很有意思，值得一看哦
翻译自http://ksat.me ， 原文链接。
我想你会经常听到CAP定理，在设计分布式系统时，它点出了技术上的“天花板”。与我的大多数其他入门教程一样，让我们通过将CAP与实际情况进行比较来理解它。
第一章: 你的新公司“Remembrance 公司”
昨晚，你的妻子夸赞你记住了她的生日还给她送了一份礼物，突然你想到一个很好的点子。人们在记东西方面总是差强人意。而你在这方面又很很很好。那么，何不开一家能发挥你这种天赋的公司呢？你越想越觉得这个主意靠谱，你甚至想出了一个报纸广告来推广你的idea。
Remembrance 公司! - 永远不会忘记, 即使你是鱼的记忆！
你曾因为忘记太多东西而感到伤心难过吗? 别担心。现在只要打个电话就能得到帮助!当你需要记住一样东西, 只需拨打 131- **** ，然后告诉我们你想记住什么。 比如：打电话给我们，告诉我们你老板的电话号码，然后当你忘记了它又迫切需要记起时，打回这个电话，我们就会告诉你你老板的电话号码。
费用 : 每个请求只需要0.1美元！
所以，你的电话对话都将会是这样的:
- 顾客：“ 嘿，你能帮我记住邻居的生日吗?”
- 你：“ OK。。是哪一天呢？”
- 顾客 ：“ 一月二号”
- 你 (把它写在客户专属的那页纸笔记本上)：“已记录。现在您可以随时打电话告诉询问我们你邻居的生日！”
- 顾客 ：“谢谢!”
- 你：“不客气！我们将从你的信用卡收取0.1美元作为记录费用。”
第二章: 公司扩张
你的公司得到了 YCombinator 的资助。你的想法很简单，只需要一个纸笔记本和一个电话，然而却如此有效，业务量像野火一样蔓延开来。你开始每天都能接到数百个电话。
这就造成了个问题。你发现越来越多的顾客不得不排队等着和你说话了。
他们中的大多数人甚至厌倦了等待的电话音而选择挂断电话。另外，前几天你生病了，不能来上班，你因此又损失了一整天的生意。
更不用说那些不满意的客户了，他们恰好那一天迫切需要这些信息。
于是你决定是时候扩大规模，让你的妻子来帮助你了。
从一个简单的计划开始:
- 你和你的妻子各持有一个分机
- 客户仍然可以拨打131- **** ，并且仍然只需要记住这一个数字。（这并没有什么变化）
- 专用的交换机会把客户的电话平均得路由到每个人的分机上。
第三章: 你的第一个“差评”
在你实施新系统两天后，你接到了你的老客户Jhon的电话。事情是这样的:
- Jhon：“Hey”
- 你： “ 很高兴你打电话给“Remembrance 公司”。我能为您效劳吗?”
- Jhon：“ 你能告诉我去新德里的航班是什么时候吗?”
- 你： “可以. .请给我1秒种时间，先生。”
- (你开始查你的笔记本)
- (哇!在Jhon的那一页上没有“航班”的信息)!!!!!
- 你： “先生，我想你是弄错了。你从没告诉过我们你去德里的航班的信息。”
- Jhon：“什么!我昨天刚给你们打电话!(愤怒得挂掉电话!)”
这是怎么回事呢？Jhon 会说谎吗？你想了一会儿，便知道了问题在哪！你妻子昨天接到 Jhon 的电话了吗？你去你妻子的桌子上看了看她的笔记本，果然就在那里。你把这个告诉你的妻子，她也意识到了问题。
你的分布式设计有那么严重的缺陷！你的分布式系统不一致（consistent）! 客户随时都有可能更新一些东西，这些东西可能是你记录，也可能是你的妻子记录，当下一个客户的电话被转到另一个人的时候，Remembrance 公司就不能提供一致（consistent）的回复了。
第四章: 解决一致性（Consistency）问题
嗯，你的竞争对手可能会忽略这一次糟糕的服务，但你不会。在你妻子熟睡之时，你整夜都躺在床上冥思苦想，清晨之时便想出一个漂亮的计划。
你叫醒你的妻子，告诉她：“亲爱的，我们从现在开始这样做。”
- 每当我们中的任何一个人接到电话要求更新(当客户想让我们记住某件事)时，我们都会在电话结束前告诉对方，这样我们双方都能记下所有更新。
- 当需要查询时(当客户来问信息的时候)，我们就不需要互通有无了。由于我们两个人都有最新的数据了，所以查一下就可以了。
不过，只有一个问题，如你所说。那就是更新请求必须涉及到我们两个人，我们不能在这段时间内并行工作。
比如：当你收到更新请求并通知我也需要更新时，我就不能接其他电话了。当然这也没多大关系，因为我们接到的大多数电话都是搜索(客户更新一次，并多次询问)。而且，我们需要不惜任何代价以提供正确的信息。
“漂亮”，你妻子说，“但是你忘了一件事，如果我们有人突然有一天不上班怎么办？那么，我们那一天将不能接受任何更新电话，因为另外一个人不在上班，所以不能更新！”
如此我们便出现了 可用性（Availability）问题， 比如：即使我收到了更新电话，我仍无法完成这个请求，因为即使我在记事本中更新了数据，我也无法让你更新这条数据。
第五章：有史以来最好的解决方案
你开始意识到分布式系统并不像你一开始想的那么简单。提出一个 “一致且可用（Consistent and Available）” 的解决方案有那么难吗？对别人来说可能很困难，但对你来说却不一定！第二天早上，你想出了一个你的竞争对手做梦都想不到的解决方案！你又急匆匆地把妻子叫醒了。
“看”，你告诉她：“我们可以这样做，既保持一致性，又有可用性”。这个计划和你昨天提出的方案很像：
- 每当我们中的任何一个人接到电话要求更新(当客户想让我们记住某件事时)，在挂掉电话之前，如果另一个人有时间（空闲），我们会告诉对方。这样我们都能记下任何更新。
- 但是如果另一个人不在，我们会给他发一封邮件，告诉他需要更新的信息。
- 第二天，当那个人休息一天后来上班时，在上班接电话之前，他首先要做的是查看所有的电子邮件，并相应地更新他的记事本。
“你真是个天才！”，你妻子说！“我找不到这个系统的任何缺陷。现在 Remembrance 公司 一致且可用（Consistent and Available） 了！”
第六章：你的妻子生气了
这段时间一切都很顺利。你的系统是一致的。你的系统工作得很好，即使你们中有一个人没有来工作。
但如果你们两个都去上班，而其中一个选择罢工呢？还记得那些日子吗？你总是用你那些新的想法把你老婆吵醒？ 如果你的妻子决定生你气，一直拒绝接受你的通知，邮件也不看呢？
所以你的这个想法完全行不通！到目前为止，您的想法在一致性和可用性方面都做得很好，但是并不”分区容忍” 你可以通过不再接任何电话，直到你和你的妻子和好为止的方式，来解决分区问题。那么您的系统在这段时间里将无法保证可用性（available）
分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在一致性（Consistency）和可用性（Availability）之间做出选择。）
以上是来自WIKI的解析
第七章：结论
现在我们来看看CAP定理。它指出，当你设计一个分布式系统时，你不能得到一个同时满足一致性、可用性和分区容错 这三种功能的系统。所以你只能选择其中两种：
- 一致性：你的客户们，一旦向你更新了最新的信息，当他们随后打电话总是会得到最新的信息。不管他们什么时候回拨电话。
- 可用性：在你们(你或你的妻子)其中一人休假时，Remembrance公司随时待命。
- 分区容错：即使你和你的妻子失去了联系，Remembrance 公司也能正常工作。
番外: 保证最终一致性的跑腿柜员
这是另一个值得思考的问题。你可以雇一个别的员工，当你或你妻子的笔记本更新后，他会更新其他人的笔记本。这样做的最大好处是，他可以在后台工作，而你或你妻子的任何更新不必等待另一个完成更新。
这其实也是多NoSql系统工作的方式，一个节点在本地自更新，一个后台进程相应地同步数据到其他节点。
这样唯一的问题便是，您将在一段时间范围内不满足一致性。当然即使是这样，这也不是一个坏的系统。因为顾客不会很快忘记事情所以他不会在5分钟内回电话。（而五分钟足够满足最终一致性）
这就是CAP和最终一致性，enjoy it. :)
译者读后感
这里只是简单讲解了一下CAP定理涉及到的简单场景，个人感觉没有很好的讲明分区容错。
一般情况下是时延导致的一个集群中的数据出现了多个版本，一部分节点存储了A版本的数据，另一部分存储B版本的数据，也就是出现了分区，而分区容错是能很好的解决掉分区状况。
一般解决分区情况，需要在C(onsistency)和A(vailable)之间做取舍。
- 保证一致性便会在这段时间里失去可用性。
- 而忽略一致性才能保证系统的可用性。