一文看懂分布式CAP理论和BASE理论
一文看懂分布式CAP理论和BASE理论
CAP理论概述
CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这3个基本需求，最多只能同时满足其中的2个。
选项 | 描述 |
|---|---|
Consistency（一致性） | 指数据在多个副本之间能够保持一致的特性（严格的一致性） |
Availability（可用性） | 指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应（不保证获取的数据为最新数据） |
Partition tolerance（分区容错性） | 分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障 |
为什么CAP不可兼得？
该问题等价于：为什么无法同时保证一致性和可用性？
- 首先对于分布式系统，分区是必然存在的，所谓分区指的是分布式系统可能出现的区域网络不通，成为孤立区域的的情况。
- 那么分区容错性（P）就必须要满足，因为如果要牺牲分区容错性，就得把服务和资源放到一个机器，或者一个“同生共死”的集群，那就违背了分布式的初衷。
那么满足分区容错的基础上，能不能同时满足一致性和可用性？
假设我们优先保证一致性 ©
假设有两个节点 N1 和 N2。当我们向 N1 写入数据时，为了确保全局一致性，必须让 N2 的读写操作暂时“冻结”。
只有当 N1 完成数据同步至 N2 后，N2 才能恢复处理读写请求。在此期间，客户端针对N2 的请求要么会收到失败响应，要么会因等待超时而得不到及时反馈。
这意味着，在追求强一致性的过程中，N2 的可用性不可避免地受到了影响，因为它无法始终如一地对所有请求提供即时响应。
再来看看优先保证可用性 (A)
这次，我们不让 N2 的读写操作暂停。即使 N1 正在进行数据写入，N2 也继续处理客户端的请求。但这样一来，N2 可能会基于过时数据作出响应，导致客户端接收到与全局最新状态不一致的结果。
显然，这种情况下，虽然我们保证了 N2 的高可用性（即对所有请求都有响应），却牺牲了数据的一致性。
综上所述，在分布式系统的设计中，由于分区容错性的必然存在，我们无法同时确保一致性和可用性达到理想状态。二者就像是天平的两端，提升一方就意味着另一方的妥协。要根据实际业务需求和容忍度来决定在 CAP 三要素中如何取舍。
CAP对应的模型及应用
CP模型（放弃可用性）
放弃A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
CP模型的常见应用：
- 分布式数据库
- 分布式锁
AP模型（放弃一致性）
要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
AP模型常见应用：
- Web缓存
- DNS
熟悉应用
举个大家更熟悉的例子，像我们熟悉的注册中心 ZooKeeper、Eureka、Nacos 中：
- ZooKeeper 保证的是 CP
- Eureka 保证的则是 AP
- Nacos 不仅支持 CP 也支持 AP
BASE理论
演变过程
BASE（Basically Available、Soft state、Eventual consistency）是基于CAP理论逐步演化而来的。核心思想是即便不能达到强一致性（Strong consistency），也可以根据应用特点采用适当的方式来达到最终一致性（Eventual consistency）的效果。
主要含义
- Basically Available（基本可用）：假设系统出现了不可预知的故障，但还是能用，只是相比较正常的系统而言，可能会有响应时间上的损失，或者功能上的降级。
- Soft State（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
- Eventually Consistent（最终一致性）：在一定时间后，应该到达一个最终的状态，保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间取决于网络延时、系统负载、数据复制方案设计等等因素。