分布式架构入门：一文轻松搞懂晦涩的CAP理论！ _可用性

二、CAP定义的辨析
有比较才有鉴别，CAP理论的定义有很多版本，通过比对这些版本的差异，让我对CAP有了更深入的理解，这里挑选了了2个典型版本：
版本1：
对于一个分布式计算系统，不可能同时满足一致性( )、可用性()、分区容错性()三个设计约束。
一致性()：所有节点在同一时刻都能看到相同的数据。
可用性()：每个请求都能得到成功或失败的响应。
分区容错性()：尽管出现消息丢失或分区错误，但系统能够继续运行。
版本2：
在一个分布式系统 (指互相连接并共享数据的节点的集合)中，当涉及读写操作时，只能保证一致性( )、可用性( )、分区容错性()三者中的两个，另外一个必须被牺牲。
一致性()：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果（A read istothe mostwrite for a given ）。
可用性()：非故障的节点在合理的时间内返回合理的响应 (不是错误和超时的响应）。
分区容错性()：当出现网络分区后，系统能够继续 “履行职责” 。
我们来具体看看两者的差异：
1、第二版强调了CAP 理论适用于哪种类型的分布式系统，第一，互相连接并共享数据的节点的集合，第二，关注的是对数据的读写操作，而不是分布式系统的所有功能。
2、在一致性上，第一版从节点 node 的角度描述，第二版从客户端的角度描述。第一版强调同一时刻拥有相同数据，第二版并没有强调这点。这就意味着实际上对于节点来说，可能同一时刻拥有不同数据，这和我们通常理解的一致性是有差异的。
3、在可用性上，第一版的“每个请求都能得到成功或失败的响应”定义比较模糊，因为无论是否符合CAP理论，我们都可以说请求成功和失败，因为超时也算失败，错误也算失败，异常也算失败，结果不正确也算失败;即使是成功的响应，也不一定是正确的。例如，本来应该返回100，但实际上返回了90，这就是成功的响应，但并没有得到正确的结果。相比之下，第二版的解释明确了不能超时，不能出错，结果是合理的，注意没有说“正确”的结果。例如，应该返回100但实际上返回了90，肯定是不正确的结果，但可以是一个合理的结果。
4、在分区容错性上，第一版用的是“继续运行”，第二版用的是“履行职责” 。只要系统不宕机，我们都可以说系统在运行，返回错误和拒绝服务都是运行，而“履行职责”表明发挥正常作用，这点和可用性是一脉相承的，相比之下更加明确。
三、CAP潜在的约束
理论的优点在于清晰简洁，易于理解，但缺点就是高度抽象化，省略了很多细节，导致在将理论应用到实践时，由于各种复杂情况，可能出现误解和偏差，CAP 理论也不例外。
1、CAP有适用范围
正如定义中所说，CAP是有适用范围的，乱套用CAP往往谬以千里。
这里以一个电商网站订单模块的下单、付款、扣减库存操作为例说明。在超时的情况下，订单数据和库存数据状态会不一致，这属不属于CAP理论的适用范围呢？答案是不适用。
大家不要一看到不一致就认为适用CAP理论。前面已经讲过，CAP的适用范围只是针对共享、互联的数据，订单和库存系统虽然是互联的，但没有共享的数据，超时情况下产生的不一致只能靠对账和人工修复等方式解决。但如果针对的是各节点的库存数据的一致性，则适用CAP理论，比如当用户下单支付后，各节点的库存数据需要立即更新，以保证所有查看该商品的用户都能看到最新的库存信息。
2、CAP理论中，P是必选项
虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 p (分区容忍)要素，因为网络本身无法做到 100%可靠，有可能出故障，所以分区是一个必然的现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error (例如，当前系统不允许写入)，这又和 A 冲突了，因为 A 要求返回 no error 和 no。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或 AP 架构。