如何正确理解CAP理论?

2018-03-19 01:49

 在大数据领域,被业界广泛谈及的CAP理论存在着一些关键性的认知误区,而只有全面地考察与分析分布式环境中的各种场景,我们才能真正正确地理解它。

  目前,CAP(Consistency一致性、Availability可用性、Partition-tolerance分区可容忍性)理论普遍被当作是大数据技术的理论基础。同时,根据该理论,业界有一种非常流行、非常“专业”的认识,那就是:关系型数据库设计选择了C(一致性)与A(可用性),NoSQL数据库设计则不同。其中,HBase选择了C(一致性)与P(分区可容忍性),Cassandra选择了A(可用性)与P(分区可容忍性)。

  该说法现在似乎已经成为一种经典认知,无论是初学大数据技术,还是已经有了相当经验的技术人员,都将其奉为真理。大家大概是认为,从CAP这样著名的理论推导出来的结论,当然是权威而又正确的,最起码在形式上感觉是专业而又严肃的。有人甚至还将这种认知画成一个三角形图,三个顶点分别是C、A、P,三条边分别是关系型数据库、HBase与Cassandra,这样一来,CAP理论就显然更加神圣了。

  实际上,这种认识是不准确的,甚至是不正确的。暂且不说深入的分析与研究,只要先从表面上简单分析一下,你就能发现问题:难道说从理论上讲Cassandra就一定比HBase的可用性更高吗?而要要彻底搞清楚这个问题,还得先从CAP理论本身开始研究。

常见的理解及分析

  目前流行的、对CAP理论解释的情形是从同一数据在网络环境中的多个副本出发的。为了保证数据不会丢失,在企业级的数据管理方案中,一般必须考虑数据的冗余存储问题,而这应该是通过在网络上的其他独立物理存储节点上保留另一份、或多份数据副本来实现的(如附图所示)。因为在同一个存储节点上的数据冗余明显不能解决单点故障问题,这与通过多节点集群来提供更好的计算可用性的道理是相同的。

如何正确理解CAP理论?



附图 CAP理论示意图

  其实,不用做严格的证明也可以想见,如附图的情况,数据在节点A、B、C上保留了三份,如果对节点A上的数据进行了修改,然后再让客户端通过网络对该数据进行读取。那么,客户端的读取操作什么时候返回呢?

  有这样两种情况:一种情况是要求节点A、B、C的三份数据完全一致后返回。也就是说,这时从任何一个网络节点读取的数据都是一样的,这就是所谓的强一致性读。很明显,这时数据读取的Latency要高一些(因为要等数据在网络中的复制),同时A、B、C三个节点中任何一个宕机,都会导致数据不可用。也就是说,要保证强一致性,网络中的副本越多,数据的可用性就越差;

  另一种情况是,允许读操作立即返回,容忍B节点的读取与A节点的读取不一致的情况发生。这样一来,可用性显然得到了提高,网络中的副本也可以多一些,唯一得不到保证的是数据一致性。当然,对写操作同样也有多个节点一致性的情况,在此不再赘述。

  可以看出,上述对CAP理论的解释主要是从网络上多个节点之间的读写一致性出发考虑问题的。而这一点,对于关系型数据库意味着什么呢?当然主要是指通常所说的Standby(关于分布式事务,涉及到更多考虑,随后讨论)情况。对此,在实践中我们大多已经采取了弱一致性的异步延时同步方案,以提高可用性。这种情况并不存在关系型数据库为保证C、A而放弃P的情况;而对海量数据管理的需求,关系型数据库扩展过程中所遇到的性能瓶颈,似乎也并不是CAP理论中所描述的那种原因造成的。那么,上述流行的说法中所描述的关系型数据库为保证C、A而牺牲P到底是在指什么呢?

  因此,如果根据现有的大多数资料对CAP理论的如上解释,即只将其当作分布式系统中多个数据副本之间的读写一致性问题的通用理论对待,那么就可以得出结论:CAP既适用于NoSQL数据库,也适用于关系型数据库。它是NoSQL数据库、关系型数据库,乃至一切分布式系统在设计数据多个副本之间读写一致性问题时需要遵循的共同原则。

更深入的探究:两种重要的分布式场景

  在本文中我们要说的重点与核心是:关于对CAP理论中一致性C的理解,除了上述数据副本之间的读写一致性以外,分布式环境中还有两种非常重要的场景,如果不对它们进行认识与讨论,就永远无法全面地理解CAP,当然也就无法根据CAP做出正确的解释。但可惜的是,目前为止却很少有人提及这两种场景:那就是事务与关联。