22-CAP理论细节

CAP的关键细节

  • CAP关注的粒度是数据,而不是整个系统 CAP理论的定义和解释上,用的都是system、node这类的系统级概念,容易给我们造成误解,认为系统只能选择AP或者CP。但是在实际设计中,系统不可能只处理一种数据,有的数据需要使用AP,有的数据需要使用CP。

    所以在CAP理论落地实践时,我们需要将系统内部的数据按照不同的应用场景和要求进行分类,每类数据选择不同的策略,而不是直接限定整个系统所有的数据都是同一策略。

  • CAP理论是忽略网络延迟的。 布鲁尔在定义一致性时,没有考虑网络延迟,也就是说,当事物提交时,数据可以瞬间复制到所有的节点。但实际上,从一个节点的数据复制到另外一个节点总是要花费一定的时间的,无论是几毫秒,还是几秒。这也就意味是,CAP理论中的C是不可能完美实现的,在数据复制的过程中,节点的数据是不一致的。

    对于某些严苟的业务场景,如金钱相关、库存相关的场景,不要小看这几十毫秒的数据延迟,在技术上是无法做的完美的数据一致性的,但是业务上又要求要做到数据一致性。因此在单个用户帐户金额、单个商品的存在,理论上要求做到CP,而实际上CP做不到,只能选择做到CA。也就是说只能单点写入,其它节点做备份,无法做到分布式情况下的多点写入。

    但是要注意,并不是说这类系统无法做到分布式系统,而是说对于单个用户、单个商品无法做到分布式,但是对于系统整体还是可以应用分布式系统的。下图是其中一种架构:

    Alt

    这种设计存在的明显问题是,一个节点出现故障后,这个节点上的用户就无法进行读写操作了,但对于整个网站来说,可以降低节点故障时受影响的用户的数据和范围。

  • 正常情况下,不存在CP和AP的选择,可以同是满足CA。 CAP理论告诉我们分布式系统下只能选择CP或者AP,但是这里的前提是已经发生了网络分区。如果系统没有发生分区现象,也就是P不存在的时候,我们没有必要放弃C或者A,应该C和A都可以保障。这要求架构设计时,即要考虑分区时选择CP或者AP,也要考虑分区没有发生时如何保证CA

  • 放弃不等于什么都不做,需要为分区恢复后做准备。

    CAP理论告诉我们三者只可以选择二个,在分区期间我们放弃了C或者A,并不意味者永远放弃了C或者A。我们可以在分区期间做一些操作,从而在分区故障解决后,系统能够重新达到CA的状态。

    典型做法就是在分区期间记录一些日志,当分区故障解决后,系统根据日志进行数据恢复,使得重新达到CA的状态。

ACID

ACID是数据库管理中为了保证事务正确性而提出的一个理论。

  • Atomicity(原子性) 一个事务的所有操作,要么全部完成,要么全部不完成,不存在中间状态。
  • Consistency(一致性) 在事物开始之间和事务结束之后,数据库的完整性没有被破坏。
  • Isolation(隔离性) 数据库允许多个并发事务同时对数据进行读和写操作。 -Durability(持久性) 事物处理后,对数据的修改是永久的,即使系统故障也不会丢失。

BASE

BASE是指基本可用(Basically Available)、软状态(Soft State)、最终一致性(Eventual Consistency),核心思想是即便无法做到强一致性,但应该可以采用一定的方法做到最终一致性。

  • 基本可用

    分布式系统出现故障时,允许损失部分不可用,即保证核心业务可用。

    具体选择哪些业务作为可以损失的业务,哪些是必须保证的业务,需要根据具体业务确定。

  • 软状态

    允许系统出现中间状态,而该中间状态不会影响系统整体的可用性。这里的中间状态是指CAP理论中的数据不一致。

  • 最终一致性

    系统中的所有数据副本经过一段时间后,最终所有的数据能够达到一致的状态。

    一定时间和数据特征是强关联的,不同数据能够容忍数据不一致的时间是不一同的。

BASE理论其实是CAP理论的一个补充,具体来说是BASE理论是对AP的一个补充

  • CAP理论是忽略延时的,而实际中延时是不可避免的。

    这意味着完美的CP是不存在的,即使是几毫秒的延迟,在这几毫秒内,系统也是不符合CP的。因为CAP方案中的CP方案,实际上也中只是实现了最终一致性,只是这个"一定时间"是几毫秒而已。

  • AP方案牺牲一致性只是指在分区期间,而不是永远放弃一致性。

    这一点是BASE理论的延伸,分区期间牺牲了一致性,在分区故障结束后,系统应该达到最终一致性。

总结

ACID是数据库事务完整性理论、CAP是分布式系统设计理论、BASE理论是CAP理论中AP方案的延伸。

上次更新: 3 个月前