分布式领域CAP理论，
专注于为中小企业提供网站设计制作、网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业迎江免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了上千家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。
关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区：
Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。
Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。
Durability. 一旦事务完成，就不能返回。
跨数据库事务：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，JavaEE中的JTA事务可以支持2PC。因为2PC是反模式，尽量不要使用2PC，使用BASE来回避。
BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步，异步。
Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。
BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片
BASE思想主要强调基本的可用性，如果你需要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。
现在NoSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：
1. Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
2. 领域模型 + 分布式缓存 + 存储 （Qi4j和NoSQL运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。
这两者共同点：都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。
不同点：NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。
常见的理解及分析
目前流行的、对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做出正确的解释。但可惜的是，目前为止却很少有人提及这两种场景：那就是事务与关联。
先来看看分布式环境中的事务场景。我们知道，在关系型数据库的事务操作遵循ACID原则，其中的一致性C，主要是指一个事务中相关联的数据在事务操作结束后是一致的。所谓ACID原则，是指在写入/异动资料的过程中，为保证交易正确可靠所必须具备的四个特性：即原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）和持久性（Durability）。
例如银行的一个存款交易事务，将导致交易流水表增加一条记录。同时，必须导致账户表余额发生变化，这两个操作必须是一个事务中全部完成，保证相关数据的一致性。而前文解释的CAP理论中的C是指对一个数据多个备份的读写一致性。表面上看，这两者不是一回事，但实际上，却是本质基本相同的事物：数据请求会等待多个相关数据操作全部完成才返回。对分布式系统来讲，这就是我们通常所说的分布式事务问题。
众所周知，分布式事务一般采用两阶段提交策略来实现，这是一个非常耗时的复杂过程，会严重影响系统效率，在实践中我们尽量避免使用它。在实践过程中，如果我们为了扩展数据容量将数据分布式存储，而事务的要求又完全不能降低。那么，系统的可用性一定会大大降低，在现实中我们一般都采用对这些数据不分散存储的策略。
当然，我们也可以说，最常使用的关系型数据库，因为这个原因，扩展性（分区可容忍性P）受到了限制，这是完全符合CAP理论的。但同时我们应该意识到，这对NoSQL数据库也是一样的。如果NoSQL数据库也要求严格的分布式事务功能，情况并不会比关系型数据库好多少。只是在NoSQL的设计中，我们往往会弱化甚至去除事务的功能，该问题才表现得不那么明显而已。
因此，在扩展性问题上，如果要说关系型数据库是为了保证C、A而牺牲P，在尽量避免分布式事务这一点上来看，应该是正确的。也就是说：关系型数据库应该具有强大的事务功能，如果分区扩展，可用性就会降低；而NoSQL数据库干脆弱化甚至去除了事务功能，因此，分区的可扩展性就大大增加了。
再来看看分布式环境中的关联场景。初看起来，关系型数据库中常用的多表关联操作与CAP理论就更加不沾边了。但仔细考虑，也可以用它来解释数据库分区扩展对关联所带来的影响。对一个数据库来讲，采用了分区扩展策略来扩充容量，数据分散存储了，很显然多表关联的性能就会下降，因为我们必须在网络上进行大量的数据迁移操作，这与CAP理论中数据副本之间的同步操作本质上也是相同的。
因此，如果要保证系统的高可用性，需要同时实现强大的多表关系操作的关系型数据库在分区可扩展性上就遇到了极大的限制（即使是那些采用了各种优秀解决方案的MPP架构的关系型数据库，如TeraData，Netezza等，其水平可扩展性也是远远不如NoSQL数据库的），而NoSQL数据库则干脆在设计上弱化甚至去除了多表关联操作。那么，从这一点上来理解“NoSQL数据库是为了保证A与P，而牺牲C”的说法，也是可以讲得通的。当然，我们应该理解，关联问题在很多情况下不是并行处理的优点所在，这在很大程度上与Amdahl定律相符合。
所以，从事务与关联的角度来关系型数据库的分区可扩展性为什么受限的原因是最为清楚的。而NoSQL数据库也正是因为弱化，甚至去除了像事务与关联（全面地讲，其实还有索引等特性）等在分布式环境中会严重影响系统可用性的功能，才获得了更好的水平可扩展性。
那么，如果将事务与关联也纳入CAP理论中一致性C的范畴的话，问题就很清楚了：关于“关系型数据库为了保证一致性C与可用性A，而不得不牺牲分区可容忍性P”的说法便是正确的了。但关于“NoSQL选择了C与P，或者A与P”的说法则是错误的，所有的NoSQL数据库在设计策略的大方向上都是选择了A与P（虽然对同一数据多个副本的读写一致性问题的设计各有不同），从来没有完全选择C与P的情况存在。
结论
现在看来，如果理解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数据库都普遍追求的特性。
个人不认为nosql在少量数据存储上有啥优势。nosql主要解决的是auto sharding的问题,你不需要sharding,搞啥nosql. 作者：方圆 链接：
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 关系型数据库与NoSQL的区别？
3.1 RDBMS
高度组织化结构化数据
结构化查询语言（SQL）
数据和关系都存储在单独的表中。
数据操纵语言，数据定义语言
严格的一致性
基础事务
ACID
关系型数据库遵循ACID规则
事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：
A (Atomicity) 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
3.2 NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储，列存储，文档存储，图形数据库
最终一致性，而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能，高可用性和可伸缩性
分布式数据库中的CAP原理(了解)
CAP定理：
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
P: 系统中任意信息的丢失或失败不会影响系统的继续运作。
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
说明：C：强一致性 A：高可用性 P：分布式容忍性
举例：
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。
因此牺牲C换取P，这是目前分布式数据库产品的方向。
4. 当下NoSQL的经典应用
当下的应用是 SQL 与 NoSQL 一起使用的。
代表项目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型机，很贵的，好像好几万一台；O 是指 Oracle 数据库，也很贵的，好几万呢；M 是指 EMC 的存储设备，也很贵的。
难点：
数据类型多样性。
数据源多样性和变化重构。
数据源改造而服务平台不需要大面积重构。
作者 石默研
关于CAP的讨论已经很多，包括作者的另一篇文章“对CAP的初步解释”，基本已经即定思维的理解就是：分布式系统必须遵循CAP，一个分布式系统的设计只能同时满足其中两个，不可能同时满足；传统关系数据库选择A与C，代表了互联网新兴技术的NoSQL数据库则选择A与P（或者C与P，虽然这种情况其实需要详细讨论）。
但是，近年来，新兴的NewSQL数据库（TiDB或者OceanBase），则是一种在分布式环境下，保证的ACID强事务特征的强一致性数据库，并且很显然，它同时也满足了高可用性与优秀的分区可容忍性（很好的可扩展特性便是其一个层面的证明），似乎看起来，C、A、P都同时保证了，这不是违反了已经经过严格证明的CAP理论吗？
这个问题初看起来，似乎是比较神奇，但仔细分析，其实答案是很明显的。
首先，需要读者区分“分布式”与CAP中所提到的分区可容忍性Paritition Tolerance并不是一回事。分区可容忍性P是指以下两种分布式的情况：
. 同一份数据的多个副本的可分布性
. 有相互关联的数据的可分布性（操作中表现为保证ACID的强分布式事务）
即使是分库分表，如果不存在以上两种情况，只是独立数据在同一个节点上的情况，虽然也是分布式，但跟CAP中的P没有半毛钱关系。
那么，还是回到上面的问题，NewSQL数据库，确实也是在保证了同一份数据多副本的强读写一致性、以及强分布式事务特性这样的C的情况下，同时保证了A与P呀！事实确实如此，但这还是要仔细分析：
无论是TiDB，还是OceanBase，其在保证数据多副本的强一致性时，都采用了Paxos协议或者Raft，它们简单来讲就是多数选举的原则，即写不需要全部副本都完成，就能保证读的强一致性，反过来也是一样。因此，其在分布式情况下，保证数据读写强一致性的效率还是很高的，就是说，在同一个数据中心的网络环境下，虽然这种分布可容忍性的满足理论上讲也会比单节点多一点点效率损失，但实际上是可以忽略不计的。但需要指出的是，在跨数据中心、跨城市的分布式情况下，如果要保证数据多副本的强一致性，即保证分区可容忍性，对效率（实际上是可用性A）的影响那还是不可忽略的。因此，在这种情况下，CAP理论依然成立。
再来看相互关联数据的可分布性，这就涉及到了分布式事务。现有的NewSQL数据库，即使在同一数据中心，为了保证强的分布式事务，对效率的折衷都是不可忽略的，所谓的乐观事务，只是因为客观问题本身冲突就少，并不改变冲突很多时效率明显受影响的现实。因此，NewSQL数据库虽然提供强分布式事务的能力，但在现实应用中，都是提倡尽量避免大量的分布式事务出现。如果你所遇到的应用场景是确实需要大量的分布式事务执行，又不做应用优化全交给数据库执行，那么，现有的NewSQL分布式数据库，依然会遇到明显的性能问题，其实就是可用性A降低了。同学仔细去研究应用中的实际情况就会发现，很多互联网应用，当其所需要的QPS很高很高，而对读写一致性与强分布式事务的要求又不那很高时候，其实，NewSQL数据库还是不能满足他们的需求的，他们仍然需要根据自己的情况改造或者选用NoSQL数据库，这也是CAP理论并没有被NewSQL打破的现实证明。
因此，总结来讲，NewSQL数据库，也是遵循CAP理论的，只不过，在同中心数据多副本情况下，保证P的同时对A的影响微乎其微；而在分布式事务的情况下，又采用了与应用特性相关的策略（其实乐观、悲观事务本质上就有根本应用特性区分的意思）来保证性能而已。当然，随着网络与计算机性能的提高，CAP三个特征中，保证其中两个，折衷另外一个，所带来的影响也会逐渐变小，但其理论依然是正确的。
Apache三剑客：HBase, Cassandra, CouchDB。HBase的前景最为看好，因为它的开发者众多并且都是顶尖高手。Cassandra目前有很多否定的声音。CouchDB的小而精悍，赞誉很多，将要正式发布的CouchBase融合了MemBase和CouchDB，很令人期待。
HBase和Cassandra都是效仿Google的BigTable的基于列的数据库，它们都是用Java写的。另外一类似的数据库是HyperTable，百度用在一些后台分析，因为它是C++写的，速度比较快。不过HyperTable有点边缘，不太流行。这些基于列的开源数据库目前都比Goolge的BigTable差之少一个数量级
CouchDB是一个文档数据库。其最大的竞争者是MongoDB。MongoDB和HBase都采用主从服务器设计。CouchDB的服务器分布设计和Cassandra类似，Peer to Peer类型的。主从服务器设计一般能更好的strong consistent，属于CAP理论中的CP类型。 CouchDB和Cassandra一般认为都是eventual consistent，属于CAP理论中的AP类型。但其实MongoDB和Cassandra都可以设置成strong consistent或者eventual consistent。
以上所提到的数据库都支持MapReduce。好像出了HyperTable都支持非主键索引。HBase和strong consistent配置的MongoDB都支持最基本的锁定（HBase单行锁定，MongoDB单文档锁定），因此可以实现transaction，但是实现有点复杂和低效。单就transaction这一点，目前开源NoSQL数据库没有做的比较好的。
MongoDB的最大卖点是不需构建非主键索引也能执行很多查询。但是MongoDB的服务器分布设计实在不能让人恭维，可以说是NoSQL数据库中最Ugly的实现。
K-V数据库比较多，而且上面提到的基于列的数据库和文档数据库其实也都是K-V数据库。比较流行的纯种K-V数据库有:
Memcached: 非常流行，不支持持久化
VMWare's Redis: 很流行，新浪和知乎都在用，CP类型。
MemBase: 由很多Memcached的开发者开发，使用sqlite作底层存储。在社交游戏中用的比较多, zynga在用，CP类型。
Riak, 分布式实现和CouchDB/Cassandra比较像，AP类型。支持MapReduce。
Linkin's Voldemort， 在K-V中少见的eventual consistent ，AP类型。
TT, TC
纯基于二维座标索引的是Neo4j。但是现在MongoDB和CouchDB都集成这一特性。
目前CouchDB的开发者成立的公司CouchOne收购了MemBase，将其底层sqlite换成CouchDB推出了CouchBase，从而引入MapReduce以支持非主键索引。CouchBase暂时还没有正式发布官方正式版，不过快了。虽然CouchDB是eventual consistent的，但是CouchBase的开发者宣称CouchBase保持了MemBase的strong consistent特性，具体实现有待以后研究。
如果从成熟的角度来看，比较成熟并且十分流行的的有CouchDB，Memcached，Redis。
HBase和MongonDB和Cassandra都比较新，处于频繁更新之中。最有前途的是HBase，但是Hadoop/HBase集群的维护常常需要很多专业人员并且需要构建一个比较大的集群才能最大化体现出威力，因此用户主要是Facebook, yahoo, 百度和阿里巴巴等大公司。
个人比较期待CouchBase。
转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦
