你的位置:首页 > 软件开发 > ASP.net > 关于CAP定理的个人理解

关于CAP定理的个人理解

发布时间:2015-04-02 00:00:18
CAP定理简介在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewers theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:一致性(Consistency):同一个数据在集群中的所有节点,同一时刻是否都是同样的值。可用 ...

CAP定理简介

在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:

  1. 一致性(Consistency):同一个数据在集群中的所有节点,同一时刻是否都是同样的值。
  2. 可用性(Availability):集群中一部分节点故障后,集群整体是否还能处理客户端的更新请求。
  3. 分区容忍性(Partition tolerance):是否允许数据的分区,分区的意思是指是否允许集群中的节点之间无法通信。

我的个人理解

我觉得,理解CAP可以从两个阶段去考虑。

只考虑CP

如果我们只考虑CP,我发现很有意思。因为此时,我们就是关注,当可能存在A,B两个节点网络不通的情况下,能否做到A,B两个节点之间的数据在任何时刻总是一致的。

我认为是不行的。因为:假如一开始A,B两个节点之间是连通的,然后一个数据写入请求过来,由于是分布式的,我们无法做到A,B同时写入。所以,不管是哪个先写入,当一个先写入后,假设此时网络突然断开了,那另一个节点就不会自动写入。从而最终导致A,B的数据不一致。大家想想是不是这样呢?

把A也考虑进来

上面,我们讨论了,在不关注A的时候,我们已经无法绝对保证A,B两个节点之间的数据在任何时刻都是一致的了。那如果再考虑A,也就是CAP同时考虑,那不是更加不可能同时做到了?如果我们此时,希望系统继续可用,那就要让用户看到这种不一致,即牺牲了C(其实不能说牺牲,因为C我们上面分析过,一定是做不到的(已经牺牲了!)。所以,应该说选择了向用户暴露这种不一致)。如果我们不允许系统继续写入或被读取,那就是牺牲了A,此时相当于:数据不一致了,且同时系统不可用了;

用户想要的一致性是什么?

难道我们集群中,某些节点挂了后,就不能继续为用户提供服务了吗?不是的。因为有NRW算法的存在。

我们想一下,用户关心集群中节点的数据一致性吗?不关心!那用户关心什么?用户关心的是,我只要写入数据成功了,那我下次读取该数据时,总是能读取到最新写入的数据。所以,只要我们的数据库做到了这一点,那数据库里的数据对于用户而言,就是具有一致性的。注意:这里的一致性是针对用户而言的,不是CAP定理中的数据副本之间的一致性概念。

那要做到这种一致性,要怎么做呢?答案就是NRW算法。

NRW算法

假设总共有五个节点(N),我们只要保证写入数据的节点数(W)+ 读取数据的节点数(R)大于总节点数即可。即保证W+R>N,那就能保证对客户端而言,总是能读取到它最新写入的数据。比如,总节点数为5,写入节点数为3,读取节点数为3,那我们就能保证客户端总是能读取到它最新写入的数据。有了这样的数据公式的作为理论保证。我们就可以根据情况灵活选择W,R了。由于我们不需要保证5台机器全部都写入成功,只需要保证3台写入成功即可。这就意味着,我们允许5台机器中的2台出现问题,也就是提高了系统的可用性。这样的设计,虽然集群节点之间,也许有些节点的数据不是最新的,也就是没有做到CAP中的C,但对用户来说,数据总是一致的。

所以,有了NRW算法,我们就能做到,在满足AP的前提下,我们完全还可以做到对用户而言的数据一致性。


原标题:关于CAP定理的个人理解

关键词:

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。

可能感兴趣文章

我的浏览记录