CAP原则、Base理论和常见分布式问题

Posted on

CAP 原则基本概念

CAP 原则(Principle)也叫 CAP 定理，指的是在一个分布式系统中，一致性、可用性、分区容错性三者不可兼得。

  • Consistency(一致性) 分布式系统中的所有主机在同一时刻是否可以保证具有完全相同的数据备份，若具有，则该分布式系统具有一致性
  • Availability(可用性) 在集群中，部分节点发生故障后，是否会影响对客户端读写请求的响应。注意，若在短时间内会影响，其也不具有”可用性”

  • PartitionTolerance(分区容错性) 分布式系统的各个网络结点就是网络分区(Partition)，不可避免的会出现由于网络问题导致结点间通信失败，此时仍可以对外提供服务，这就是分区容错性

  • 为什么说三者不可兼得？ 在上述三个属性中，分区容错性是分布式系统必须具有的特性。为了保证高可用，我们可以增加结点数量，但由于网络延迟等问题会导致结点间数据不一致； 反过来为了提高一致性，减少结点数量，则会导致可用性差，比如只有一台主机的情况下主机宕机会导致整个系统不可用。

三二原则

如上分析，在 CAP 中 P 是必须保证的，而 C、A 之间相互存在矛盾，所以对分布式系统来说最终只能选择满足 CP 或 AP 的组合，这就是三二原则。

  • CA 组合 不是分布式系统，没有分区(单机)。比如关系型数据库，比如用 RAID 实现同时备份。
  • AP 组合 加强可用性，放弃立即一致性(强一致性)，追求最终一致性。比如 SpringCloud-Eureka(注册中心)，通过多个结点保证可用性。

  • CP 组合 强调一致性，放弃容错性。比如 Zookeeper，在 master 宕机后选举 leader 过程中服务不可用。

  • 在分布式系统中，AP 运用较多，因为它放弃强一致性，追求最终一致性，性价比较高。比如”微信提现 2 小时内到账”，在用户可接受范围内保证了最终一致性。

BASE 理论

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。 BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用，但要保证核心功能可用， 允许数据在一段时间内是不一致的，但最终达到一致状态。满足 BASE 理论的事务，我们称之为“柔性事务”。

  • Basically Available(基本可用) 分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。 如，电商网站交易中付款出现问题了，商品依然可以正常浏览。
  • Soft state(软状态) 由于不要求强一致性，所以 BASE 允许系统中存在中间状态(也叫软状态)，这个状态不影响系统可用性。 如订单的”支付中”、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
  • Eventually consistent (最终一致性) 最终一致是指经过一段时间后，所有节点数据都将会达到一致。 如订单的”支付中”状态，最终会变为“支付成功”或者”支付失败”，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待 。

AKF 问题

对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲。 但是随着时间的向前，系统规模的增长，除了面对性能与容量的问题外， 还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务变化带来的差异化服务问题。

《可扩展的艺术》提出了分布式系统的可扩展模型——AKF 可扩展立方(Scalability Cube) 这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。 X 水平复制，通过绝对平等地复制服务与数据，以解决容量和可用性的问题。 Y 按服务功能拆分，每个服务实现一组相关的功能。 Z 数据分区，按服务和数据的优先级或某种序号段划分数据。

  • 以 Redis 为例解释 X、Y、Z:
    • X 主从复制，解决单点故障、容量问题
    • Y 按不同业务拆分使用不同的 Redis，实现逻辑隔离
    • Z 用分区(分片)模式，解决数据量大的问题