在做分布式系统开发时,我们经常会或多或少的听到CAP理论、或者是处理节点间数据一致性的问题。
但CAP理论究竟是什么呢?
CAP理论很简单,但却是很多软件设计的宏观指导,因此也有人将之称为架构师必须掌握的理论之一。
鉴于理论的东西相对来说比较抽象而且繁琐,因此我们先举个例子:
有一天你打王者荣耀连跪,于是找了一个大神鲁班,带你起飞:
于是就发生了下边的对话
---------------------------------------------------------------
(1)
射手鲁班:救救我,谢谢
辅助蔡文姬:收到
(2)
辅助蔡文姬:我来抓人了
射手鲁班:收到
如果一切良好,那么一切都OK
但是假若这时候YY语音突然挂掉了
---------------------------------------------------------------
(1)射手鲁班:救救我,谢谢
蔡文姬,没有响应
(2)辅助蔡文姬:我来抓人了
射手鲁班,没有响应
---------------------------------------------------------------
那么接下来有两种策略:
1、 暂时先不管YY语音的问题,继续打好游戏。
2、先不打游戏了,切屏打电话给对方,看下是不是发生了什么状况
是的,这涉及到所谓的CAP理论了,
也就是在分布式场景下,如果不同节点之间的通信出现了问题,那么不同节点的响应策略应该是什么样的。是该暂停响应,等待连接恢复,还是应该坚持响应,忽略数据的不一致性。
我们先来看下计算机领域中,CAP的专业解释:
一致性 Consistency:在分布式系统中,所有的数据备份,在任意时刻都要求一致;
可用性 Availability:对于分布式系统中的节点,在任意时候都可以正常的进行读写响应,并且不超时;
分区容错性 Partition tolerance:当节点之间的通信出现(防盗连接:本文首发自http://www.cnblogs.com/jilodream/ )故障时,整个分布式系统仍然可以运行起来,不至于直接崩溃掉;
P是背景,也就是在分布式系统下,如果节点之间的通信出现了问题,那么整个系统仍然在运行,等待网络恢复后,整个系统仍然可以正常操作。
经过理论以及实际的推演,我们发现在P的背景下,AC不可以共存。
也就是你无法做到既保证了节点的可用性,还保证了一致性。
专业的推演证明,这里就不说了,笔者自己的理解是这样的:
当节点之间的网络崩溃时,节点如果想要能够支持可用性,势必会造成数据的修改,从而造成数据的不一致,而网络又崩溃掉,因此没有办法进行节点间的数据同步。现在对于接下来的处理策略有两个选择:
(1)如果节点想要支持一致性呢,那么唯一的选择就是不能进行数据的写,这是因为节点之间无法进行数据的同步,因此只能放弃写操作,这就导致失去了高可用性。
(2)如果支持了写,那么就会出现节点间的数据不一致,并且由于网络问题,无法及时同步,这就失去了高一直性。
这套理论有什么用呢?
他可以明确指出,对于分布式系统来说,无法做出数据完美一直,而且有高可用的场景。架构设计必须要做出取舍。
1、遵从可用性,放弃高一致性
2、支持高一直性,放弃高可用性
具体应该如何选择,由业务来决定。如果你的系统支持短暂的业务停顿,但是系统不能出错,那么就要倾向于CP方案,如实时通话系统,财务交易系统。如果你的系统支持暂时的数据不一致性,但是一定要保证高可用性,如直播点赞,评论。那么就要倾向于AP方案。无所谓哪种方案更优秀,而是需要由业务来驱动技术的选型。
很多人说,不是CAP,三者取其二么?为什么你这里只有CP,和AP?
这两种理解其实都可以,但是(注意,要画重点了)
P所代表的是分区容忍性,是指分布式场景下,对于网络通信问题下仍然可用,这个是前提。
CP和AP是基于这个前提讨论的两种方案。如果划掉P,取AC,也就是单机场景下的一致性和可用性(防盗连接:本文首发自http://www.cnblogs.com/jilodream/ )问题,这就失去了讨论的意义。这好比在中学物理中R=U/I ,电阻等于电压除以电流。但是你不能理解为电阻与电压成正比,与电流成反比,因为电阻只与材料和规格相关。你可以按照公式推算出数据,但是不代表是字面的含义。
另外需要注意的是,上述情况下,都是理论模型,其中忽略了数据一致性所需要的网络延迟。也就是说,在实际情况中,由于网络的延时问题,高效的CP系统非常难实现。同时又由于互联网产品中本身需要的快速响应,所以在实际的开发中,往往AP模式的设计,相对来说占比会更大一点。那么如何规避掉数据不一致性造成的影响呢?
这里提供两个思路
1、 数据的最终一致性,出现一致性问题没关系,只要不影响到核心的数据计算,是可以接受的。只要最终的数据能够保证一致性,满足幂等性即可。
2、 缩短数据一致性恢复的时间,也就是如果出现数据不一致的问题,系统可以想办法缩短恢复数据的耗时,如果当请求再次进来时,如果数据已经恢复完成,那么对于外界来说,就不会感知到此次的不一致。