一致性（Consistency）：所有节点在同一时间具有相同的数据。 可用性（Availability）：保证对于每个请求的成功或者失败都有响应。分区容错性（Partition Tolerance）：系统中信息的丢失或失败并不影响系统的运行。

分布式事务问题，必然会说下CAP理论，分布式系统的三大指标：

Consistency：一致性

单个事务执行更新写操作，操作结束成功返回，在同一时间的其他事务读取的数据完全一致，不存在中间状态。在分布式的系统中描述：用户下单支付，扣款，减库存，生成物流，必须一致。例如限量打折促销中，用户下单后库存没减少，这就导致不一致问题。

Availability：可用性

服务必须一直处于可用的状态，收到用户的请求，服务器必须在有限的时间给出回应，不管结果是处理成功或者处理失败。

Partition tolerance：分区容错

通俗说，在分布式系统中，一个流程里可能出现某个服务出错情况，这是无法绝对避免的，在程序设计上要能容忍这种错误发生。

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

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

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

● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本），换句话就是说，任何时刻，所用的应用程序都能访问得到相同的数据。

● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性），换句话就是说，任何时候，任何应用程序都可以读写数据。

● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，换句话说，系统可以跨网络分区线性的伸缩和扩展。

如上图所示意，不可能设计出既满足一致性，有满足可用性还同时满足分区容错性的系统。

其实就是一个三角约束，咱们触类旁通一下，学过项目的管理的同学都知道，在项目管理中也有一个有名的黄金三角约束：时间，质量和成本或者时间，成本和范围的三角约束。

鱼与熊掌不可得兼，所以要求架构设计者能够和业务部门或者客户或者领导层沟通，进行一定的取舍。毕竟在很多公司，技术都是业务驱动的。

CAP原理认为:分布式系统有三个核心需求,即数据一致性Consistency(以下简称C)､可用性Availability(以下简称A)和分区容忍性PartitionTolerance(以下简称P),且这三个需求最多只能同时满足两个(见图1)｡CAP原理是针对Web等各类分布式系统提出的,由于在数据库领域内的表现显著,现在人们大都围绕数据库对其讨论和应用

Consistency：一致性

单个事务执行更新写操作，操作结束成功返回，在同一时间的其他事务读取的数据完全一致，不存在中间状态。在分布式的系统中描述：用户下单支付，扣款，减库存，生成物流，必须一致。例如限量打折促销中，用户下单后库存没减少，这就导致不一致问题。

Availability：可用性

服务必须一直处于可用的状态，收到用户的请求，服务器必须在有限的时间给出回应，不管结果是处理成功或者处理失败。

Partition tolerance：分区容错

通俗说，在分布式系统中，一个流程里可能出现某个服务出错情况，这是无法绝对避免的，在程序设计上要能容忍这种错误发生。

CAP原理认为:分布式系统有三个核心需求,即数据一致性Consistency(以下简称C)､可用性Availability(以下简称A)和分区容忍性PartitionTolerance(以下简称P),且这三个需求最多只能同时满足两个(见图1)｡CAP原理是针对Web等各类分布式系统提出的,由于在数据库领域内的表现显著,现在人们大都围绕数据库对其讨论和应用

CAP需求
在分布式的环境下，设计和部署系统时主要考虑下述3 个重要的核心系统需求：

● 一致性（Consistency）：所有节点在同一时间具有相同的数据。

● 可用性（Availability）：保证对于每个请求的成功或者失败都有响应。

● 分区容错性（Partition Tolerance）：系统中信息的丢失或失败并不影响系统的运行。
上述3 个重要的核心系统需求又简称为 CAP需求。

