CAP理论详解

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

微服务架构下，一个业务操作必须经过多个服务，每个服务有自己独立的数据库，造成一个业务操作必然在多个数据库实例中执行，必须达到多个数据库实例同时成功或者失败的效果，才能实现这个业务操作。所以必须对数据库进行协调来保证整个系统数据的一致性。

---

一、CAP理论

有一个理论，对于分布式系统的设计影响非常大，那就是 CAP 理论。它为分布式事务提供了一个目标，一个理论依据。为什么是理论依据，这个后面再说，先来说一下CAP三个特性的详细含义。

1、一致性(Consistency):一致性是指写操作后的读操作可以读到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。

如上图，商品服务对主数据库进行写入操作，对从数据库进行读取操作。而一致性的特点便是当商品服务写入主数据库成功，则向从数据库查询新数据也成功。反过来也是如此，当商品服务写入主数据库失败，则向从数据库查询新数据也失败。但是从上图我们可以看出这有一个问题，当商品服务向主数据库中成功写入数据以后，主数据库与从数据库在同步的期间，我们对从数据库进行读取，那么就有可能造成数据查询到的数据是旧数据或者是没有的情况。在这里我们可以通过在写入主数据库后向从数据库同步期间将从数据库锁定，待同步完成后再释放的方式保持数据的一致性。说白了就是加锁的方式。

2、可用性(Availability):可用性是指任何事务操作都可以得到响应的结果并且不会出现响应超时或者响应错误的情况发生。

还是上面的这一张图：

同理，商品服务对主数据库进行写入操作，对从数据库进行读取操作。而数据可用性的特点便是从数据库接收到数据查询的请求则立即能够响应数据库查询结果，从数据库中不允许出现响应超时或者响应错误。因为我们要保证从数据库的可用性，所以我们便不可以像上面保持一致性一样将从数据库进行加锁处理。当我们向从数据库查询数据时，即使新的数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但就是不能返回错误或者相应超时。

3、分区容忍性(Partition tolerance)：
通常分布式系统的各个结点部署在不同的子网上，不可避免的会出现由于网络问题而导致结点之间通信失败，此时仍可以对外提供服务，这叫做分区容忍性。(基本能力)

我们还是以上图举例：

主数据库向从数据库同步数据失败是不会影响商品服务对主数据库以及从数据库的读写操作，分区容忍性所具有的特点为其中一个结点挂掉不影响另外一个结点对外提供服务。那我们应该如何实现呢？
我们可以尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据库，这样结点之间能有效的实现松耦合。或者是添加从数据库结点，其中一个结点挂掉其它从结点提供服务。如下：

二、CAP组合方式

一个分布式系统中，不可能同时具备CAP这三个特性。在这样的背景下，根据选择的不同我们可以分为AP(availability + partition tolerance),CP (consistency + partition tolerance),CA (Consistency + Availability)。但是，对于分布式系统而言，部署节点分散，网络故障是常态，分区容忍性P(Partition tolerance)是我们必须要保证的前提。所以在大部分情况下设计分布式系统在具备了P(Partition tolerance)的前提下C(Consistency)和A(Availability)是不能共存的。所以我们在设计系统时，不需要将精力浪费在如何设计满足三者的完美分布式系统，而是应该做出取舍。

1、AP(常见)
放弃一致性，追求分区容忍性和可用性。
业务场景：订单退款（今日退款成功，明日账号到账，只要用户可以接受在一定时间内到账就可以）

2、CP:
放弃可用性，追求一致性和分区容忍性。
业务场景：跨行转账，一次转账请求要等待双方银行系统都完成整个事务才能算完成。

3、CA:
放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。我们最常用的关系型数据库就满足了CA。(不在是标准的分布式系统)

三、总结

对于一个分布式系统而言，无法同时满足 Consistency(强一致性)、Availability(可用性) 和 Partition tolerance(分区容忍性) 这三个条件，最多只能满足其中两个。但需要注意的是虽然说我们设计系统时不能同时保证拥有三点。也不是完全抛弃另外一点。只是另外一点要相对的做出一些牺牲而已。