关于微服务:分布式系统中的CAP与BASE理论

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)，来决定数据的一致性；