用生活案例形容说明什么是CAP定理

用生活案例形容说明什么是CAP定理

您经常会听到 CAP 定理，它规定了设计分布式系统时的某种上限。

第 1 章：成立"纪念公司" ：
昨晚，当你的妻子感谢你记得她的生日并给她带了礼物时，你突然产生了一个奇怪的想法。人们总是记不住事情。而你却非常擅长。那么，为什么不开始一项能发挥你天赋的事业呢？你越想越喜欢。事实上，你甚至想出了一个新闻报纸广告，来解释你的想法：

Remembrance Inc！- 不忘初心，方得始终！有没有因为经常忘记而感到难过？别担心。只要一个电话，就能得到帮助！当您需要记住某些东西时，只需拨打 555-55-REMEM，告诉我们您需要记住什么。例如，给我们打电话，告诉我们您老板的电话号码，但忘记了。当您需要知道它时，回拨同一个号码（(555)-55-REMEM），我们就会告诉您老板的电话号码。收费：每次请求仅收 0.1 美元

因此，您的典型电话对话会是这样的：

• 客户：嘿，您能存储我邻居的生日吗？当然可以，是什么时候？
• 客户：1 月 2 日
• 您：（在纸质便签本的客户页面上写下）已存储。没问题！我们从您的信用卡中扣除了 0.1 美元
• 客户：谢谢！
• 您：没问题！我们从您的信用卡中扣除了 0.1 美元 

第 2 章：你扩大规模：
您的企业获得 YCombinator 的资助。你的创意非常简单，只需要一本纸质笔记本和一部电话，但却非常有效，像野火一样蔓延开来。你开始每天接到数百个电话。

问题开始出现了。你发现越来越多的客户不得不排队等候与你通话。他们中的大多数人甚至厌倦了等待的提示音而挂断了电话。此外，当你前几天生病不能来上班时，你损失了一整天的生意。更不用说那些对你不满意的客户了。
你决定扩大规模，让你的妻子来帮助你。

你从一个简单的计划开始：

• 你和你的妻子都有一部分机电话
• 客户仍然拨打 (555)-55-REMEM，只需记住一个号码
• PBX 会将客户的电话转接给空闲的人，而且同样空闲

第 3 章：你的第一次 "糟糕服务"：
实施新系统两天后，你接到信任客户 Jhon 的电话。事情是这样的：

• Jhon：嘿
• 你：很高兴你打电话给 "Remembrance Inc!"。我能为你做些什么？你能告诉我什么时候飞新德里吗？当然可以。1 秒钟，先生（您翻看笔记本）（哇！Jhon 的页面上没有 "航班日期 "条目）!!!!!
• 您：先生，我想这是个错误。你从来没有告诉过我们你飞往德里的航班
• Jhon：我昨天才给你们打过电话！）

怎么会这样？Jhon会不会在撒谎？你想了一会儿，原因就出来了！昨天 Jhon 的电话会不会打到你妻子那里？您走到妻子的办公桌前，查看她的笔记本。果然在那里。

你的分布式设计中存在多么可怕的缺陷！ 你的分布式系统并不一致！

你的分布式系统不一致！客户更新的内容有可能会转到你或你妻子那里，而当客户的下一个电话转到另一个人那里时，Remembrance 公司的回复就不一致了！ 

第 4 章：你解决了一致性问题：
好吧，你的竞争对手可能会忽略糟糕的服务，但你不会。当你的妻子熟睡时，你在床上想了一夜，早上想出了一个漂亮的计划。你叫醒妻子并告诉她：
"亲爱的，从现在开始我们就这么做。"

• 无论何时，只要我们中的任何一个人接到更新电话（当客户希望我们记住某些东西时），我们都会在完成呼叫之前告诉对方
• 这样我们两个人都会记下任何更新
• 当接到搜索电话（当客户需要他已经存储的信息时），我们不需要与对方交谈。因为我们两个人的笔记本中都有最新更新的信息，我们只需参考即可。

