本文转载自微信公众号《全栈码农画像》，作者小马甲。转载本文请联系全栈码农画像公众号。你可能经常听到CAP定理，它描述了设计分布式系统时的自然约束。和其他文章一样，这篇文章也是通过真实场景来对比理解CAP定理。1.记忆公司昨晚你老婆过生日。你这个没心没肺的男人，竟然想起了精心准备的生日礼物。夫妻俩相视一笑。你脑子里冒出一个绝妙的主意：既然人的记性一般都不好，而我的记性还不错，不如凭着我的记性创业。马上行动，你制作了【RemembranceInc】的开篇广告：RemembranceInc！-永远不要忘记，即使不记得！你有没有因为忘记这么多而感到难过？不用担心。只需一个电话即可获得帮助！当您需要记住一些事情时，只需拨打555—55-REMEM并告诉我们您需要记住什么。例如，打电话给我们并告诉我们您老板的电话号码，而忘记记住它。当您需要知道时..回拨相同的号码[(555)—55-REMEM]我们会告诉您您老板的电话号码是多少。收费：每次请求只需0.1记住公司的日常业务通话记录：客户:你好，你可以存储Isitmyneighbor'sbirthday?你：是的，你说。客户：1月2日你：记录（记下笔记本客户页的信息），好的，欢迎下次来电咨询。顾客：谢谢你：请付1元2.业务拓展凭着创意和品格，[MemoryCompany]越做越大，成本只是一台笔记本和一部手机。当你生病不能工作一天时，你会损失一天的收入；更不用说那天想要信息的疯狂客户了。您有一个新的计划：1.您和您的妻子分别使用分机2.(555)—55-REMEM客户服务号码保持不变3.客户服务电话将转移到空闲的分机号码3.第一次业务停机将有一天，你接到老客户罗志祥的电话，询问“明天的预约安排”；你一头雾水，我不知道，你的记忆页上没有这样的信息；客户砰的一声挂断了电话。在当天的回放中，我猜测罗志祥昨天打电话给我老婆有事，果然如此。你们都知道扩展带来的新问题。分布式设计中的一个多么可怕的缺陷！你的分布式系统不一致！总会有客户向你们中的一个人打商务电话的时候；下次客户拨号时，客户可能会收到不一致的信息。4.解决一致性问题睡前，你有一个想法：当我们中的一个人从客户那里得到一个新的记忆订单时，我们在挂断电话之前告诉另一个人，这样我们都可以在笔记本上记下新订单当客户询问时，我们俩都能轻松搞定。问题是：当我们中的一个人接到一个新的业务电话时，我们两个人无法并行工作。例子：当你接到新业务时，让我记录信息，我不能接其他电话。不过这个问题也不算太大，因为大部分都是查询服务（你可以再打电话试试），我们的首要任务是保证信息的正确性。你老婆进一步提出：如果有一天你不上班，我接到一个新业务，你的笔记本电脑无法获取最新信息，这会导致可用性问题，因为我无法挂断电话来完成这个业务，因为我未能通知您。5.更好的解决方案你逐渐理解了分布式系统中的“一致性”和“可用性”。你提出了一个更好的解决方案：1、接到新的业务电话时，在挂断前通知对方，让双方都记下信息。发送邮件3.第二天，空缺的人会去上班查看他们的电子邮件并更新他们的笔记本。很好，现在一致性和可用性都满足了。6.老婆难养。使用优化的解决方案，一切顺利。你们的笔记本也是一样的，即使你们中的一个人不值班，系统也能很好地工作。然而，凡事都有but。有一天你们都在值班，但是你老婆嫌你碗没洗干净，所以今天不想跟你说话，接到新业务也不通知你。你的询盘业务有问题。你的方案包括“一致性”和“可用性”，但不满足“分区容错”。为了满足“分区容错”，你可以自己下线（直到修复关系），让你老婆一个人接管业务，但是你的系统就不能用了。7.结论让我们回顾一下CAP定理：在设计分布式系统时，只能满足“一致性”、“可用性”和“分区容忍度”中的两个。?一致性：一旦接受了客户的新业务，客户后续询价时必须获取最新的信息？可用性：只要你们中的一个人在工作，内存公司就会继续提供服务吗？PartitionTolerance:如果你们夫妻有矛盾，内存公司还会有这样的场景在运营，不难理解CP,AP,CA雇用工具人-->finalconsistency雇用工具人来更新笔记本的【未更新的人】，比起你老婆实时通知你更新，这个工具人的一大优势是他在后台跑腿，你们的业务都不会被屏蔽。这也是很多NoSql的工作原理：一个节点在本地更新，后台进程同步到其他节点。唯一的问题是它有几次失去了一致性。你老婆接到新业务，还没来得及办事，客户立马回拨你的分机，你的回答前后矛盾。这是有限的，因为客户不会那么快忘记事情。这是对CAP定理和最终一致性的现实解释。
