-
C: Consistency一致性
-
A: Availability可用性
-
P: Partition-tolerance分区可容忍性
一、首先CAP理论是普遍被当作是大数据技术的理论基础。

二、三种不可忽视的CAP场景
(1)分布式系统中多个数据副本之间的读写一致性问题
数据在节点A、B、C上保留了三份,如果对节点A上的数据进行了修改,然后再让客户端通过网络对该数据进行读取。那么,客户端的读取操作什么时候返回呢?有这样两种情况:一种情况是要求节点A、B、C的三份数据完全一致后返回。也就是说,这时从任何一个网络节点读取的数据都是一样的,这就是所谓的强一致性读。很明显,这时数据读取的Latency要高一些(因为要等数据在网络中的复制),同时A、B、C三个节点中任何一个宕机,都会导致数据不可用。也就是说,要保证强一致性,网络中的副本越多,数据的可用性就越差;另一种情况是,允许读操作立即返回,容忍B节点的读取与A节点的读取不一致的情况发生。这样一来,可用性显然得到了提高,网络中的副本也可以多一些,唯一得不到保证的是数据一致性。当然,对写操作同样也有多个节点一致性的情况,在此不再赘述。
(2)分布式系统系统的分布式事物问题
分布式事务一般采用两阶段提交策略来实现,这是一个非常耗时的复杂过程,会严重影响系统效率,在实践中我们尽量避免使用它。在实践过程中,如果我们为了扩展数据容量将数据分布式存储,而事务的要求又完全不能降低。那么,系统的可用性一定会大大降低,在现实中我们一般都采用对这些数据不分散存储的策略。关系型数据库,因为这个原因,扩展性(分区可容忍性P)受到了限制,这是完全符合CAP理论的。对NoSQL数据库也是一样的。如果NoSQL数据库也要求严格的分布式事务功能,情况并不会比关系型数据库好多少。只是在NoSQL的设计中,我们往往会弱化甚至去除事务的功能,该问题才表现得不那么明显而已。在扩展性问题上,如果要说关系型数据库是为了保证C、A而牺牲P,在尽量避免分布式事务这一点上来看,应该是正确的。也就是说:关系型数据库应该具有强大的事务功能,如果分区扩展,可用性就会降低;而NoSQL数据库干脆弱化甚至去除了事务功能,因此,分区的可扩展性就大大增加了。
(3)分布式环境中的关联场景
初看起来,关系型数据库中常用的多表关联操作与CAP理论就更加不沾边了。但仔细考虑,也可以用它来解释数据库分区扩展对关联所带来的影响。对一个数据库来讲,采用了分区扩展策略来扩充容量,数据分散存储了,很显然多表关联的性能就会下降,因为我们必须在网络上进行大量的数据迁移操作,这与CAP理论中数据副本之间的同步操作本质上也是相同的。而NoSQL数据库则干脆在设计上弱化甚至去除了多表关联操作。那么,从这一点上来理解“NoSQL数据库是为了保证A与P,而牺牲C”的说法,也是可以讲得通的。当然,我们应该理解,关联问题在很多情况下不是并行处理的优点所在,这在很大程度上与Amdahl定律相符合。
三、总结
现在看来,如果理解CAP理论只是指多个数据副本之间读写一致性的问题,那么它对关系型数据库与NoSQL数据库来讲是完全一样的,它只是运行在分布式环境中的数据管理设施在设计读写一致性问题时需要遵循的一个原则而已,却并不是NoSQL数据库具有优秀的水平可扩展性的真正原因。而如果将CAP理论中的一致性C理解为读写一致性、事务与关联操作的综合,则可以认为关系型数据库选择了C与A,而NoSQL数据库则全都是选择了A与P,但并没有选择C与P的情况存在。这才是用CAP理论来支持NoSQL数据库设计正确认识。这种认识正好与被广泛认同的NoSQL的另一个理论基础相吻合,即与ACID对着干的BASE(基本可用性、软状态与最终一致性)。因为BASE的含义正好是指“NoSQL数据库设计可以通过牺牲一定的数据一致性和容错性来换取高性能的保持甚至提高”,即NoSQL数据库都应该是牺牲C来换取P,而不是牺牲A。可用性A正好是所有NoSQL数据库都普遍追求的特性。
摘自原文:http://www.jdon.com/bigdata/how-to-understand-cap.html
理解参考:https://www.cnblogs.com/shanyou/archive/2012/06/11/2545536.html
网友评论