可能是 CAP 理论的最好解释

这是一篇非常 精彩的解释 CAP 理论的文章。本文系翻译整理，翻译水平有限，不准确之处请参考原文，还请见谅。

第一章：记忆公司（Remembrance Inc）—— 你的新事业

昨晚，当你的妻子感激你记得她的生日并送上礼物时，你突然冒出一个想法：人们的记性总是很糟，而你又是如此善于记忆。为什么不利用你的天赋干出一番事业呢？你越想越觉得这个点子不错，事实上，你甚至构思出了一则报纸广告来解释你的想法：

记忆公司（Remembrance Inc）！—— 不用记忆，从不忘记

您是否曾为健忘而感到沮丧？不用担心，帮助只需一通电话！

当您需要记住什么时，拨打 555-55-REMEM，告诉我们您想记住的东西。例如，来电让我们记下您老板的电话号码，然后您就可以忘了这事。当您想要查询时，拨打同样的号码，我们将告诉您老板的电话号码。

费用：每次请求仅需 0.1 美元

所以，您的典型通话流程是这样的：

  • 客户：嗨！能记一下我邻居的生日吗？
  • 你：当然可以，他生日是什么时候？
  • 客户：1 月 2 日。
  • 你：（在笔记本上该客户的那一页记下）记好了！想知道他生日时随时打给我们！
  • 客户：谢谢！
  • 你：不客气，您的信用卡将扣除 0.1 美元。

第二章：规模扩张

你拿到了 YCombinator 的投资。这个点子是如此简单，只需纸笔和电话，但却像燎原之火一样发展迅猛。你每天逐渐有上百个来电。

但问题也随之而来。你发现越来越多的客户要排队等你应答，他们都受够了等待音。而且当你生病没法工作时，你将损失一整天的生意，更不用说那些当天需要查询信息的不满客户。

于是你决定：是时候把你的妻子拉过来帮忙了，进行规模扩张（Scale Up）。

你的计划很简单：

  1. 你和你妻子都有分机号。
  2. 客户还是拨打原来的号码 555-55-REMEM。
  3. 交换机（PBX）将把客户来电路由给你们俩中空闲的那一位。

第三章：第一次“糟糕的服务”

就在扩张后两天，你接到了老客户 John 的来电。对话如下：

  • John：嗨！
  • 你：感谢致电记忆公司，有什么可以帮您？
  • John：能告诉我第一次飞新德里的航班时间吗？
  • 你：当然可以，请稍等。（你翻阅你的笔记本，在 John 那页却没发现航班这一项）…… 先生，抱歉，我想您没有告诉过我们您去新德里的航班信息。
  • John：什么！？我昨天就打给过你们！（挂断了电话）

怎么可能发生这种事？John 在说谎吗？你思考了一会儿，突然想到了原因：可能 John 昨天打给了你的妻子。

于是你到她桌上检查她的笔记本。没错，记录就在那里。你告诉了你妻子，她也意识到了这个问题。

多么糟糕的设计缺陷！你的分布式系统不是一致性的（Consistent）！ 客户打给你或你妻子，再来电时却是另一个人接的，你的记忆公司没法给出一个一致性的答复。数据在不同节点（你和你妻子）之间出现了不一致。

第四章：修复一致性问题

你的竞争者可能会忽视这个问题，但你不会。你妻子入睡时你想了一整晚，终于在清晨时想出了一个方案。你叫醒她说：

“亲爱的，这是我们从今往后要做的事：”

  1. 不论我俩谁接到客户要求记东西（更新） 的电话，在挂断前我们要告诉另一个人。
  2. 这样我俩都能记下任何的更新。
  3. 当客户要求查找（查询） 时，我们不用互相问，因为我俩的笔记本上都记录了所有最新更新。

