CAP 理论是分布式系统的一个基础理论，它描述了任何一个分布式系统最多只能满足以下三个特性中的两个：
1：一致性（Consistency）
2：可用性（Availability）
3：分区容错性（Partition tolerance）
CAP 理论听起来十分抽象，本文尝试以生活中的例子并用通俗易懂的语言来解释 CAP 理论的含义。
第一章：记忆公司面世
一天晚上，正准备入睡时，你的妻子对你记住她生日并送她礼物表示感谢。这时，一个商业想法从你的脑海中闪现：人们总是弱于记忆生活中的事情，而我却拥有超群的记忆力，因此，为何不成立一间公司可以充分运用自己的记忆天赋来赚钱。说干就干，接着你在当地一间报社刊登了记忆公司的宣传广告：
记忆公司 —— 你的事情永不会忘记
还在为你老是忘记而苦恼？福音来了，只须一个电话。
当你需要记着某件事情时，请拨打 400 - 888 - 8888，告诉我们你需要记住的事情，下次你需要找回这件事情，请再次拨打电话，我们将会告诉你的所需。
收费： 每次只需要 10 元。
以下是一次你和顾客的电话对话。
顾客：Hey，麻烦帮我记住我邻居的生日。
你：好。你邻居生日是什么时候？
顾客：1月2日。
你：（在一个本子，翻到这位顾客的一页，记录下他邻居的生日。）好的，已记录好。下次你找回邻居的生日，请再次拨打电话。
顾客：谢谢。
你：不客气，本次收费 10 元。
第二章：业务扩大了
随着时间的推移，记忆公司的业务发展得越来越好，越来越多的顾客打电话进来需要服务。虽然赚到的钱越来越多，但也产生了一个新的问题。 顾客打电话进来时，需要等待的时间越来越多，另外，当你生病时，所有顾客都不能获得服务，这令人很是烦恼。
于是，你想出了一个新的计划：你和你的妻子同时接收顾客的电话，顾客仍然只需要记着一个公司的服务电话 400 - 888 - 8888，一个路由器会将顾客的电话分发到你和妻子电话上
第三章：服务出错了
新计划实施两天后，你接到了一个名叫 John 的电话，John 是个老顾客了。
John：Hey
你：你好，欢迎拨打记忆公司电话，有什么可以帮到你吗
John：可以告诉我去新泽西的航班是什么时候吗
你：当然。（然后你翻开 John 的页面，发现并没有 John 航班的记录）
你：你好，是不是搞错了，我们这里并没有关于你航班的信息
John：什么？！昨天我才刚打电话过来说去新泽西航班的事情
哪里出错了？难道 John 撒谎了。你继续思考导致出错的原因。会不会是妻子接到了电话？你走到妻子的桌子，发现妻子将 John 的航班记录在了本子上，这时你才意识到导致问题的原因，妻子接听到 John 的电话，但你的本子没有 John 的记录。
如果将上面的实施计划称一个分布式的设计，那这个设计存在明显的问题——一致性（consistent）的问题。打进来的电话可能其中一人接听并记录下来，下次电话查询时却可能由另一人接听，这样就会出现不一致的问题，无法为顾客准确提供服务。
第四章：解决一致性问题
晚上你在床上翻来覆去，最后想到一个解决一致性问题的办法，你把新的计划告诉妻子：
每次接收记录的电话（顾客要求帮忙记住他们的事情）时，我们同时告知另一个人
这样，我们两个人都会在本子更新这位顾客的记录
下次这位顾客再次打电话进来查询，这时我们不需要告知对方，因为两个本子都有这位顾客的记录了
这个方法只有一个问题，你告诉妻子，当有顾客需要记录时，我们不能并行地工作。例如，你接收到记录的电话并这个信息告知我，这时我就不能再接听其他顾客的电话了。但这个问题基本上也是可以接受的，因为大部分顾客的电话都是查询的。
老公你真聪明，妻子称赞你，但这个设计还有一个问题。如果某天我们其中一个人有事不能工作了怎么办？由于我们要求每次接到记录电话需要同时更新两个本子，这就导致我们不能为顾客提供记录的服务，这样就导致无法满足 可用性（availability）的要求。例如，当我接到一个记录的电话时，而你恰好不在，这样我就无法完成这个顾客的服务。这是由于我无法要求你更新你的本子。
第五章：更好的办法
这时你才意识到，设计一个分布式的系统是多么的不容易，难道就没有同时满足 一致性和可用性 的设计吗？
又经过一晚的思考，你想到一个两全其美的办法，新的办法跟之前的很相似。你把新的办法告诉妻子：
当接到记录的电话（顾客要求为他们记录事情），如果我们两人当天都上班，那么我们同时记录下这位顾客的记录
但如果另一人当天没上班，我们可以将记录通过 E-mail 的方式发送给不上班的人
第二天，没上班的人上班后第一件事就是接收所有的 E-mail ，并在自己的本子上记录所有顾客的要求。记录好后，才开始接收第一个电话。
真是天才，妻子说，这个办法我找不出任何问题了，而且可以同时满足 一致性和可用性 的要求。
第六章：妻子生气了
公司所有业务继续正常运作了好一段时间，即使你和妻子其中一人不上班，服务仍然可以正常提供。
好景不长，新的问题又出现了。
一天，妻子由于某件小事对你很是生气，以至于她接到一位顾客需要记录的电话并没告知你。由于记录没能在两个本子更新，你的设计完全被打破了。你的设计建立在两人良好沟通的前提下，如果出现沟通无法进行的情况，系统就出现问题了。也就是说，你的设计没有达到 分区容忍性（partition tolerant）的要求。
当然，你也可以允许沟通无法进行的情况下继续提供服务。这样，当有顾客需要记录时，由于需要满足 一致性 要求，这位顾客的服务就无法完成，也就是 可用性 无法满足。。。
第七章：结论
让我们再次回到 CAP 理论，CAP 理论告诉我们，当设计一个分布式系统时，我们无法同时满足 一致性，可用性，分区容忍性 的要求，我们最多满足其中的两个要求，形式化的证明，可以参考 CAP 理论的证明 。
一致性：一旦顾客更新了记录，下次再打电话查询时，总能获取最新的记录
可用性：只要你和妻子有人上班，记忆公司总能为顾客提供服务
分区容忍性：即使你和妻子的沟通无法进行，记忆公司仍然可以提供服务
番外篇：背后的记录员
上面设计的系统仍然有优化的空间。记忆公司可以雇佣一个记录员，当你和妻子其中一人接到顾客的记录电话时，记录员在背后会将这个记录写在另一个人的本子上。这样一来，另一个人的服务就不会被这个记录的电话打断。许多 NoSQL 系统就使用了这个方法，一个节点更新了数据，背后会有一个进程将数据同步到其他节点。
这种设计存在的问题是可能在短时间内丢失一致性。例如，顾客打电话进来要求记录，妻子接听到这个电话。紧接着，这位顾客再次打电话进来要求查询，你接听到这个查询的电话。如果记录员还没将这位顾客的记录更新到你的本子，这时顾客就没法正常查询。虽然存在这种可能性，但你也不用过分担心，因为顾客很少会打完记录电话后马上又打查询电话，所以出现本子内容不一致的概率很低。
原文发布时间为：2018-09-21
原文作者：haozlee
