架构设计中的 CAP 和 BASE 理论
Posted 性能与架构
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了架构设计中的 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，这就违背了可用性原则。
AP（可用性/分区容忍性）
还是上面的场景，为了保证可用性，N2 返回 x，但不是最新的数据，违背了一致性原则。
对于CAP理论，架构设计时要注意以下几点：
CAP 关注的粒度是数据，而不是整个系统
CAP理论说分布式系统中这3点无法同时满足，但一定不要理解错误了，不要认为我们在架构设计时，这个系统要么 CP 要么 AP。
要记住：CAP 关注的粒度是数据，系统中会包含多种类型的数据，有的必须选择 CP，有的必须选择 AP。
例如用户管理系统，有账号数据（ID、密码），还有用户信息数据（昵称、简介等），账号数据就需要选择 CP（一致性/分区容忍性），用户信息数据对一致性没那么高的要求，就可以选择 AP（可用性/分区容忍性）。
CAP是忽略网络延迟的
节点间的数据复制一定是需要花费时间的，即使是同一个机房，也需要几毫米，如果是距离较远的异地，耗时可能就是几十到几百毫秒了。
对于极其严苛的业务场景（例如金钱相关的），是无法做到分布式下的一致性的，只能单点写入，其他节点备份。
注意：是这个类型的数据无法做分布式，不意味着系统无法应用分布式。
放弃不等于什么都不做，要为分区恢复后做准备
CAP告诉我们三者只能取两个，牺牲另一个，网络分区的确是必然存在，但正常情况是可以满足 CA 的。在分区期间需要放弃C或者A，我们要做好准备，分区解决后重新达到 CA。
例如用户系统，对于账号数据，我们选择了 CP（一致性/分区容忍性），分区发生后，节点1可以继续注册新用户，节点2无法注册，此时我们就要做好数据追平的策略，例如节点1可以将新注册但未同步的用户记录到日志中，当分区恢复后同步给节点2。
而对于用户信息数据，我们选择了 AP，发生分区后，节点1和节点2都可以修改用户信息，就会产生数据不一致，当分区恢复后，系统按照某个规则来合并数据，例如最后修改优先规则。
BASE 理论
BASE 是指：
基本可用（Basically Available）
分布式系统在出现故障时，允许损失部分可用性，保证核心可用。
例如一个日活千万的系统，登录肯定是核心功能，注册就是非核心。
软状态（Soft State）
允许系统存在中间状态，该中间状态不会影响系统整体可用性。
最终一致性（Eventual Consistency）
系统中所有数据副本经过一定时间后，最终能够达到一致状态。
BASE理论的核心思想是即使无法做到强一致性，但应用可以采用合适的方式达到最终一致性。
BASE理论是对 CAP 的延伸和补充，例如 AP 方案中牺牲一致性只是指分区期间，分区恢复后，系统应达到最终一致性。
内容整理自《从0开始学架构》
点击 以上是关于架构设计中的 CAP 和 BASE 理论的主要内容，如果未能解决你的问题，请参考以下文章