所有分类
  • 所有分类
  • 未分类

分布式–CAP定理

简介

本文介绍分布式的CAP定理。

CAP定理概述

说明

一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中的两项。

  1. 一致性(Consistency)
    1. 每次访问都能获得最新数据,但可能会收到错误响应。
  2. 可用性(Availability)
    1. 每次访问都能收到成功的响应(响应时间也正常),但不保证获取到最新数据。
    2. “Reads and writes always succeed”
  3. 分区容错性(Partition tolerance)
    1. 在网络分区的情况下,即使出现单个节点无法可用,系统依然正常对外提供服务。

如何选择

在分布式系统中,在任何数据库设计中,一个Web应用至多只能同时支持上面的两个属性。显然,任何横向扩展策略都要依赖于数据分区。因此,设计人员必须在一致性与可用性之间做出选择。

对于一个业务系统来说,可用性和分区容错性是必须要满足的两个条件,并且这两者是相辅相成的。业务系统之所以使用分布式系统,主要原因有两个:

  • 提升整体性能 :当业务量猛增,单个服务器已经无法满足我们的业务需求的时候,就需要使用分布式系统,使用多个节点提供相同的功能,从而整体上提升系统的性能,这就是使用分布式系统的第一个原因。
  • 实现分区容错性 :单一节点 或 多个节点处于相同的网络环境下,那么会存在一定的风险,万一该机房断电、该地区发生自然灾害,那么业务系统就全面瘫痪了。为了防止这一问题,采用分布式系统,将多个子系统分布在不同的地域、不同的机房中,从而保证系统高可用性。

这说明分区容错性是分布式系统的根本,如果分区容错性不能满足,那使用分布式系统将失去意义。

CAP定理详述

Consistency(一致性)

概念

一致性指“all nodes see the same data at the same time”,即所有节点在同一时间的数据完全一致。

一致性是因为多个数据拷贝下并发读写才有的问题,因此理解时一定要注意结合考虑多个数据拷贝下并发读写的场景。

对于一致性,可以分为从客户端和服务端两个不同的视角。

  1. 客户端
    1. 从客户端来看,一致性指的是并发访问时更新过的数据如何获取的问题。
  2. 服务端
    1. 从服务端来看,则是更新如何分布到整个系统,以保证数据最终一致。

数据一致性的基础理论

从客户端角度,多进程并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性。对于一致性,可以分为强/弱/最终一致性 三类

  1. 强一致
    1. 当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值。
  2. 弱一致性
    1. 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后,不承诺立即可以读到最新写入的值,也不会具体的承诺多久之后可以读到。
  3. 最终一致性
    1. 弱一致性的特定形式。
    2. 经过一段时间后要求能访问到更新后的数据。
    3. 在没有故障发生的前提下,不一致窗口的时间主要受通信延迟,系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。

Availability(可用性)

可用性指“Reads and writes always succeed”,即:每次访问都能收到成功的响应(响应时间也正常),但不保证获取到最新数据。

好的可用性主要是指系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。通常情况下可用性和分布式数据冗余,负载均衡等有着很大的关联。

Partition Tolerance(分区容错性)

分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”,即:分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务。

CAP为什么只能取两个?

CAP的基本场景

上图是我们证明CAP的基本场景,网络中有两个节点N1和N2,可以简单的理解N1和N2分别是两台计算机,它们之间网络可以连通,N1中有一个应用程序A和一个数据库V;N2也有一个应用程序B2和一个数据库V。现在,A和B是分布式系统的两个部分,V是分布式系统的数据存储的两个子数据库。

CAP情景如下:

  • 在满足一致性的时候,N1和N2中的数据是一样的,V0=V0。
  • 在满足可用性的时候,用户不管是请求N1或者N2,都会得到立即响应。
  • 在满足分区容错性的时候,N1和N2有任何一方宕机,或者网络不通的时候,都不会影响N1和N2彼此之间的正常运作。

分布式系统正常运转的流程

上图是分布式系统正常运转的流程,用户向N1机器请求数据更新,程序A更新数据库V0为V1,分布式系统将数据进行同步操作M,将V1同步的N2中的V0,使得N2中的数据V0也更新为V1,N2中的数据再响应N2的请求。

这里,可以定义N1和N2的数据库V之间的数据是否一样为一致性;外部对N1和N2的请求响应为可用性;N1和N2之间的网络环境为分区容错性。

这是正常运作的场景,也是理想的场景,然而现实是残酷的,当错误发生的时候,一致性和可用性还有分区容错性,是否能同时满足,还是说要进行取舍呢?

出现异常

作为一个分布式系统,它和单机系统的最大区别,就在于网络。现在假设一种极端情况,N1和N2之间的网络断开了,我们要支持这种网络异常,相当于要满足分区容错性,能不能同时满足一致性和响应性呢?还是说要对他们进行取舍。

假设在N1和N2之间网络断开的时候,有用户向N1发送数据更新请求,那N1中的数据V0将被更新为V1,由于网络是断开的,所以分布式系统同步操作M,所以N2中的数据依旧是V0;这个时候,有用户向N2发送数据读取请求,由于数据还没有进行同步,应用程序没办法立即给用户返回最新的数据V1,怎么办呢?

有两种选择:

  1. 牺牲数据一致性,响应旧的数据V0给用户;
  2. 牺牲可用性,阻塞等待,直到网络连接恢复,数据更新操作M完成之后,再给用户响应最新的数据V1。

这个过程,证明了要满足分区容错性的分布式系统,只能在一致性和可用性两者中,选择其中一个。

CAP的实际使用

服务的CAP

示例1:Redis

Redis集群是AP架构的:一个节点下线后,其他节点可以正常提供服务。(多个节点下线导致分布式集群不可用的时候,整个集群就不能用了。)

注册中心的CAP

示例:Nacos

Nacos支持AP/CP两种模式,可以任选一种。

Nacos对Nacos节点的管理

Nacos节点默认为CP模式。比如:3台nacos,leader宕机,会进行raft选举,选举期间,没被选成leader的follower是不可用的,单独访问无法使用,被选成leader的candidate是可用的。

Nacos对应用实例的管理

Nacos对应用实例的管理默认为AP模式。

AP模式CP模式
对不可用应用的处理若应用实例的健康检查失败,则将该应用实例标记为不健康,不删除。(Nacos会通过负载均衡等机制保证系统的可用性,虽然可能会造成部分请求失败或超时。)若应用实例的健康检查失败,则从列表中删除该应用实例。(确保系统的数据一致性,但可能会导致短暂的服务不可用。)
健康检查的方法客户端通过心跳上报方式告知nacos服务端健康状态。默认心跳间隔5秒;nacos会在超过15秒未收到心跳后将实例设置为不健康状态;超过30秒将实例删除;nacos服务端主动探知客户端健康状态。默认间隔为20秒;健康检查失败后实例会被标记为不健康,不会被删除。

注册中心支持的项

框架CAP
EurekaAP
NacosAP/CP
ZookeeperCP
ConsulCP
0

评论0

请先

显示验证码
没有账号?注册  忘记密码?

社交账号快速登录