1.1 一致性
在分布式系统中，数据存在多个副本。一致性是指对某数据操作之后，存在各副本中的该数据始终保持一致。通常将这种操作称为一致性操作，一致性操作是原子性的操作，即对数据的操作（增、删、改）结果是对所有数据副本全部成功才算操作成功，否则为失败。如果操作失败，则回退到一致性操作前的状态。如果一个存储系统能够保证一致性，那么客户读取的数据可以保证是最新的数据，不会发生两个客户端在不同存储节点读取到不同的数据副本。
例1 ： N1、N2 为网络中的两个节点，共享同一数据V，即一个是主本，另一个是副本，其初始值为V0。N1 节点上有一个算法A， N2 上有一个类似的算法B，利用A算法可以将新值写入V，而利用B 算法可以读取V 的值。
1）数据保持一致性情况。
（1） A 写入新的V 值，称作V1。
（2） N1 发送信息给N2，更新N2 的V 值。
（3） B 读取N2 的V 值，读取到的值将是V1。

2）数据出现不一致性情况。
如果网络断开（分区），从N1 无法发送信息到N2，那么在第（3）步的时候，N2 就会包含一个与N1 中的不一致的V 值，即在N1 中的V=V1，在N2 中的V= V0。

1.2 可用性
可用性是指客户端访问数据时，可以得到响应，但系统可用并不代表存储系统的所有节点提供的数据一致。如客户端想要读取文章评论，存储系统可以返回客户端数据，但评论缺少最新的一条。在这种情况下，我们仍然可以说系统可用。往往可对不同的应用设定一个定长响应时间，超过这个定长响应时间的服务认为不可用。可用性只表明服务可用，主要标志是可以完成或不能完成上述操作。如当用户购书时希望得到反馈，而不是看到浏览器报告网站无法连接的信息。

1.3 分区容错性
在分布系统中，为了提高系统性能，可以将同一数据的副本分布地存放在不同地点。分区容错性是指分布系统的容错性。更确切地说，除非网络的全部节点都出现故障，否则所有子集合节点的故障都不能导致整个系统的不正确响应。显然，将数据分布在不同节点上，就有形成分区的风险。如果网线被切断，分区就形成，两节点之间无法进行通信。网络分区是指由于某种原因网络被分成若干个孤立的互不相通区域。分区容错性也可以理解为系统在存在网络分区的情况下仍然可以接受满足一致性或可用性的请求。

2 CAP 定理
CAP定理指出：在一个分布式系统构建中，不可能同时满足一致性、可用性和分区容错性三个系统需求，最多只能同时满足两个[2]。对所设计系统的强调点不同，采用的策略也不一样。分布系统在小规模、低压力、小延迟的情况下，CAP 定理还不足以对系统总体性能造成影响，但随着活动增加与吞吐量上升将凸显其重要性。对大型网站来说，可用性与分区容错性的优先级高于数据一致性，一般放弃一致性，尽量朝着可用性和分区容错性的方向设计，然后通过其他方法来保证一致性的商务需求。架构设计师不要将主要精力用在如何设计能同时满足三者的完美分布式系统，社交SNS 网站可以容忍相对较长时间的不一致性，但需要最终一致性。
CAP 的证明很简单，假设两个节点集{G1，G2}，由于网络分片导致G1 和G2 之间所有的通讯都断开了，如果在G1 中写，在G2 中读刚写入的数据， G2 中返回的值不可能是G1 中的写入值。由于可用性的要求，G2 一定要返回这次读请求，由于分区容错性的存在，导致不一致性。但由于一致性的要求，G2 一定要返回这次读请求的一致性结果，由于分区容错性的存在，导致了长期等待，出现了不可用性。

2.1 异步网络模型
在异步网络模型中，没有统一时钟，对于所有对等运算（包括消息可丢失或不丢失的对等运算），不能实现同时满足可用性、一致性和分区容错性。
一个算法无法判断一个消息是否丢失或者在传输通道中被延迟。

