Base理论和CAP

Base理论和CAP

  1. Architecture 🚢
  2. 4 years ago
  3. 10 min read
CAP基础认知
  • C 代表 Consistency, 一致性, 是指所有分布式节点在同一时刻的数据是完全相同,完全一致的,也就是在执行更新操作并响应用户完成之后,所有节点存储的数据会保持相同
  • A 代表 Available, 可用性 是指系统对外提供的服务功能一致处于可用状态,对于用户的请求可以立即响应
  • P 代表 Partition Tolerance, 分区容错性, 在分布式系统遇到网络分区的情况下,仍然可以响应用户的请求,网络分区是指因为网络故障导致节点之间网络不联通,不同的节点分别处于不同的自网络中,但是各个子网络内部的网络正常

CAP只能同时满足两个目标,由于是分布式环境,所有分区容错是必须要保证的,那么就需要在C和A之间进行取舍

  • 如果需要保证分布式系统的数据一致性,那么就需要在服务的可用性A上让步,采用CP模型
  • 如果需要保证服务的可用性较高,那么就需要在数据的一致性上C让步,采用AP模型

大部分时间下,网络分区是不会发生的,CAP理论适用于在系统设计时候需要衡量的因素,但不是绝对的选择

PACELC理论

pacelc是在CAP的理论基础上进行延伸, 新增了2项考量点:

  • Eventual Consistancy: 在出现网络分区时,由于网络延迟或者异步复制等原因,可能会存在一段时间内多个节点之间的数据不一致,但随着时间推移,最终回答道数据的一致性
  • Latency: 分布式系统的响应时间, 在某些场景下,为了提高系统的响应速度,可能会需要牺牲一点可用性A或者一致性C
Base理论

Base理论的核心思想是达到最终一致性,即使无法做到强一致性,但每个应用应该根据自身的业务特点,采用适当的方式来是系统达到最终一致性

  1. 基本可用(Basically Available): 不追求CAP中的任何时候读写都是成功的,而是字体能够基本运行,一致提供服务,这一点强调了分布式系统在出现不可预知的故障时,允许牺牲部分的可用性, 相比正常系统,可能出现响应时间延长或者服务被降级等情况

    激增的超大流量访问系统时,如果超过了系统的QPS阈值,那么会出现排队或者限流,这就是通过合理手段来保护系统的稳定性,保证主要核心服务政策,保证基本可用

  2. 软状态(Soft State): 软状态对应ACID事务中的原子性,在ACID的事务中,实现的是强一致性,要么不做,要么全部做成功,保证所有用户看到的数据一致,其中的原子性(Atomicity)要求多节点的数据副本完全一致,强调数据的一致性

    原子性可以理解为一种硬状态,软状态则是允许系统中的数据存在中间状态,这种状态不会影响系统的整体可用性,也就是允许系统在多个不同的节点数据副本存在不一致的情况

  3. 最终一致性(Eventual Consistancy): 数据不可能一直是软状态,必须在一定时间阈值之后达到所有节点的全部一致,在期限过后,应当保证所有数据副本保持数据一致性

    最终一致性的视线取决于网络延迟 系统负载 存储介质 数据同步方案等设计因素

CAP在组件中的应用
CP模型

追求的是数据的强一致性,如果一个分布式场景需要很高的数据一致性,可以容忍系统在较长时间内无响应,那么保CP弃A这个策略比较合适

保证CP的系统组件有很多,典型的有Redis HBase Zookeeper等

image-20241007152811728

ZK集群包含多个节点,这些几点会通过分布式选举算法选举ZAB出一个leader节点,除了leader节点外的都是Follower节点,leader节点会专门负责用户的写请求:

  • 当用户向集群发起写请求,如果请求的节点正好是Leader节点,那么就直接处理该请求
  • 如果请求的节点的Follower节点,那么该节点会将请求转给Leader节点,leader节点会首先向所有Follower发出一个Proposal,等待超过半数以上的Follower节点响应后,才会提交本次写操作,从而保证了数据的强一致性 等待半数Follower节点的响应这里就体现了牺牲响应时间(需要等待Follower的ACK),如果某些Follower一致无法响应,那么也会阻塞Leader节点的数据提交和响应,间接也就降低了系统的可用性A

image-20241007153426126

当发生网络分区时,如果其中一个网络分区的节点数大于整体集群节点数量的一半,那么该子分区可以再次选举出一个Leader出来,仍然对外提供服务(选举过程中不能提供服务)

如果没有任何一个子分区的节点数量大于整体集群节点数量的一半,那么整个系统将无法选出一个leader,系统无法正常对外提供服务,必须等到网络回复之后,才能正常提供服务

如果存在多个子分区的节点数量大于整体集群节点数量的一半,那么则会选举出多个leader出来,此时出现脑裂问题,但系统仍然可以对外提供服务

AP模型

追求的是可用性,任何时候都能对外提供服务,容易导致不同节点的数据不一致,最终一致

网络分区出现后,各节点之间数据无法马上进行同步,为了保证高可用,系统需要立即响应用户需求,但可能存在某些节点还没有最新的数据,只能返回旧版本的数据,从而出现数据不一致的情况

适合保证AP放弃C的场景比较多,例如 查询系统, 用户的体验非常重要,所有大多会保证系统的可用性,而牺牲一定的数据一致性, 虽然用户拿不到最新数据,但是这种情况也远好于系统无法响应用户的请求,典型的组建由 COACHDB Eureka Cassandra DynamicDB Nacos等

image-20241007154808734

数据一致性模型

image-20241007154840303

  • 强一致性: 当更新操作完成之后,任何后续进程的访问都会返回最新的更新后的值
  • 弱一致性: 当数据写入成功之后, 不承诺立即可以读取到最新写入的值,也不会具体承诺多久之后能够读取到, 更新后到用户最终能够读取到最新数据的一段时间称之为 “不一致性窗口”
Distributed Architecture