但是只有一个问题，您说，那就是 "更新 "请求必须涉及到我们两个人，在此期间我们无法并行工作。例如，当您收到更新请求并告诉我也要更新时，我就不能接听其他电话。不过没关系，因为我们接到的大多数电话都是 "搜索 "电话（客户更新一次，询问多次）。
"很好，"你的妻子说，"但是这个系统还有一个缺陷你没有想到。
"很好，"你妻子说，"但是这个系统还有一个缺陷你没有想到。在那一天，我们将无法接听 "任何 "更新电话，因为另一个人无法更新！

我们将面临 "可用性 "问题，例如，如果有人向我提出更新请求，我将永远无法完成该通话，因为即使我已将更新内容写在笔记本上，我也永远无法向您更新。因此，我永远无法完成通话！"

第 5 章：你想出了史上最棒的解决方案：
你开始意识到，为什么分布式系统可能并不像你最初想象的那样简单。提出一个既 "一致又可用 "的解决方案有那么难吗？对别人来说可能很难，但对你来说不难！"！第二天早上，你想出了一个竞争对手做梦都想不到的解决方案！
"看"，你告诉她。
"看"，你告诉她："这就是我们可以做的，让我们始终如一，随时随地"。这个计划与我昨天告诉您的大致相同：

• i）每当我们中的任何一个人接到要求更新的电话时（当客户希望我们记住某些事情时），在完成通话之前，如果另一个人有空，我们就告诉他。
• ii)但是，如果对方没有时间（没有来上班），我们就会给对方发送一封关于更新的电子邮件。
• iii)第二天，当对方休息一天后上班时，他会先查看所有电子邮件，更新他的笔记本，然后再接第一个电话！你妻子说！我找不到这个系统的任何缺陷。让我们开始使用它吧。

第 6 章：你的妻子生气了：
有一段时间一切都很顺利。您的系统始终如一。即使你们中的一个人没有来上班，你们的系统也运行良好。但是，如果你们两个人都去上班了，而其中一个人没有更新另一个人的信息，那该怎么办呢？还记得那些天你一直用 "有史以来最伟大的想法 "之类的废话把你妻子吵醒吗？* 如果你的妻子决定接听电话，但因为太生你的气而决定一天都不更新你的信息呢？你的想法完全破灭了！

到目前为止，你的想法在一致性和可用性方面是不错的，但却不具备分区容忍性！*你可以决定不接任何电话，直到你与妻子和好为止，从而实现分区容忍性。那么你的系统在这段时间内就不会 "可用"...... 

第 7 章：结论 :
所以，现在让我们来看看 CAP 定理。该定理指出，在设计分布式系统时，你不可能同时实现一致性、可用性和分区容差这三个目标。您只能选择其中的两项：

• 一致性：您的客户一旦在您这里更新了信息，当他们随后致电您时，将始终获得最新的信息。无论他们回电的速度有多快
• 可用性：Remembrance Inc 在你们（您或您的妻子）中的任何一位报到上班之前，始终可以接听电话。
• 分区容忍度：即使您和妻子之间的通信中断，Remembrance Inc 也能正常工作！

与临时工最终保持一致：
这是另一个值得思考的问题。您可以安排一名临时工，当您或您妻子的笔记本更新时，他就会更新其他人的笔记本。这样做的最大好处是，他可以在后台工作，而您或您妻子的 "更新 "工作不必阻塞，不必等待另一个人更新。

这就是许多 NoSql 系统的工作方式，一个节点在本地更新自己，后台进程相应地同步所有其他节点......唯一的问题是，你会在一段时间内失去一致性。例如，顾客的电话先打到你的妻子那里，在店员有机会更新你的笔记本之前，顾客的电话又打到了你那里。这样他就得不到一致的答复。

但话虽如此，如果这种情况有限，这也不失为一个好主意。例如，假设顾客不会很快忘记事情，以至于 5 分钟后再打回来。