分布式系统中的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)，来决定数据的一致性；