分布式系统设计理论: CAP,BASE

CAP 定理的核心含义就是，发生故障时，开发者必须选择，优先满足一致性还是可用性。
https://codahale.com/you-cant-sacrifice-partition-tolerance/

CAP理论

概念

1. 一致性（Consistence）
   所有节点访问同一份最新的数据副本
2. 可用性（Availability）
   非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
3. 分区容错性（Partition tolerance）
   分布式系统出现网络分区的时候，仍然能够对外提供服务。
   网络分区：节点之间不连通，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。

CAP 定理（CAP theorem）

对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个

CAP定理关注的粒度是数据，而不是整体的架构。

• 思考：
  1. 分布式系统为了性能得有多节点，节点之间网络中断就会导致分区，如果一个分区没有其他分区的数据就会导致这个分区不可用
  2. 要分区容错性的2个方案：1单节点不产生分区，2每个节点都有全量数据
  3. 每个节点都有全量数据，同步数据需要时间，会产生节点间数据不一致问题。
  4. 要确保所有节点数据同步一致，那在同步过程中就不能对外提供服务，产生可用性问题
  5. 所以：无法全部满足

3种方案区别

• CA-单点集群，满足一致性可用性的系统，
  扩展能力不强
• CP-满足一致性、容错性的系统，
  现在实现方法就是加读锁 性能不高
• AP-满足可用性、容错性的系统，
  一致性要求低一些。

不是所谓的“3 选 2”

加州大学的布鲁尔在提出来CAP的时候并没有对CAP三者进行详细的定义，所以在网上也出现了不少对CAP不同解读的声音。
CAP 之父在 2012 年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。

分区容错性 P 是一定要满足

1. 如果系统发生“分区”，我们要考虑选择 CP 还是 AP。
2. 如果系统没有发生“分区”的话，我们要思考如何保证 CA 。

分布式系统理论上不可能选择 CA 架构

原因:

1. 分布式肯定会有多节点, 在写操作时要满足Consistency（一致性） , 就不能在其他节点进行读写操作
2. 禁止其他节点的读写操作, 就不满足Availability（可用性）

如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了
支持CA的系统, 一定不是真分布式, 肯定会有全局锁的情况

https://zhuanlan.zhihu.com/p/55053121

---

BASE 理论

BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的
是对 CAP 中 AP 方案的一个延伸和补充

1. Basically Available（基本可用）
   允许损失部分可用性。绝不等价于系统不可用
   1. 响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
   2. 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。
2. Soft-state（软状态）
   允许系统中的数据存在中间状态, 数据不一致, 但该中间状态的存在不会影响系统的整体可用性
3. Eventually Consistent（最终一致性）
   系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态

强一致性与最终一致性

• 强一致性：A成功，B失败，则回滚A
• 最终一致性：A成功，B失败，则想办法让B成功
  （RocketMQ的半消息,消息回查,重试机制,以及xxl-job捞失败的核心参数走相应逻辑,最终人工兜底）

核心思想

AP 方案 + 最终一致

• 牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

BASE 理论延伸的地方

• 只是在系统发生分区故障的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。