趣谈分布式CAP定理,值得一看

内容目录

开篇

CAP定理也称作布鲁尔定理,它的提出是针对分布式系统,不能同时满足一下三点

一致性(Consistency):所有节点访问最新的数据副本

可用性(Availability):每次请求都能获取到正确的响应,但是不保证获取到的数据为最新数据

分区容错性(Partition tolerence):分区相当于通信时限的要求。如果系统不能在一定时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

以上是维基百科对CAP的解释。

但是有一个非常有意思的文章,阐述了CAP定理。

你可能经常听到CAP定理,它定义了分布式系统的某种上限。我们用现实世界的场景来理解一下CAP定理。

第一章:你成立了一个新公司“记事帮科技有限公司”

这公司干嘛的?假设你昨晚上想起了你媳妇的生日,并且想到送你媳妇生日礼物,这时候,你想起了一个金点子。记事对人来讲太难啦。但是你很擅长记事。所以为什么不利用这个需求和自己的天赋来创办一个公司,公司名就叫:记事帮科技有限公司。你越想越觉得有意思,所以你写了一个PPT,来宣传你的公司。内容如下:

记事帮科技有限公司!-不需要记忆,我们不会让你忘记!

你是否感觉你经常忘记事情?不要慌,只需要一通电话,我们就帮你搞定。

当你需要记住事情的时候,只需要拨打我们的电话:555-55-记事 (你可以尝试拨打一下),并告诉我们你想记住啥(非法乱纪,黄赌毒不行哈)。例如:打电话告诉你老板的电话,然后你就可以把老板的电话删了。当你需要知道你老板电话的时候,只需要拨打555-55-记事,那么我们就会告诉你老板的电话。

我们的收费也超级划算:一块钱一条。

所以,你和客户典型通话的场景是:

用户:喂,你可以记一下我邻居的生日吗?(不会是隔壁老王吧)

你:当然,你邻居生日多少哇?

用户:一月2号

你:(你把这个内容写到你的记事本里面),告诉用户,需要知道随时给我们打电话

用户:QQQ

你:给钱呀!谢谢可不值1块钱。

第二章:记事帮科技有限公司业务扩展

你公司运营的不错,很快火了。你每天收到成百上千个电话。

但是同时也遇到问题了。你一个人应付不了那么多人,用户在电话那头已经等的花儿都谢了。同时如果某天你病了,或者有事不能上班,那这些用户和钱都没了。这时候你想到是时候招一个小弟来了,但是出于成本考虑,还是找到你媳妇。

计划是这样:

你和你媳妇人手一个电话(电话从1个扩展到了2个)

用户还是打555-55-记事这个号码

pbx会将用户的呼叫请求路由到空闲的电话上

第三章:第一次没有给用户查出数据

两天后你实现了这个新系统,你收到了一个老客户的来电,通话内容如下:

客户:哈喽

你:欢迎,我能帮你干点啥

客户:你能告诉我,我什么时候飞上海吗?

你:当然,我查查

你找了一个你的记事本,发现没有这个娃子的记录

你:额,你有没有搞错,你没让我记过你的航班哇

客户:我昨天刚花一块钱记得,你们公司什么鬼,店大欺客,然后电话挂断

发生了啥?为啥没有查到?这个客户真的弄错了吗?你想了一会,然后想到了原因。这娃子电话是不是大道你媳妇哪儿去了?你去你媳妇的办公位,然后查了一下她的记事本。果然,这个娃子的记录在她哪儿。

你的分布式系统留了一个大BUG。你的分布式系统没有处理一致性。同时,如果用户来电更新他的记录,第一次来电路由到你,第二次来电路由到你媳妇,那么两次更新是不一致的。

第四章:你解决了一致性问题

你的竞争对手可能忽视了这个问题,但是你不能忽视。晚上你躺在床上想这个问题,然后早上的时候想到了一个完美的解决方案。

用户让我们记住一个东西的时候,在用户挂断电话之前,我们互相告知并记录一下

这样我们都记住这个东西

当有用户电话问的时候,这样我们就不用互相查找了,因为我们各自都有一份最新的数据。

这样就只有一个问题,当有用户来向我们更新数据的时候都会牵扯到我们两个,在这期间,我们没有办法并行处理其他事情。例如:当你有更新的时候,我也得更新,这样我就不能接电话了。但是这样也还可以接受,因为我们接到的大部分电话是查询的,而且我们不能给用户提供错误的数据。

但是还有个问题,当我们两个其中之一在某一天不上班怎么办?这样的话,那天我们就不能记任何东西,因为另一个人不能记。我们遇到了可用性问题。例如:如果我们这收到了一个更新请求,即使我可以在我们这儿更新,但是我也无法完成这个更新请求,因为你不在,我没有办法更新你的记事本。所以,这个电话打不完了(除非等到你到岗)。

第五章:你建立了公司以来最好的方案

你开始意识到了,分布式系统不向你刚开始想的那样简单。要实现一个一致性和可用性的系统那么难吗?对别人可能很难,但是对你来讲,毛毛雨啦。然后第二天早上,你想到了一个你竞争对手都想不到的方案。你把你媳妇叫醒:我们可以这样来解决一致性和可用性,方案和昨天的类似:

当我们任何一个人得到一个更新请求时,在挂断电话之前,如果另一个人在就告诉另一个人,这样我们都可以记录下来

如果另一个人不在,我们给另一个人发送一封邮件(邮件内容就是数据更新)

第二天当那个人来上班的时候,他先浏览邮件,根据邮件内容更新笔记本,更新完成后,再接听电话

你老婆肯定会说你真是天才(聪明绝顶–地中海)。现在你公司的分布式系统具备了一致性和可用性,哇哦!

第六章:你和你媳妇吵架啦

一段时间内这个系统运行的很好。你的系统是具备一致性的。在有一个人不上班的时候也很好。但是如果你和你媳妇两个人都在上班,其中一个人没有能更新另一人的笔记本会怎么样?想想你最近总是一大早把你媳妇弄醒,并跟她BB你的想法和设计,没睡好容易发火哟。如果你媳妇很生气,接了电话记下来了,故意不同步给你会咋样?你的方案就不满足了。目前为止你的方案在一致性和可用性方面做的很好,但是却不是分区容忍的。

当然你可以做成分区容忍的,只要你在平息了你媳妇的怒火之后再去接电话(这样,你媳妇才会把更新同步给你)。但是,在这期间,你们两个都不在工作,所以你的系统在这段时间是不可用的。

第七章:总结

所以,我们来看下CAP定理。当你要设计分布式系统的时候,你无法完成这三点:一致性,可用性和分区容忍性,你可以选择其中的两个:

一致性:一旦你的用户让你更新数据。随后,不管用户在更新数据后多快打电话查询,那么用户应该拿到他最新的数据

可用性:你或者你媳妇的一人或者两个人在上班的时候,你的系统是可用的

分区容忍性:当你和你媳妇之间没有任何联系,你公司也可以对外提供服务

发表评论

您的电子邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部