CAP & BASE理论

1. CAP

• 一致性（Consistency） : 所有节点访问同一份最新的数据副本
• 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）
• 分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务

1.1. 什么是网络分区？

分布式系统中，多个节点之间的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区

1.2. CAP不是3选2这么简单

• CAP最开始听到的答案是：一致性、可用性、分区容错性三者你只能同时达到其中两个，不可能同时达到，确实是这样，但是是片面的
• 正确的是答案是：当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择
• 简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C
• ZooKeeper、HBase：CP；Cassandra、Eureka：AP
• 为啥不可能选择 CA 架构呢？ 举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了
• 选择 CP 还是 AP 的关键在于当前的业务场景，没有定论
• 如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证

1.3. CAP 实际应用案例

就拿注册中心来做实例比较：注册中心负责服务地址的注册与查找,相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小

• ZooKeeper 保证的是 CP： 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的
• Eureka 保证的则是 AP： Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的

2. BASE 理论

BASE 是 Basically Available（基本可用）、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

• BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充
• AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性，这一点其实就是 BASE 理论延伸的地方
• 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用
  • 响应时间上的损失：0.5s->2s
  • 系统功能上的损失：熔断机制
• 软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时：类似与消息队列
• 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

分布式一致性的 3 种级别：

1. 强一致性：系统写入了什么，读出来的就是什么
2. 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态
3. 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态

那实现最终一致性的具体方式是什么呢?

• 读时修复 : 在读取数据时，检测数据的不一致，进行修复
• 写时修复 : 在写入数据，检测数据的不一致时，进行修复
• 异步修复：通过定时对账检测副本数据的一致性，并修复

3. 网路请求路线