CAP原则

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代表了两种截然相反的设计哲学，分处一致性-可用性分布图谱的两极。