CAP原则(CAP定理)

  CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

  CAP原则是NOSQL数据库的基石。Consistency(一致性)。 Availability(可用性)。Partition tolerance(分区容错性)。

分布式系统的CAP理论:理论首先把分布式系统中的三个特性进行了如下归纳:

  • 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
  • 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
  • 分区容忍性(P):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

一致性与可用性的决择编辑

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。

对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地

  1. 数据库事务一致性需求 
      很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求并不高。允许实现最终一致性。
  2. 数据库的写实时性和读实时性需求
      对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说发一条消息之 后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。
  3. 对复杂的SQL查询,特别是多表关联查询的需求 
      任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的报表查询,特别是SNS类型的网站,从需求以及产品设计角 度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

与NoSQL的关系编辑

传统的关系型数据库在功能支持上通常很宽泛,从简单的键值查询,到复杂的多表联合查询再到事务机制的支持。而与之不同的是,NoSQL系统通常注重性能和扩展性,而非事务机制(事务就是强一致性的体现)[2]  。
  传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性,即在事务中执行多个操作是原子性的,要么事务中的操作全部执行,要么一个都不执行;C代表一致性,即保证进行事务的过程中整个数据加的状态是一致的,不会出现数据花掉的情况;I代表隔离性,即两个事务不会相互影响,覆盖彼此数据等;D表示持久化,即事务一量完成,那么数据应该是被写到安全的,持久化存储的设备上(比如磁盘)。
  NoSQL系统仅提供对行级别的原子性保证,也就是说同时对同一个Key下的数据进行的两个操作,在实际执行的时候是会串行的执行,保证了每一个Key-Value对不会被破坏。

CAP的是什么关系

It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time.
在分布式系统的设计中,没有一种设计可以同时满足一致性,可用性,分区容错性 3个特性

注意:不要将弱一致性,最终一致性放到CAP理论里混为一谈(混淆概念的坑真多)
弱一致性,最终一致性 你可以认为和CAP的C一点关系也没有,因为CAP的C是更新操作完成后,任何节点看到的数据完全一致, 弱一致性。最终一致性本身和CAP的C一致性是违背的,所以你可以看到那些谎称自己系统同时具备CAP 3个特性是多么的可笑,可能国内更多的场景是:一个开放人员一旦走上讲台演讲,就立马转变为了营销人员,连最基本的理念也不要了
这里有一篇标题很大的文章  cap-twelve-years-later-how-the-rules-have-changed ,实际上本文的changed更多的是在思考方式上,而本身CAP理论是没有changed的

为什么会是这样

我们来看一个简单的问题, 一个DB服务   搭建在两个机房(北京,广州),两个DB实例同时提供写入和读取

1. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功
      在没有出现网络故障的时候,满足CA原则,C 即我的任何一个写入,更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致, A 即我的读写操作都能够成功,但是当出现网络故障时,我不能同时保证CA,即P条件无法满足

2. 假设DB的更新操作是只写本地机房成功就返回,通过binlog/oplog回放方式同步至侧边机房
      这种操作保证了在出现网络故障时,双边机房都是可以提供服务的,且读写操作都能成功,意味着他满足了AP ,但是它不满足C,因为更新操作返回成功后,双边机房的DB看到的数据会存在短暂不一致,且在网络故障时,不一致的时间差会很大(仅能保证最终一致性)

3. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功且网络故障时提供降级服务
      降级服务,如停止写入,只提供读取功能,这样能保证数据是一致的,且网络故障时能提供服务,满足CP原则,但是他无法满足可用性原则

选择权衡

通过上面的例子,我们得知,我们永远无法同时得到CAP这3个特性,那么我们怎么来权衡选择呢?
选择的关键点取决于业务场景

对于大多数互联网应用来说(如网易门户),因为机器数量庞大,部署节点分散,网络故障是常态,可用性是必须需要保证的,所以只有设置一致性来保证服务的AP,通常常见的高可用服务吹嘘5个9 6个9服务SLA稳定性就本都是放弃C选择AP

对于需要确保强一致性的场景,如银行,通常会权衡CA和CP模型,CA模型网络故障时完全不可用,CP模型具备部分可用性,实际的选择需要通过业务场景来权衡(并不是所有情况CP都好于CA,只能查看信息不能更新信息有时候从产品层面还不如直接拒绝服务)

延伸

