CAP
CAP: Consistency/Availability/Partition Tolerance
-
Consistency: 一致性
- 不论拜访哪个节点，返回给 client 的数据：要么是相对统一的数据，要么读取失败；
- 一致性强调的不是数据的完整性，而是各节点间的数据统一；
-
Availability: 可用性
- 不论拜访哪个节点，都能返回 client 数据，但不保障是同一份最新的数据；
- 强调服务的可用性，但不保证数据的一致性；
-
Partition Tolerance: 分区容错性
- 分布式系统通知 client: 不论我外部呈现什么样的网络谬误，我会始终运行，提供服务；
- 因为分布式系统波及多节点间的通信，节点间的分区故障是必然会产生的，故分区容忍性是必须要满足的；
CAP 不可能三角
设计分布式系统时，CAP 三个指标不可兼得，只能抉择其中 2 个。
P: 只有有网络交互就肯定呈现提早和数据失落，也就是说分区故障是必然产生的， P 是必须要保障的；
C: 产生网络分区时，当节点收到 client 的写申请，保障大多数节点写入胜利，能力返回 client 写入胜利；否则返回 client 写入失败；
A: 产生网络分区时，当节点收到 client 的读申请，某些节点可能会返回 old 数据；
BASE
BASE: Basically Available/Soft State/Eventually consistent
BASE 实践，能够了解为 CAP 实践中 AP 的延长，是对大规模分布式系统的实际总结，强调可用性。
Basically Available: 根本可用
当系统故障时，容许损失局部性能的可用性，保障外围性能的可用性。
实现服务“根本可用”的罕用办法：
-
流量削峰：
- 业务上将顶峰流量错开，比方 9 点开始第一批用户，10 点开始第二批用户；
- 应用 MQ 将顶峰流量削平，由 MQ 缓存流量，防止将业务打挂；
-
提早响应：
- 接管到用户申请后，返回“已接管，正在解决”，而后后端缓缓的解决，待处理完毕后，发送后果告诉；
-
服务降级：
- 比方对用户的体验降级，比方小图代替大图；
-
过载爱护：
- 比方队列满了当前，间接回绝后续的申请；
Soft state: 软状态
数据正本存在短暂不统一的过渡状态。
Eventually consistent: 最终统一
零碎中的所有正本，在通过一段时间的同步后，最终可能达到一个统一的状态。
实现服务“最终统一”的罕用办法：
-
异步修复：
- 比方 InfluxDB 的 hinted handoff，向向不同节点写数据时，若写失败，将数据缓存起来，而后定时重传，修复数据的不一致性；
-
自定义写一致性级别：
- 在写入数据时，由用户传入一致性级别(All/Quorum/One/Any)，来决定数据的一致性；