随着微服务和分布式系统的广泛运用，CAP 定理被大家熟悉起来，也成为了分布式系统的三大指标。这篇文章我们就来聊一聊 CAP 定理。
CAP 定理
1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：
- Consistency.
- Availability.
- Partition Tolerance.
Eric Brewer 说，这三个指标不可能同时做到。然后就取首字母，组成了 CAP 定理。
一起来看看这三个指标分别代表什么？
Consistency(一致性)：指读写数据的一致性，特指分布式系统中数据的一致性。如何理解这句话？
假设我们现在有G1、G2 两个实例，现在的值都是 v0，有一个客户端向 G1 发起更新请求，将 v0 更新为 v1，如下图所示：
在不做任何处理的情况下，G1实例对应的值为 v1，G2对应的值为v0。如果此时客户端发起读请求，读 G1 实例上的数据是 v1，读 G2 实例上的值是 v0，这就出现了数据不一致，这就不满足数据一致性。如何保证数据一致性？需要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1。
这样的话，两个实例的值都是 v1，不管客户端读取哪个服务器获取的数据都一样，这就是数据一致性。用大白话来讲就是多实例之间任何时刻数据都要相同。
Availability（可用性）：指服务的高可用，特指分布式系统中服务的高可用，这个就比较好理解，就是我给你发一个请求，你必须给我一个正确的响应。
Partition Tolerance（分区容错性）：指在分布式系统遇到网络分区的情况下，仍然可以响应用户的请求。怎么理解呢？
在我们的分布式系统中，节点组成的网络本来应该是连通的。然而可能因为某些故障，使得有些节点之间不连通了，整个网络就分成了几块区域，而数据就散布在了这些不连通的区域中，这就叫分区。容错的意思就是分区了也需要能够正常访问，大白话就是不要出现单点故障。在分布式系统中，网络抖动、故障是不可避免的所以 CAP 中，P 是必须实现的，只能在 CA 上做取舍。
接下来我们就来看看 CAP 的选择策略及在开源中间件的运用，加深对 CAP 的理解。
保 CP 弃 A
对数据一致要求比较的场景，可以牺牲一定的可用性，来保证数据的一致性，也就是强一致性。比如金融行业，因为它任何时候都不允许出现数据不一致的情况，否则就会给用户造成损失。因此，这种场景下必须保证 CP。
在我们的开源中间件中，ZooKeeper 就是采用保 CP 弃 A 策略，一起来看看。
在 ZooKeeper 集群中，Leader 节点之外的节点被称为 Follower 节点，Leader 节点会专门负责处理用户的写请求：
- 当用户向节点发送写请求时，如果请求的节点刚好是 Leader，那就直接处理该请求；
- 如果请求的是 Follower 节点，那该节点会将请求转给 Leader，然后 Leader 会先向所有的 Follower 发出一个 Proposal，等超过一半的节点同意后，Leader 才会提交这次写操作，从而保证了数据的强一致性。
具体示意图如下所示：
当出现网络分区时，如果其中一个分区的节点数大于集群总节点数的一半，那么这个分区可以再选出一个 Leader，仍然对用户提供服务，但在选出 Leader 之前，不能正常为用户提供服务；
如果形成的分区中，没有一个分区的节点数大于集群总节点数的一半，那么系统不能正常为用户提供服务，必须待网络恢复后，才能正常提供服务。
这种设计就是保证了数据的一致性，但是牺牲了一定的可用性，比如当 Leader 宕机的时候。
保 AP 弃 C
保 AP 弃 C 的策略是比较常见的策略，我们为了追求系统的高可用性，在出现网络抖动的情况下，允许数据暂时不一致，牺牲一定的数据一致性。
网络分区出现后，各个节点之间数据无法马上同步，为了保证高可用，分布式系统需要即刻响应用户的请求。但是此时可能某些节点还没有拿到最新数据，只能将本地旧的数据返回给用户，从而导致数据不一致的情况。
比如我们的 eureka 注册中心就是采用这种策略，在 eureka 集群中，当某个实例宕机了，并不会导致整个 eureka 注册中心不可用，活跃的 eureka 服务器仍然可以响应外部请求。当宕机的服务器重新启动后，在第一次数据同步之前，eureka 实例之间的数据是不一致的，但是经过一次数据同步之后，实例之间的数据就一致了，这就是通过牺牲数据的一致性，来保证系统的高可用。
以上就是 CAP 定理，希望对你的学习或者工作有所帮助。最后留一道思考题：
你们公司的分布式架构是怎么设计的？
互联网平头哥（id：it_pingtouge）
作者：平头哥