CAP

一 CAP理论简述 
海量数据管理中的一致性理论，包括CAP理论，BAS理论，数据一致性理论模型，以及现有的经典数据一致性技术。其中CAP (Consistency, Availability, Partition Tolerance,) 理论是NoSQL数据库管理系统构建的基础。 
CAP定律说的是在一个分布式计算机系统中，一致性，可用性和分区容错性这三种保证无法同时得到满足，最多满足两个。该定律作为猜想在2000年提出，2002年被证实。 


强一致性：系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。 
可用性：每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。一定时间指的是，在可以容忍的范围内返回结果，结果可以是成功或者失败。 
分区容错性：理解为在存在网络分区的情况下，仍然可以接受请求（满足一致性和可用性)。这里的网络分区是指由于某种原因，网络被分成若干个孤立的区域，而区域之间互不相通。还有一些人将分区容错性理解为系统对节点动态加入和离开的能力，因为节点的加入和离开可以认为是集群内部的网络分区。 

放弃P：如果想避免分区容错性问题的发生，一种做法是将所有的数据（与事务相关的）都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果。当然这个选择会严重的影响系统的扩展性。 
放弃A:相对于放弃“分区容错性“来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供服务。 
放弃C：这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。以网络购物为例，对只剩下一件库存的商品，如果同时接受到了两份订单，那么较晚的订单将被告知商品告罄。 
二 CAP的理解 常见的理解及分析 目前流行的、对CAP理论解释的情形是从同一数据在网络环境中存在多个副本出发为前提的。为了保证数据不会丢失，同时也是为了增加并发访问量（读写分离），在企业级的数据管理方案中，一般必须考虑数据的冗余存储问题，而这应该是通过在网络上的其他独立物理存储节点上保留另一份、或多份数据副本来实现的（如附图所示）。因为在同一个存储节点上的数据冗余明显不能解决单点故障问题，这与通过多节点集群来提供更好的计算可用性的道理是相同的。程序开发来说，会少很多额外的烦恼。 
从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：N — 数据复制的份数,W — 更新数据是需要保证写完成的节点数,R — 读取数据的时候需要读取的节点数，如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。 
对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突。 
四 传统数据库与NoSQL数据库 
传统的关系型数据库在功能支持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机制的支持。而与之不同的是，NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）。 传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行;C代表一致性，即保证进行事务的过程中整个数据加的状态是一致的，不会出现数据花掉的情况;I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等;D表示持久化，即事务一量完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）。
NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。例如MongoDB数据库，它是不支持事务机制的，同时也不提倡多表关联的复杂模式设计，它只保证对单个文档(相当于关系数据库中的记录)读写的原子性。 

补充: MPP架构介绍 MPP (Massively Parallel Processing)，大规模并行处理系统，这样的系统是由许多松耦合的处理单元组成的，要注意的是这里指的是处理单元而不是处理器。每个单元内的CPU都有自己私有的资源，如总线，内存，硬盘等。在每个单元内都有操作系统和管理数据库的实例复本。这种结构最大的特点在于不共享资源。

分布式系统的CAP理论：
理论首先把分布式系统中的三个特性进行了如下归纳：
● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（可用性不仅包括读，还有写）
● 分区容忍性（P）：集群中的某些节点在无法联系后，集群整体是否还能继续进行服务。

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

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

高可用性就是高性能。 BASE提供了基本可用性。BASE是碱，ACID是酸。

总结：
传统的关系型数据库在功能支持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到
事务机制的支持。而与之不同的是，NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现。）。

传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性，即在事务中执行多个
操作是原子性的，要么事务中的操作全部执行，要么一个都不执行;C代表一致性，即保证进行事
务的过程中整个数据加的状态是一致的，不会出现数据花掉的情况;I代表隔离性，即两个事务不
会相互影响，覆盖彼此数据等;D表示持久化，即事务一量完成，那么数据应该是被写到安全的，
持久化存储的设备上（比如磁盘）。


NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串
行的执行，保证了每一个Key-Value对不会被破坏。


Redis:BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
1.目前最快的KV数据库,10W次/S, 满足了高可用性。
2.Redis的k-v上的v可以是普通的值（基本操作：get/set/del） v可以是数值（除了基本操作之外还可以支持数值的计算） v可以是数据结构比如基于链表存储的双向循环list（除了基本操作之外还可以支持数值的计算，可以实现list的二头pop,push）。
如果v是list，可以使用redis实现一个消息队列。如果v是set,可以基于redis实现一个tag系统。与mongodb不同的地方是后者的v可以支持文档，比如按照json的结构存储。redis也可以对存入的Key-Value设置expire时间。
3.Redis的v的最大远远超过memcache。这也是实现消息队列的一个前提。


在NoSQL中，通常有两个层次的一致性：第 一种是强一致性，既集群中的所有机器状态同步保持一致。第二种是最终一致性，既可以允
许短 暂的数据不一致，但数据最终会保持一致。我们先来讲一下，在分布式集群中，为什么最终一致 性通常是更合理的选择