首页手记戴上 CAP 这顶帽子，又能和面试官扯皮了

戴上 CAP 这顶帽子，又能和面试官扯皮了

标签：

Java

随着微服务和分布式系统的广泛运用，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 定理，希望对你的学习或者工作有所帮助。最后留一道思考题：