BASE(Basically Available, Soft State, Eventual Consistency  基本可用、软状态、最终一致性) 对CAP AP理论的延伸, Redis等众多系统构建与这个理论之上
ACID  传统数据库常用的设计理念, ACID和BASE代表了两种截然相反的设计哲学,分处一致性-可用性分布图谱的两极。

时间: 2024-10-24 15:14:16

CAP原则(CAP定理)的相关文章

CAP原则(CAP定理)、BASE理论

参考文章: https://www.cnblogs.com/duanxz/p/5229352.html 原文地址:https://www.cnblogs.com/amei0/p/8178550.html

CAP原则、BASE理论

CAP原则.BASE理论 2017-12-15 目录 1 CAP原则  1.1 CAP原则是什么  1.2 CAP为何三者不可得兼  1.3 一致性与可用性的决择2 BASE理论  2.1 BASE理论是什么  2.2 ACID和BASE的区别与联系  2.3 最终一致性五钟变种3 分布式系统的典型应用参考 计算机系统从集中式向分布式的变革,随着包括分布式网络.分布式事务和分布式数据一致性等在内的一系列问题与挑战,同时也催生了一大批诸如ACID.CAP和BASE等经典理论的快速发展. 1 CAP

CAP原则和BASE理论

CAP原则 CAP原则又称CAP定理,是一个经典的分布式系统理论.CAP理论告诉我们:一个分布式系统不可能同时满足一致性(C:Consistency).可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中两项. 一致性 在分布式环境下,一致性是指数据在多个副本之间能否保持一致的特性.在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态. 对于一个将数据副本分布在不同分布式

分布式数据缓冲的CAP原则

首先需要了解一个概念: 在分布式系统中需要处理大量的http请求,其中有大量的http请求(来自不同服务器)需要访问数据库,但是我们的主数据库承载不了如此之多的连接,所以衍生出了数据缓冲的概念,也就是在多个处理http连接的服务器上创建主数据库的副本(不一定是全部副本,可能是部分,也可能是全部,根据设计不同而不同,) 接下来该说明一下CAP原则了(在处理服务器的数据库中) C:数据一致性(一次更改,在下一次访问该数据时,所有副本的数据都是更改之后的) A:可用性(该数据库可以立即处理对应的htt

CAP原则

http://baike.baidu.com/link?url=LsT9uKY9cI4O9tBtLUnuC1LsCDcay6z2gtY9zA9nUP5qDGujg-RayCHKoeBRoybD4T02He4JwoOnbjba9uJPhDYE-3G0kI8BQFd8hvMAxga CAP原理和BASE思想

zk和eureka的区别(CAP原则)

作为服务注册中心,Eureka比Zookeeper好在哪里 著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性).A(可用性)和P(分区容错性).由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡.在此Zookeeper保证的是CP, 而Eureka则是AP. 1 Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用.也就是说,服务注册功能对可用性的要求要高于一致性.但是z

CAP定理(原则)以及BASE理论

CAP定理(原则)以及BASE理论 CAP定理(原则)概念 CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性). Availability(可用性).Partition tolerance(分区容错性),三者不可得兼. 1. 数据一致性(consistency) 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值.(等同于所有节点访问同一份最新的数据副本) 2. 服务可用性(availability) 可用性(A):在集群中一部分节点故障后,集

搜索引擎基本原理

摘要:最近读了<这就是搜索引擎:核心技术详解>一书,简要作个记录. __________________________________________________ 目录 [1]搜索引擎概述 [2]搜索引擎的基础技术 [3]搜索引擎的平台基础 [4]搜索结果的改善优化 __________________________________________________ [1]搜索引擎概述 过去的15年间,互联网信息急剧膨胀,靠人工的方式去筛选获取有用信息不再可能,因此搜索引擎应运而生.根据

一篇文章助你深入理解zookeeper

Zookeeper作为一个分布式协调系统提供了一项基本服务:分布式锁服务,分布式锁是分布式协调技术实现的核心内容.像配置管理.任务分发.组服务.分布式消息队列.分布式通知/协调等,这些应用实际上都是基于这项基础服务由用户自己摸索出来的. 1.Zookeeper在大数据系统中的常见应用 zookeeper作为分布式协调系统在大数据领域非常常用,它是一个很好的中心化管理工具.下面举几个常见的应用场景. 1.1.HDFS/YARN HA(分布式锁的应用):Master挂掉之后迅速切换到slave节点.