什么是 CAP 理论？

CAP 理论是指在一个分布式系统中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，剩下的一个必须被牺牲。

一致性 Consistency：对某个客户端来说，读操作保证能够返回最新写操作的结果。以社交网站来说，假如今天你按了某个贴文赞，其他看贴文的人如果马上看到，那就是有一致性；但如果其他人没有马上看到贴文多了一个赞，那就是没有维持一致性。
可用性 Availability：非故障节点能在合理的时间内，返回合理地响应，意即不是错误和超时的响应，让系统能维持可用的状态。以社交网站来说，如果今天你进到网站中，看到某个喜欢的贴文要按赞，但是按不了，那就是不可用。
分区容错性 Partition Tolerance：当出现分区时（封包遗失、连接中断、塞车等），系统能够继续履行职责（返回合理的响应）。

让我们再用比较具体的例子来说明。想像今天你要设计银行的 ATM 系统，会在世界各地都设置 ATM 系统。每个 ATM 机器都可以想像成一个节点，这些节点通过网络连接，知道目前系统的状态。

然而，假如今天网络连接出问题，这时如果想从在路口的 A 机台领钱，在没有网络连接的情况下，A 机台无从得知其他机台的状态，这时如果用户甲从 A 机台领了钱，然后走到转角后想到自己少领，所以在马路转角的 B 机台领，因为 A 与 B 两者没有连线，所以在 B 机台领钱时，B 机台不会知道余额要被扣掉刚刚领的，这时会导致余额显示错误。

上面这种状况，就是保持可用性，但是一致性出问题 (A 与 B 机台的余额显示不一致)，在 ATM 的设计下，这会是个大问题。因此，多数 ATM 不会这样设计，而是会选择保持一致性。

但如果我们要保持一致性，就会牺牲可用性，因为若要保持一致性，当网络连接出问题时，就需要暂时锁死不让人从任何机台领钱，这样每台的余额都会维持一致；但若不给领钱，可用性就会出问题。

CAP 的应用

在分布式系统中，必然会需要选择 P ，因为网络本身不可能做到 100% 可靠，因此可能的系统可能是 AP 或者是 CP 。

CP：当两节点 Node 1 将 A 更新为 1 ，当 Node 1 欲将 A 复制到 Node 2 时发生错误，则 Client 重新在 Node 2 读取 A 值时，因为为了确保 Consistency ，所以会得到 Error 。

AP：当两节点 Node 1 将 A 更新为 1 ，当 Node 1 欲将 A 复制到 Node 2 时发生错误，则 Client 重新在 Node 2 读取 A 值时，因为为了确保 Availability，所以会得到旧的值 0 。

用 CAP 辅助思考系统设计

不同子系统有不同策略

在讨论 CAP 时，通常都是以系统、节点的方式来讨论，以至于会误以为系统架构要不选择可用性，要不选择一致性，但其实以系统的角度来看，每一个子系统，可能根据不同的特性，可以选择不同策略，某些部分使用可用性，某些部分则使用一致性。

以抢票系统来说，在最核心的抢票部分，一致性是最关键的，因为不一致就可能导致剩下一张票，但两个人同时买到，这种状况在抢票系统是不能接受的，所以在这部份要维持一致性。但是在浏览有哪些不同活动的页面，可用性就会比较重要，这时一致性就相对还好，因此在该子系统，就可以朝着优化可用性的方向设计。

更进一步说，在同一个系统中的不同面向，也可能有不同的策略。以上面提到的 ATM 例子来说，如果今天出现网络断线，在领钱部分要确保一致性，但是存钱可能就不用。因为领钱时的余额不一致，可能导致领的总额超出余额，这对银行来说后续要追讨会很麻烦；但是存钱的话，两边有暂时的不一致，对银行业务不会有太大的影响，只要等网络连接恢复后再同步即可，因此存钱就可以往高可用靠。

现实的系统不会是完美的

在用 CAP 思考时，要有个前提，那就是现实系统不会是完美的。举例来说，即使网络没有断线，在数据的复制过程中，一定会有网络延迟，短则几毫秒，长则几十毫秒，因此在复制的过程中会有短暂的不一致问题，因此在某些情况下，是做不到完美的一致性，但我们仍会朝着尽可能一致性来设计。与此同时，假设在完美的状况下 P 没有发生，我们可以去思考，如何确保设计能保证 CA 被尽可能实现。

放弃并不等于什么都不做

系统不会一直都处于错误的状态，但错误还是有可能发生，因此需要为错误发生后要怎么恢复来做准备，举例来说，用户管理系统一开始选择了 CP ，当分区发生后，节点一可以注册新帐户，节点二无法注册新帐户（不满足 A ），当分区发生故障时（ P 失效时），节点一会先将纪录存在 Log 里，分区恢复后再将数据同步到节点二。所以对于节点一而言，目前是 CA 状态。