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