转载

架构设计中的 CAP 和 BASE 理论

CAP 定义

在一个分布式系统中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)3者中的2个,另一个必须被牺牲。
这里的分布式系统指的是互相连接并共享数据的节点的集合,互连和共享数据很关键,像 memcache 集群,没有互连和共享数据,就不算是分布式系统。

一致性(Consistence)
对某个指定的客户端来说,读操作保证能够返回最新的写操作结果。

可用性(Availability)
非故障节点在合理的时间内返回合理的响应。

分区容忍性(Partition Tolerance)
当出现网络分区后,系统能够继续履行职责。

在分布式环境下,必须选择 P,因为网络原因可能出现故障,所以分区是一个必然现象。因此,分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP。

CP(一致性/分区容忍性)
例如 N1 和 N2 两个节点,N1 上的数据更新为了y,同步到 N2 之前,网络中断,发生分区,N2 上还是旧的数据 x。

为了保证一致性,当客户端访问 N2 时,N2 不能返回 x,需要提示系统发生了错误,返回 error,这就违背了可用性原则。

file

AP(可用性/分区容忍性)

还是上面的场景,为了保证可用性,N2 返回 x,但不是最新的数据,违背了一致性原则。

file

对于CAP理论,架构设计时要注意以下几点:

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

    CAP理论说分布式系统中这3点无法同时满足,但一定不要理解错误了,不要认为我们在架构设计时,这个系统要么 CP 要么 AP。

    要记住:CAP 关注的粒度是数据,系统中会包含多种类型的数据,有的必须选择 CP,有的必须选择 AP。

    例如用户管理系统,有账号数据(ID、密码),还有用户信息数据(昵称、简介等),账号数据就需要选择 CP(一致性/分区容忍性),用户信息数据对一致性没那么高的要求,就可以选择 AP(可用性/分区容忍性)。

  2. CAP是忽略网络延迟的

    节点间的数据复制一定是需要花费时间的,即使是同一个机房,也需要几毫米,如果是距离较远的异地,耗时可能就是几十到几百毫秒了。

    对于极其严苛的业务场景(例如金钱相关的),是无法做到分布式下的一致性的,只能单点写入,其他节点备份。

    注意:是这个类型的数据无法做分布式,不意味着系统无法应用分布式。

  3. 放弃不等于什么都不做,要为分区恢复后做准备

    CAP告诉我们三者只能取两个,牺牲另一个,网络分区的确是必然存在,但正常情况是可以满足 CA 的。在分区期间需要放弃C或者A,我们要做好准备,分区解决后重新达到 CA。

    例如用户系统,对于账号数据,我们选择了 CP(一致性/分区容忍性),分区发生后,节点1可以继续注册新用户,节点2无法注册,此时我们就要做好数据追平的策略,例如节点1可以将新注册但未同步的用户记录到日志中,当分区恢复后同步给节点2。

    而对于用户信息数据,我们选择了 AP,发生分区后,节点1和节点2都可以修改用户信息,就会产生数据不一致,当分区恢复后,系统按照某个规则来合并数据,例如最后修改优先规则。

BASE 理论

BASE 是指:

  1. 基本可用(Basically Available)

    分布式系统在出现故障时,允许损失部分可用性,保证核心可用。

    例如一个日活千万的系统,登录肯定是核心功能,注册就是非核心。

  2. 软状态(Soft State)

    允许系统存在中间状态,该中间状态不会影响系统整体可用性。

  3. 最终一致性(Eventual Consistency)

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

    BASE理论的核心思想是即使无法做到强一致性,但应用可以采用合适的方式达到最终一致性。

    BASE理论是对 CAP 的延伸和补充,例如 AP 方案中牺牲一致性只是指分区期间,分区恢复后,系统应达到最终一致性。

关于分布式事务的问题,可以加我微信(itsoku)讨论

请关注公众号javacode2018,免费领取年薪40万的资料,更多好文及时推送给您

分布式事务交流群,微信扫码入群,无法进入的加微信号itsoku
file

正文到此结束
本文目录