2.2 部分同步网络模型
对于一个部分同步的网络模型，假设所有的节点都有一个时钟，并且所有的时钟以一个相同的速度变化。然而，这些时钟并不同步，在相同的时间，它们显示不同的时间值。事实上，时钟扮演计时器的角色，处理器可以根据本地状态变量去衡量流逝了多少时间。一个本地的计时器可以用来确定调度某事件之后，经过多长时间间隔进行另一个操作。进而假设每一个消息要么在给定的时间内到达，要么丢失。并且所有节点在给定时间内处理完一个接收到的消息。在一个部分同步网络模型中，对于所有对等运算（包括消息可丢失的对等运算），不能实现同时满足可用性、一致性和分区容错性。在Google 使用廉价的PC 机搭建了强大的、高可靠的计算和存储平台之后，互联网公司一致性地选择使用PC 集群支撑全部的业务，这个理论指明了实现满足可用性、分区容错性的分布式系统可行，并且该分布式系统在没有故障的情况下可以提供良好的一致性读写。

2.3 三中取二原则
CAP 定理阐明分布系统构建中的3 个核心系统需求不能够全部同时满足，强调一致性就需要处理因为系统不可用而导致的写操作失败的情况；如果强调可用性，那么应该知道系统的读操作可能不能精确的读取到写操作写入的最新值。因此系统的强调点不同，相应采用的策略也不一样，只有真正理解了系统的需求，才有可能合理使用CAP 理论。目前互联网中的很多分布式系统是基于首要满足可用性和分区容错性而设计。当处理CAP的问题时，存在下述几个选择。

1）放弃可用性 。
如果选择分区容错性和一致性，放弃了可用性，那么即使节点损坏，为保证一致性，必须百分之百地保证所有节点之间有很好的连通性，这是很难做到的。最好的办法就是将所有数据放到同一个节点中，但显然这种设计一旦遇到分区事件，受影响的服务需要等待数据一致，在等待期间就无法对外提供服务。在多个节点上控制数据一致相当复杂，而且恢复的节点需要处理逻辑，以便平滑地返回服务状态。满足一致性与分区容错性的系统主要是一些键‘ —’值数据库， 典型代表为Google 的BigTable 等系统。

2）放弃分区容错性。
如果要满足一致性和可用性，必须要有回滚操作。这样，系统显然无法容忍分区，当同一数据的两个副本分配到了两个无法通信的分区上并需要回滚操作时，将会返回错误的数据。满足一致性和可用性的系统通常在可扩展性方面不太强，如传统的关系数据库系统MySQL 等。

3）放弃一致性。
如果选择分区容错性和可用性，放弃了一致性，当节点损坏时，遇到分区事件，受影响的服务不需要等待数据一致，就可以对外提供服务，保证了可用性。满足可用性与分区容错性的系统主要是一些面向文档的适用于分布式系统的数据库，如SimpleDB。
两个节点分处分区两侧，允许至少一个节点更新状态将导致数据不一致，即丧失了一致性。除非两个节点可以互相通信，才能既保证一致性又保证可用性，这又会导致丧失分区容错性。对于跨区域的系统，设计者无法舍弃分区容错性，那么就只能在数据一致性和可用性上做一个艰难选择。一般说来，NoSQL 的主题是创造可用性优先、数据一致性其次的方案；而传统关系数据库保持ACID 特性（原子性、一致性、隔离性和持久性）。

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

● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本），换句话就是说，任何时刻，所用的应用程序都能访问得到相同的数据。

● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性），换句话就是说，任何时候，任何应用程序都可以读写数据。

● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，换句话说，系统可以跨网络分区线性的伸缩和扩展。

如上图所示意，不可能设计出既满足一致性，有满足可用性还同时满足分区容错性的系统。

分布式领域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原理中的三个要素

• 一致性(Consistency)

• 可用性(Availability)

• 分区容忍性(Partition tolerance)

CAP理论的描述

CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。

　　对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

　　当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

最终一致性(eventually consistent)

对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

• 因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。

• “读己之所写（read-your-writes）”一致性。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。

• 会话（Session）一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。

• 单调（Monotonic）读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。

• 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

　　上述最终一致性的不同方式可以进行组合，例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看，这两者的组合，读取自己更新的数据，和一旦读取到最新的版本不会再读取旧版本，对于此架构上的程序开发来说，会少很多额外的烦恼。

从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：

• 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，并且写入的节点不重叠的话，则会存在写冲突