翻译：A plain english introduction to CAP Theorem¶
有趣的行文风格，参考一下
你经常会听到 CAP 定理，该定理在设计分布式系统时指定了某种上限。与我的大多数其他介绍教程一样，让我们尝试将 CAP 与现实世界的情况进行比较来理解 CAP。
第 1 章：“记忆公司” - 你的新事业¶
你拥有超群的记忆力。昨晚，当你的配偶因为你记得她的生日并送上礼物而对你表示感谢时，一个奇妙的想法突然闪现。你意识到人们总是容易遗忘事情，而你的记忆力却异常出色。于是，你萌生了一个念头：为什么不利用自己的天赋，开创一番事业呢？你越想越觉得这个主意妙不可言。实际上，你甚至已经构思好了一则报纸广告来阐述你的理念。
你的广告
记忆公司！ - 即使不记得，也永远不会忘记！
你是否曾因为忘记太多事情而感到糟糕？别担心。你与记忆之间只有一个电话之遥！
当你需要记住某件事情时，只需拨打 555—55-REMEM 并告诉我们你需要记住的内容。例如，打电话告诉我们你老板的电话号码，然后忘记去记它。当你需要知道它时……再次拨打相同的号码 [555—55-REMEM]，我们会告诉你你老板的电话号码。
收费：每次请求仅 0.1 美元
因此，你的电话对话通常如下所示：
一个对话示例
- 客户： 嘿，你能帮我记下我邻居的生日吗？
- 你：当然可以...是什么时候呢？
- 客户： 1 月 2 日。
- 你：（在你的纸质笔记本的客户页面上写下来）已经记下了。下次想了解你邻居的生日，请随时给我们打电话！
- 客户： 谢谢！
- 你：不客气！我们已从您的信用卡中收取了 0.1 美元的费用。
第 2 章：扩张之路¶
在 YCombinator 的资助下，你的企业蒸蒸日上。你的创意简单至极，只需一本纸质笔记本和一部电话，却出奇的有效，迅速火遍开来。你开始每天接到数百个电话。
问题也随之而来。你发现越来越多的客户不得不排队等待与你通话。他们中的大多数人甚至不等接通就挂断了电话，语气中充满了厌倦。此外，当你生病或其他原因不能上班时，你将损失一整天的生意。更不用说那些想要获取信息却联系不上你的不满客户了。
你意识到是时候扩大规模了，于是决定让妻子来帮你一起打理生意。
你的计划很简单：
- 你和你的妻子都配有一部分机电话。
- 客户仍然拨打 (555)55-REMEM，并且只需要记住一个号码。
- PBX（交换机）会平等的将客户的电话转接给任何空闲的人。
第 3 章：一次 “糟糕的服务”¶
新系统上线两天后，你接到了一位重要客户——约翰的电话。通话内容如下：
与 Jhon 的通话
约翰： 嘿
你： 欢迎致电“记忆公司”！很高兴为您服务，有什么可以帮您？
约翰： 你能告诉我我去新德里的航班是什么时候吗？
你： 好的，先生，请您稍等。
（你查看你的笔记本）
（天哪！约翰的页面上竟然没有记录“航班日期”！）！！！！
你： 先生，我想这里可能有些误会。您似乎并没有告知我们您去德里的航班信息。
约翰： 什么！我昨天明明才打电话通知过你们！（挂断电话！）
这究竟是怎么一回事？难道是约翰在撒谎？你思索片刻，突然想到了原因！约翰昨天的电话，难道是打给了你的妻子？你快步走到你妻子的书桌前，翻开了她的笔记本。果然，航班信息清晰地记录在那里。你把这件事告诉你的妻子，她也立刻意识到了问题的严重性。
你们的分布式设计竟然存在着如此可怕的缺陷！你们的系统数据不一致！客户随时可能将信息更新发送给您或您妻子，而当该客户下次来电时，如果电话转接给了另一个人，“记忆公司”就无法给出一致的回复！
第 4 章：解决一致性问题¶
好吧，你的竞争对手可能会对糟糕的服务视而不见，但你不会。当你妻子入睡后，你躺在床上辗转反侧，整晚都在思考，终于在早上想到了一个绝妙的计划。你叫醒妻子，兴奋地告诉她：
“亲爱的，这就是我们今后要采取的策略。”
你的新方案
- 每当我们中的任何一个人接到更新电话（也就是客户希望我们记住某些信息时），在结束通话之前，我们会立即告知对方。
- 这样我们俩都能及时记录下任何更新内容。
- 当接到查询电话（也就是客户想要了解他们之前提供的信息时），我们就不需要互相询问了。因为我们两人的笔记本都实时更新，我们可以直接参考笔记回答客户。
不过还有一个问题，那就是所有的“更新”请求必须我们两人共同参与，在这段时间内我们无法同时处理其他工作。（例如，当你接到更新请求并告知你妻子也需要记录时，她就无法接听其他电话。）但没关系，因为我们接到的电话大多是“查询”类型的（客户通常更新一次信息，但会多次查询）。此外，我们绝不能提供错误的信息，这是至关重要的。
“很好，”你妻子表示赞同，“但这个系统还有一个你没有考虑到的问题。如果我们中的一个人某天没有上班怎么办？那么，在那一天，我们将无法处理任何‘更新’电话，因为另一个人无法单独完成更新！我们将面临可用性问题，也就是说，例如，如果我接到更新请求，我将永远无法结束通话，因为即使我已经在笔记本上记录了更新，我也无法在没有你的情况下更新你的笔记。所以，我将永远无法结束通话！”
第 5 章：你想出了有史以来最好的解决方案!¶
你开始意识到，分布式系统可能远非你最初想象的那般简单。要找到一个既能保证“一致性”又能保证“可用性”的解决方案，真的有那么难吗？或许对别人来说很难，但对你来说却不是！！第二天早上，一个绝妙的解决方案浮现在你的脑海，这可是你的竞争对手做梦也想不到的！你再次兴奋地叫醒了你的妻子...
“听好了，” 你对她说，“这就是我们为了保证一致性和可用性所能采取的措施。 这个计划和我昨天告诉你的差不多：...”
你的新方案
- 每当我们中的任何一个人接到更新电话（也就是客户希望我们记住某些信息）时，如果在结束通话之前，另一个人有空，我们会立即告知对方。这样我们俩都能及时记录下任何更新内容。
- 但如果另一个人当时没空（比如没来上班），我们会通过邮件将更新内容发送给对方。
- 第二天，当这个人休假回来上班后，他会先查阅所有邮件，并根据邮件内容更新他的笔记本...然后才会接听第一个电话。
“天才！” 你的妻子赞叹道，“我找不到这个系统的任何漏洞。让我们开始实施吧！‘记忆公司’现在既保证了一致性，又保证了可用性！”
第 6 章：你的妻子生气了（有修改）¶
一开始没有 get 到什么是分区容错性，感觉这里写的太简短了。让 ai 帮我修改了一下。
一开始，你们的系统像钟表一样精准运行。你们能够处理所有客户的更新电话，并且始终保持记录的一致性。即使某一天你们中的一个人生病或需要休假，系统仍然能够依靠另一个人正常运转，这体现了你们的系统具有良好的可用性。
然而，生活总会抛来一些意料之外的挑战。有一天，你们两人都准时上班，准备开始一天的工作。可是，因为一些家庭琐事，你惹恼了你的妻子。你们开始冷战，她虽然像往常一样坐在办公桌前，却拒绝和你进行任何关于工作上的沟通。她不接你打来的电话，也不回复你的邮件，就像你这个人不存在一样。
这突如其来的变化让你的系统陷入了混乱：
-
你的系统不再是一致的： 你继续接听客户的电话，并根据你已知的最新信息进行记录。然而，你不知道的是，你的妻子那里已经有了一些新的更新。由于你们之间缺乏沟通，你们的记录开始出现偏差，系统的一致性被打破了。客户可能会从你们两人那里得到不同的信息，这会导致混乱和错误。
-
更糟糕的是，你的系统的可用性也受到了严重影响。虽然你和你的妻子都在上班，并且愿意接听客户的电话，但由于你们之间沟通的“分区”，你们无法获取到完整的、最新的信息。这就像网络出现了故障，将你们的系统分割成了两个独立的部分，每个部分只能看到自己这边的信息。
这就是一个典型的网络分区 scenario (scenario 是“场景”的意思)。在这个场景中，虽然你们两人都“在线”，但你们之间的沟通渠道被“阻断”了。
你可以决定在和你妻子和好之前不接任何电话，以此来容忍分区...那么你的系统在那段时间内将完全不可用...
第 7 章：结论¶
现在让我们来看看 CAP 定理。它指出，在设计分布式系统时，你无法同时保证一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。你只能选择其中的两个：
- 一致性：你的客户在更新信息后，再次打电话来时总能获得最新信息。无论他们回拨得多快。
- 可用性：只要你们中的任何一个人（你或你的妻子）来上班，‘记忆公司’就能始终接听电话。
- 分区容错性：即使你和你的妻子之间出现通讯中断，‘记忆公司’也能照常运作！
Bonus：最终一致性¶
“也许我们可以换个思路，” 你提议道，“我们雇佣一个实习生，让他负责同步我们的笔记本。这样我们就不需要每次都互相通知了，我们可以专注于接听客户的电话，提高效率。”
“这个主意不错” 你的妻子表示赞同。
于是，你们雇佣了一名计算机专业的大学生小李作为实习生，并向他许诺会给他开实习证明且有转正机会。他的工作很简单：每当你的笔记本上有新的更新时，他就负责将更新内容复制到你妻子的笔记本上；反之亦然。这样，即使你们之间因为某些原因无法直接沟通，你们的记录也能通过实习生保持同步。
这样做的最大好处是，你和你的妻子在进行“更新”时不必阻塞等待，冷战并且在期间也可能正常工作。你们可以继续接听客户的电话，而不必思考更新过程。这就像许多 NoSql 系统的工作方式：一个节点先本地更新自己，然后后台进程会相应地同步所有其他节点。
然而，这个方案并非完美无缺。有时，你们会失去一段时间的一致性。例如，一个客户的电话先打给了你的妻子，在小李有机会更新你的笔记本之前，这个客户又打来了电话，这次电话打给了你。由于你的笔记本还没有更新，你可能会给出一个过时的信息，导致客户得到不一致的回复。
尽管如此，你们认为这并不是一个坏主意。毕竟，这种情况很少发生，客户不会在短时间内频繁打电话，因此这种最终一致性是可以接受的。
以上就是关于 CAP 原则和最终一致性的通俗解释 :)