架构学习系列:了解CAP理论

Posted 程序杂烩

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了架构学习系列:了解CAP理论相关的知识,希望对你有一定的参考价值。


CAP 定理(CAP theorem)又被称作布鲁尔定理,对于分布式系统的架构师来说,CAP是必须掌握的理论。对于一个分布式计算系统来说,不可能同时满足以下三点:

  • 一致性(Consistency) 在分布式系统中的所有数据备份,在同一时刻是否是同样的值。

  • 可用性(Availability) 每次请求都能获取到非错的响应,但是不保证获取的数据为最新的。

  • 分区容错性(Partition tolerance)以实际效果而言,分区相当于对通信的时限要求。系统如果不能在同一时限内达成数据一致,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。


根据CAP定理,分布式系统只在同时满足三项中的两项。其原则精髓是要么CA,要么CP,要么AP,但是不存在CAP。理解CAP理论,我们可以认为两个节点分别部署在两个分区。若允许至少一个节点更新状态正常则会导致数据不一致,违背C(一致性)原则。如果为了保证数据一致性,将一个分区的节点设置为不可用,则违背了A(可用性)原则。若两个节点可以互相通信,才能既保证C又保证A,但这又会违背P(分区容错性)原则。

CAP 的关键细节点

NEW


CAP关注的粒度是数据,而不是整个系统

在实际的架构设计中,每个系统不可能只处理一种数据,而是包含多种类型的数据,有的数据必须选择CP,有的数据必须选择AP。如果我们从整个系统的角度去选择AP或者CP,就会发现顾此失彼,无论怎么做都是有问题的。其实在我们实际业务中,也经常遇到这种情况,在电商业务中,对于商品来说,可能有商品表(价格、库存),也有商品信息表(商品的详情、购买说明等),对于商品表来说会选择CP,而对于信息表来说,会选择AP。所以,我们需要将系统的不同应用场景和要求进行分类,每类数据选择不同的策略,而不是直接限定整个系统为同一种策略。


CAP是忽略网络延迟的

忽略网络延迟只是一种假设,在实际业务中,是不可能做到没有延迟的。布鲁尔在定义一致性时,并没有将网络延迟考虑进去。也就是说,当事务提交时,数据能够瞬间同步复制到所有节点。但实际情况是,从A节点复制到B节点,总是要花费一些时间的,同机房可能只需要几毫秒,不同机房可能会消耗几十毫秒,这就意味着C不可能完美的实现,在复制过程中,就会出现数据不一致的情况。


虽然说只有几毫秒,但是在极其严谨的业务情况下,例如金钱余额变动,秒杀场景下商品库存,技术上是无法做到分布式场景下的完美一致性的,而业务上必须要求一致性,所以理论上要求CP,而实际上CP是做不到,只能选择CA。但这并不意味着这类系统无法应用分布式架构,单个业务场景无法做分布式,但系统整理还是可以应用分布式的。


正常运行情况下,不存在CP和AP的选择,可以同时满足CA

CAP理论告诉我们分布式架构只能选择CP或者AP,这里的前提是系统发生了“分区”。如果在没有P的情况下,C和A是都可以保证的。所以,在架构设计时,既要考虑分区情况下选择CP或者AP,又要考虑无分区情况下的CA。


放弃并不是什么都不做,需要为分区恢复后做准备

CAP理论说,三者只能同时取其二,但并不意味着,另外的一什么都不做。在CAP中,我们只能说在分区过程中,无法同时满足C和A,但是“牺牲”的另一个,我们可以在分区期间做一些操作,从而让分区故障解决后,能够重新到达CA的状态。比如,我们经常说到的99.99%可用性系统,一年下来不可用时间只有50分钟,99.999%的可用性系统,一年下来不可用的时间可能只有不到5分钟。

与ACID的关系

NEW



ACID是数据库管理系统为了保证事务的正确性而提出来的一个理论,ACID分别是:
  • Atomicity(原子性) 一个事务中的所有操作,要么全部完成,要么全部不完成,不会在某个环节出错而导致执行不完整。
  • Consistency(一致性 )事务开始之前和结束之后,数据库的完整性不会遭到破坏
  • Isolation(隔离性) 数据库允许多个并发事务同时对数据进行读写和修改。而隔离性可以防止多个事务并发执行时由于交叉执行而导致数据不一致。事务隔离分为四个级别:读未提交(Read Uncommitted)、读提交(Read Committed)、可重复读(Repeatable Read)和串行化(Serilizable)。
  • Durability(持久性 )事务结束后,对数据的修改是永久性的,即使发生故障也不会发生改变。
虽然ACID和CAP中都有CA的特性,但是他们并没有关系。A在ACID是原子性,在CAP是高可用,意义上也完全不同。而C虽然都是一致性,但是ACID是指数据库的数据完整性,而CAP中的C则是指分布式节点中的数据一致性。

与BASE关系

NEW



另一个不得不说的理论是BASE理论。BASE是指基本可用(Basically Available)、软状态(Soft State)、最终一致性(Eventual Consistency),其核心思想是即使无法做到强一致性,但是可以采取一系列的其他合适方式来达到最终一致性。


基本可用(Basically Avaliable) 请输入标题
分布式在出现故障时,允许损失系统的部分可用性,也就是说需要保证核心系统可用。在实际业务中,比如登录相比注册来说,我们需要在系统故障时,保障“登录”可用,可以允许短时间“注册”故障。再比如,在电商业务中,我们需要保障商品正常购买流程的可用性,而可以适当放弃其中的营销组件的可用性。

软状态(Soft State)
允许系统中存在中间状态,但该状态不会影响系统整体可用性。这个状态其实就是数据没到达到一致性。

最终一致性(Eventual Consistency)
系统中的所有数据副本在一定时间内,最终能达到一致性状态。当然,不同的业务场景能容忍的不一致时间是不同的。

BASE理论本质上是对CAP理论的一种延伸和补充。或者说,是对CAP中AP方案的一个补充。

声明:本系列学习内容来自于《从零开始学架构》。另,图片源于网络,若有侵权,请及时联系删除。

以上是关于架构学习系列:了解CAP理论的主要内容,如果未能解决你的问题,请参考以下文章

大白话系列MySQL 学习总结 之 初步了解 MySQL 的架构设计

微服务架构中你必须了解的 CAP 原理

Arm微架构学习系列2——开启Armv9时代

Java 集合系列15之 Set架构

ABP架构学习系列

分布式|跟着“乐哉”学习redis系列教程-redis主从同步