CAP理论是分布式系统的基石, 那么base理论就是分布式系统的台阶了,在基石上凿的台阶。
BASE 是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency),核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性。
分布式系统,在出现故障的时候,允许损失部分可用性。
这里的故障首先我们得有个定义:故障可不是说是直接所有系统宕机了(其实这就属于抬杠了)。也就是分布式系统故障,不是我们日常看待的比较细维度的鼓掌,比较你的服务GC问题导致系统超时的,由于你的疏忽导致业务故障的。都不是一个层次的。
还有就是“部分”和“核心”的定义,具体选择哪些作为可以损失的业务,哪些是必须保证的业务,我们得从产品层面去认真分析,也就是说我们可以评估一下这个部分业务在系统中挂掉对用户伤害的程度(也就是说让用户选择,二选一的话他们会选择留下那个)。例如,对于一个用户管理系统来说,“登录”是核心功能,而“注册”可以算作非核心功能。因为未注册的用户本来就还没有使用系统的业务,注册不了最多就是流失一部分用户,而且这部分用户数量较少。如果用户已经注册但无法登录,那就意味用户无法使用系统。例如,充了钱的游戏不能玩了、云存储不能用了……这些会对用户造成较大损失,而且登录用户数量远远大于新注册用户,影响范围更大。
这个软状态看到就很晦涩,我们先来看下是什么意思:“允许系统存在中间状态,而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。”
再仔细想想也不晦涩,想像一个状态的东西它是软的,你压了一下它变为另一种形态,但是这种形态只是暂时的,他仍然会复原到最终状态。这么牵强的解释还挺完美。
系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。
这里的关键词是“一定时间” 和 “最终”,“一定时间”和数据的特性是强关联的,不同的数据能够容忍的不一致时间是不同的。
举一个微博系统的例子,用户账号数据最好能在 1 分钟内就达到一致状态,因为用户在 A 节点注册或者登录后,1 分钟内不太可能立刻切换到另外一个节点,但 10 分钟后可能就重新登录到另外一个节点了;而用户发布的最新微博,可以容忍 30 分钟内达到一致状态,因为对于用户来说,看不到某个明星发布的最新微博,用户是无感知的,会认为明星没有发布微博。“最终”的含义就是不管多长时间,最终还是要达到一致性的状态。
BASE 理论本质上是对 CAP 的延伸和补充,更具体地说,是对 CAP 中 AP 方案的一个补充。前面在剖析 CAP 理论时,提到了其实和 BASE 相关的两点:CAP 理论是忽略延时的,而实际应用中延时是无法避免的。这一点就意味着完美的 CP 场景是不存在的,即使是几毫秒的数据复制延迟,在这几毫秒时间间隔内,系统是不符合 CP 要求的。
因此 CAP 中的 CP 方案,实际上也是实现了最终一致性,只是“一定时间”是指几毫秒而已。AP 方案中牺牲一致性只是指分区期间,而不是永远放弃一致性。这一点其实就是 BASE 理论延伸的地方,分区期间牺牲一致性,但分区故障恢复后,系统应该达到最终一致性。
CAP 是分布式系统设计理论,BASE 是 CAP 理论中 AP 方案的延伸。