CAP 理论 —最通俗易懂的解释

  1. 云栖社区>
  2. 博客>
  3. 正文

CAP 理论 —最通俗易懂的解释

技术小能手 2018-09-25 10:46:45 浏览1329
展开阅读全文

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

本文来自云栖社区合作伙伴“Python专栏”,了解相关信息可以关注“Python专栏”。

网友评论

登录后评论
0/500
评论
技术小能手
+ 关注