分布式CAP理论：为什么CAP理论中的三个指标不能同时满足呢？

为什么CAP理论中的三个指标不能同时满足呢？春暖花开、鸟语花香，莫要虚度这明媚的春天，一起学一学分布式CAP理论吧~本文主要会对以下问题进行介绍：

 

分布式系统有什么特点？

CAP理论的含义是什么？

为什么CAP三者不能同时满足？

CAP理论怎么应用？

（若文章有不正之处，或难以理解的地方，请多多谅解，欢迎指正）

 

分布式系统的特点

对于分布式系统最简单的理解，就是一组计算机工作，但最终以一台计算机的用户身份显示。简单说，就是由多个不同业务的子系统，共同组成在用户眼中就是一个系统的模式。但这些机器具有共享状态，并不会因其中一个系统节点故障而影响整个系统。

 

分布式系统技术是用来解决什么问题的呢？

分布式系统技术是用来解决集中式架构的性能瓶颈问题，其核心是可扩展性。举个简单的栗子：

 

假如有个大学生想做一个XX校园系统，这时他需要对于系统的数据存储配置只有一个数据库，也就是说，服务器与数据库之间的交互是实时且一对一的：

 

然而这个XX校园系统在版本更新的路上披荆斩棘，从鸡肋Demo系统升级到全省高校都在使用的校园系统，这时如果还将数据放在同一个数据库或者数据表中，会在查询过程中消耗过多的时间，使得响应时间过长，导致用户体验不良，所以进行了分库操作：

 

假如依照用户的名称来进行分库，服务器需要通过代理服务器选定访问数据库。在这里，就需要两个系统来进行向数据库请求数据的操作。

 

所以，分布式系统是通过对服务、存储的扩展，来提高系统的处理能力。通过对多台服务器协同工作，来完成单台服务器无法处理的任务，如高并发或大数据量的任务。

 

因为分布式系统的复杂性，也可能会出现结点之间通信失败，网络分区失败、数据不一致等问题。所以分布式系统也可能出现对单点故障、无状态的需要。

 

单点故障

 

一般在系统中某个组件一旦失效，整个系统就无法工作了，为了避免这种情况，往往会将单点故障作为分布式系统的设计目标之一，因为单点故障，意味着单点不影响整体。

 

无状态

 

服务的无状态，是为了满足部分机器宕机也不影响全部，可用于随时进行扩展的需求。

 

那么在设计分布式系统时需要什么理论作为指导思想呢？这时，让我们掌声欢迎CAP理论出场！

 

CAP代表什么含义

CAP分别是指一致性（Consistency）、可用性（Availablity）、分区容忍性（Partition Tolerance），一般分布式系统只能满足其三项中的两项。

 

一致性（Consistency）

一致性是指“所有节点同时看到相同的数据”，也就是说在更新操作成功并返回到客户端后，所有节点在同一时间的数据完全一致，所有节点所拥有的数据都是最新版本。

 

 

可用性（Availability）

可用性指的是“任何时候，读写都是成功的”，即服务一直可用，而且响应时间在正常范围内。比如系统稳定性到了3个9、4个9，即99.9%、99.99%。

 

这里的N个9对应的就是对可用性的一种描述，叫做SLA，即服务水平协议。

 

分区容错性（Partition Tolerance）

分区容错性是指“当部分结点出现消息丢失，或分区故障时，分布式系统仍然能够继续运行”，即系统容忍网络出现分区，且在遇到某个结点或网络分区之间出现不可达的情况下，仍然能够对外提供满足一致性和可用性的服务。

 

在分布式系统中，P的满足是基本要素，一般是在CP或AP中进行选择，实现更好的C或者提升A的性能。

 

那么CAP理论中的一致性、可用性和分区容忍性不能同时满足呢？

 

CAP理论的证明

为什么CAP不能同时满足呢？

 

下面可以通过反证法来证明。

 

假如有一个实际场景，CAP三者都可以同时满足。由于允许P的存在，则一定存在服务器（Server）之间的丢包，如此则不能保证C。

 

在没有分区的情况下，如果ClientA向Server1发送修改X=1的指令，在进行事务机制将Server1的X修改为1后，Client1从Server1获取到的X也会是1。因为Client读取到的值一定是最新值，所以这里符合一致性，但显然不具备分区容错性，也就是说，如果服务器宕机了，那么读写就一定会失败。

 

在有分区的情况下，如果ClientA向Server1和Server2发送修改X=1的指令，然而这指令并没有成功发送给Server2，那么Client1和Client从服务器中读取到的X值就不一样了。虽然这里满足了分区容错性，但并不满足一致性，而且如果为了保证一致性，那么在发送指令给服务器时，如果有一个命令没有成功发送，所有服务器都不能接收这个请求，这无疑降低了可用性。

 

所以这里，可以对CAP的定义有更加明确的声明：

一致性（Consistence）

 

一致性被称为原子对象，任何的读写都应该看起来像是“原子”的，或串行的。

 

写入数据库后读取数据，一定能读到前面写的内容，所有的读写请求都像是全局排序依次进行。

 

可用性（Availability）

 

对任何非失败节点都应该在有限的时间内给出请求的回应（请求的可中止性）。

 

分区容错性（Partition Tolerance）

 

允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失。

 

CAP理论的应用

在架构设计中，不要把时间浪费在如何设计能满足这三者的完美分布式系统上，应当合理取舍。只能三者取其二。

不同业务对于一致性的要求是不一样的。像是微博点赞，用户对不一致是不敏感的，能容忍相对长的一段时间数据不一致，只要做好交互，并不影响体验；而电商商品价格的显示是具有强一致性的，如果不能保证修改商品价格后的数据一致性，对交易是有很大影响的。

在CAP理论中并没有将网络延迟需要花费的时间考虑进来，因为只要是事务提交，节点间数据复制是一定要花时间的。

CP和AP架构的取舍

其实在实际工程中，可用性和一致性并不是完全对立的，我们往往关注的是如何在保持相对一致性的前提下，提高系统的可用性。

 

至于是使用CP或者AP架构，则取决于业务对一致性的要求。

 

CP架构：放弃可用性，追求一致性和分区容错性

举个栗子，ZooKeeper就是采用了CP一致性。

 

ZooKeeper是一个分布式的服务框架，主要用来解决分布式集群中应用系统的协调和移置性问题。在ZooKeeper中，对应每一个事务操作请求，ZooKeeper都会为其分配一个全局唯一的事务ID，每个事务ID对应一次更新操作，从这些事务ID中可以间接识别出ZooKeeper处理这些事务操作请求的全局顺序。

 

AP架构：放弃强一致性，追求分区容错性和可用性

举个栗子，Eureka就采用了AP可用性。

 

Eureka是Spring Cloud微服务技术栈中的服务发现组件。

 

Eureka的各个节点都是平等的，几个节点挂掉不影响正常节点的工作。剩余节点依然可以提供注册和查询服务，只要有一台Eureka在，就能保证注册服务可用。只不过查看的信息可能不是最新版本，不保证一致性。

————————————————

原文链接：https://blog.csdn.net/NYfor2017/article/details/105285252