分布式系统（distributed system）正变得越来越重要，大型网站几乎都是分布式的。
分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。
本文介绍该定理。它其实很好懂，而且是显而易见的。下面的内容主要参考了 Michael Whittaker 的文章。
一、分布式系统的三个指标
1998 年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。
- Consistency
- Availability
- Partition tolerance
它们的第一个字母分别是 C、A、P。
Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
二、Partition tolerance
先看 Partition tolerance，中文叫做"分区容错"。
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
上图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。
一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。
三、Consistency
Consistency 中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。
接下来，用户的读操作就会得到 v1。这就叫一致性。
问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。
为了让 G2 也能变为 v1，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1。
这样的话，用户向 G2 发起读操作，也能得到 v1。
四、Availability
Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。
用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。
五、Consistency 和 Availability 的矛盾
一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。
如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。
如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。
综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。
[更新 2018.7.17]
读者问，在什么场合，可用性高于一致性？
举例来说，发布一张网页到 CDN，多个服务器有这张网页的副本。后来发现一个错误，需要更新网页，这时只能每个服务器都更新一遍。
一般来说，网页的更新不是特别强调一致性。短时期内，一些用户拿到老版本，另一些用户拿到新版本，问题不会特别大。当然，所有人最终都会看到新版本。所以，这个场合就是可用性高于一致性。
http://www.ruanyifeng.com/blog/2018/07/cap.html
总结
- 在分布式系统中，有一个基本原则叫做 CAP，consistence，一致性，availability，可用性，partition tolerance 分区容错性。
- 一致性，在这里指的是分布式系统的各个副本的值要保持同步，这里强的是空间上的一致，注意和数据库中 ACID 中的一致性相区分，那个一致性指的是事务执行前后的逻辑一致性，比如你转 1000 块给别人，不能你的账户少了 1000 块，对方的账户却没有多 1000 块。
可用性，指的是当 client 发出数据读写请求时，要在足够短的时间内做出响应。 - 分区容错性指的是，在不稳定和不可靠的网络环境下，节点可能出现失联或者荡机，网络可能出现分区子网，在这种情况下仍然能保证数据不出错。
所以，分区容错性是我们必须最终要保证的，但是一致性和可用性是一对矛盾的东西。所以在三者中，我们只能取两个。
为啥一致性和可用性是一对矛盾的东西呢？因为要实现一致性，在本质上都是进行副本之间的同步，而这个是需要花时间的，如果要保证强一致性，那么在同步的这一段时间中，是不可用的。
定义
在一个分布式系统（指系统中的节点互相连接并共享数据）中，当涉及读写操作时，只能保证一致性 (Consistency)、可用性 (Availability)、分区容错性 (Partition Tolerance)三者中的两个，另外一个必须被牺牲。
- 一致性：CAP 中的 C 和 ACID 中的 C 不是一个含义，ACID 中的 C 是指数据库中的数据满足一定的约束条件。而 CAP 中的 C 是指线性一致性，即：客户端向系统写入什么，那么读出来的也会是什么。也就是要保证客户端读取到的数据一定是上次写入的最新数据。
- 可用性：指系统中的部分节点出现故障后，系统能否还能对外提供完全可用的服务；
- 分区容错性：指是否允许系统中的节点之间无法通信，也就是无法互相连接；
适用场景
那么什么样的分布式系统是节点之间互联并共享数据呢？
典型的场景就是数据库的主从集群，一个数据库集群有一个主，多个从，主从之间会进行数据复制。所以适用于 CAP 原理。
那么如果我现在是一个 Redis 的集群，集群中每台机器存储不同的数据，集群中每台机器不需要复制和传递数据，那么就不属于 CAP 原理的讨论范围。同理，如果是 A,B 两个不同的业务系统，比如招行账号 A 给工行账号 B 转账 100 元，由于招行和工行是两个不同的业务系统，业务上隔离，且他们之间也没有共享的数据，从而也不属于 CAP 原理的讨论范围。
场景方案选择
- 传统数据库主从集群：如果当前是一个现在是一个主从复制的数据库集群，同一条数据会在主从数据库上都存储，那么当存在主从数据库之间网络断开时，我们确实只能要么选择 A 放弃 C，要么选择 C 放弃 A。选择 A 放弃 C，就是客户端读取到的可能不是最新的数据，但是系统持续可用；选择 C 放弃 A，就是让系统服务不可用，客户端自然就不会认为数据不一致了。
- 分布式数据库，如阿里的 OceanBase，这种数据库也是一个主从的集群，但是主从节点往往使用 Paxos/Raft 等副本一致性协议，做到整个数据库系统，在部分节点发生故障时，也能在很短的时间内自动重新选主，选出一个新的主从集群的数据库系统。在重新选主的过程中，系统不可用，相当于放弃了 A，而一旦选出新的主之后，系统又继续可用，且数据对外是线性一致的。相比传统的数据库主从集群，分布式数据库由于可以在遇到网络分区导致数据库主从节点之间无法互联时，可以快速选出新的主，然后快速恢复，所以架构设计上和用户体验上，要好很多。但是系统设计的复杂度也非常高。
分布式事务
通过上面的分析，我们知道 CAP 中的数据一致性，本质上是为了维护同一个数据的不同副本之间的一致性。而更多的时候，我们要解决的是不同业务系统之间的数据一致性，即数据之间总是应该满足规定的业务规则。典型的场景比如有跨行转账、订单和减库存。这种场景，由于没有数据共享的特征，所以不适用于 CAP。比如 A 银行的账户给 B 银行的账户转账 100 元，那么转账前后，两个账户的钱加起来应该不变。也就是 A 扣款了，B 就必须加款。那么这种场景如何解决呢？一般的做法是采用分布式事务，常见的分布式事务的解决方案有：2PC\3PC、TCC、基于分布式 MQ+ 本地消息、分布式 MQ 事务消息、Sagas。
其他网友分析
CAP 原理指的是，在分布式系统中这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数 Web 应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。
- 一致性（
Consistency）：数据在多个副本之间是否能够保持一致的特性。（当一个系统在一致状态下更新后，应保持系统中所有数据仍处于一致的状态） - 可用性（
Availability）：系统提供的服务必须一直处于可用状态，对每一个操作的请求必须在有限时间内返回结果。 - 分区容错性（
Tolerance of network Partition）：分布式系统在遇到网络分区故障时，仍然需要保证对外提供一致性和可用性的服务，除非整个网络都发生故障。
为什么只能同时满足两个？
例如，服务器中原本存储的 value=0，当客户端 A 修改 value=1 时，为了保证数据的一致性，要写到 3 个服务器中，当服务器 C 故障时，数据无法写入服务器 C，则导致了此时服务器 A、B 和 C 的 value 是不一致的。这时候要保证分区容错性，即当服务器 C 故障时，仍然能保持良好的一致性和可用性服务，则 Consistency 和 Availability 不能同时满足。为什么呢？
- 如果满足了一致性，则客户端 A 的写操作 value=1 不能成功，这时服务器中所有 value=0。
- 如果满足可用性，即所有客户端都可以提交操作并得到返回的结果，则此时允许客户端 A 写入服务器 A 和 B，客户端 C 将得到未修改之前的 value=0 结果。
🐶 你走，我不送你。你来，风雨无阻，我去接你。