架构设计中的 CAP 和 BASE 理论

CAP 理论

定义：

在一个分布式系统中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）3者中的2个，另一个必须被牺牲。

这里的分布式系统指的是互相连接并共享数据的节点的集合，互连和共享数据很关键，像 memcache 集群，没有互连和共享数据，就不算是分布式系统。

1. 一致性（Consistence)

对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。

1. 可用性（Availability）

非故障节点在合理的时间内返回合理的响应。

1. 分区容忍性（Partition Tolerance）

当出现网络分区后，系统能够继续履行职责。

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

1. CP（一致性/分区容忍性）

例如 N1 和 N2 两个节点，N1 上的数据更新为了y，同步到 N2 之前，网络中断，发生分区，N2 上还是旧的数据 x。

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

1. AP（可用性/分区容忍性）

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

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

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

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

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

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

1. CAP是忽略网络延迟的

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

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

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

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

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

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

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

BASE 理论

BASE 是指：

1. 基本可用（Basically Available）

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

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

1. 软状态（Soft State）

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

1. 最终一致性（Eventual Consistency）

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

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

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

内容整理自《从0开始学架构》