但是还是有一个问题。客户要求记东西的来电需要我们俩人同时处理，所以那段时间就没法并行工作了。例如，当你接到保存或更新请求时也会告诉我，于是我就不能接听其他来电了。但是因为多数来电都是查找的（客户更新一次然后查找多次），所以也没什么大问题。而且，我们要不惜一切代价避免记错东西。

“很好！”你的妻子说，“但是还有个问题你没想到。要是我俩中的一个哪天不能来工作呢？在那天我们就不能一起接受更新的来电了，因为另一个人无法同步这个更新。”

“所以我们会有可用性问题（Availability Problem）！例如，我接到更新来电时就没法完成这个请求，因为即使我在我的本子上记下了，我也没法告诉你。所以我没法完成这个来电！”

第五章：终极解决方案

你有点儿意识到了为什么分布式系统不像你一开始想的那样简单。想出一个既一致又可用的方案很难吗？对其他人也许很难，但对你则不是！第二天早上，你想出了一个你的竞争者们做梦都想不到的解决方法。你再一次急切地叫醒了你妻子。

“看！”你跟她说，“这就是我们既一致又可用的做法，方案与我昨天告诉你的很像：”

  1. 不论我俩谁接到客户要求记东西的电话，打完电话前我们要告诉另一个人，这样我俩都能记下任何的更新。
  2. 但是如果另一个人请假不在，我们给他发一封关于更新的邮件。
  3. 第二天他来工作时，在处理任何来电前先看一遍这些邮件，更新到他的本子上。

“天才啊！”你的妻子说，“这个方案想不到任何的问题。咱们就这样来吧！记忆公司现在既是一致的（Consistent）又是可用的（Available）！"

第六章：妻子的愤怒（分区容忍）

一切都很顺利。你的系统是一致的，当你俩中的一人不能工作时也能运行良好。但是假如你们都来工作了，但是却没把更新告诉另一个人呢？

想想你那些所谓的伟大的点子总是吵醒你妻子。要是哪天她接电话却很生气而不告诉你去更新呢？ 你的方法完全毁了。到目前为止，你的方法是一致而可用的，但却不是分区容忍的（Partition Tolerant）。

网络分区（Partition）在这个故事里比喻为你和妻子之间的通信中断（无论是请假还是生气不沟通）。你可以在与你妻子和好前不接听任何来电，于是你的系统在那段时间又是不可用的了。这意味着为了保证分区容忍性（在通信中断时仍能工作），你可能需要牺牲可用性。

第七章：总结

让我们现在看一下 CAP 理论。它指出：当你设计分布式系统时，你无法同时实现一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）。你只能三者选其二：

  • 一致性（Consistency）：你的客户再次来电时总能查到他们刚来电更新的信息，不论相隔多短。
  • 可用性（Availability）：不论你和你妻子谁来工作，记忆公司总能接听来电，处理客户请求。
  • 分区容忍性（Partition Tolerance）：即便你和你妻子失联（通信中断），记忆公司依然能正常运转。

彩蛋：最终一致性与跑腿员工

这里还有一个思考点。你可以雇一个员工负责当一个本子上内容更新时去更新另一个本子。最大的好处就是，他能在后台工作，你或妻子更新时不用等待另一个完成更新。

这就是许多 NoSQL 数据库系统 的工作方式：一个节点进行本地更新，后台进程将更新内容同步到其他所有节点。唯一的问题是：你将会失去一定时间的一致性。

例如，客户先打给你妻子，在负责更新的员工未完成更新你的本子时，客户打给了你。那么他就无法得到一个一致性的回复。但即便如此，在某些情况下倒也不算是个坏主意。例如，假设一个客户不会忘东西忘得这么快，一般五分钟左右才会再次来电。

这就是给您关于 CAP 理论 和 最终一致性（Eventual Consistency） 的极简解释。

说明：本文基于经典文章翻译整理，旨在通过通俗故事解释分布式系统核心概念。CAP 理论是分布式领域的基石，但在实际工程选型中（如 PACELC 理论），往往需要根据具体场景在延迟与一致性之间做更细致的权衡。