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

Posted 来老铁干了这碗代码

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式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。

  1. 在没有分区的情况下,如果ClientA向Server1发送修改X=1的指令,在进行事务机制将Server1的X修改为1后,Client1从Server1获取到的X也会是1。因为Client读取到的值一定是最新值,所以这里符合一致性,但显然不具备分区容错性,也就是说,如果服务器宕机了,那么读写就一定会失败。
  2. 在有分区的情况下,如果ClientA向Server1和Server2发送修改X=1的指令,然而这指令并没有成功发送给Server2,那么Client1和Client从服务器中读取到的X值就不一样了。虽然这里满足了分区容错性,但并不满足一致性,而且如果为了保证一致性,那么在发送指令给服务器时,如果有一个命令没有成功发送,所有服务器都不能接收这个请求,这无疑降低了可用性

    所以这里,可以对CAP的定义有更加明确的声明:
  • 一致性(Consistence)

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

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

  • 可用性(Availability)

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

  • 分区容错性(Partition Tolerance)

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

CAP理论的应用

  1. 在架构设计中,不要把时间浪费在如何设计能满足这三者的完美分布式系统上,应当合理取舍。只能三者取其二
  2. 不同业务对于一致性的要求是不一样的。像是微博点赞,用户对不一致是不敏感的,能容忍相对长的一段时间数据不一致,只要做好交互,并不影响体验;而电商商品价格的显示是具有强一致性的,如果不能保证修改商品价格后的数据一致性,对交易是有很大影响的。
  3. 在CAP理论中并没有将网络延迟需要花费的时间考虑进来,因为只要是事务提交,节点间数据复制是一定要花时间的。

CP和AP架构的取舍

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

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

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

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

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

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

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

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

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

以上是关于分布式CAP理论:为什么CAP理论中的三个指标不能同时满足呢?的主要内容,如果未能解决你的问题,请参考以下文章

图解 CAP 理论

图解 CAP 理论

画图证明CAP理论

分布式架构之「 CAP理论」

分布式理论:CAP是三选二吗?

分布式理论:CAP是三选二吗?