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

Posted 2021-05-01 程序杂烩

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（持久性）事务结束后，对数据的修改是永久性的，即使发生故障也不会发生改变。