发表于 | 分类于 | 0 | 阅读次数 267

分布式系统之BASE理论

什么是BASE理论

BASE理论起源

BASE理论源于eBay 的架构师 Dan Pritchett 对大规模分布式系统的实践总结，是基于 CAP 理论逐渐演化而来。BASE 是 Basically Available(基本可用)、Soft State(软状态)和 Eventually Consistent(最终一致性)三个短语的缩写。

image-20221110101804029

BASE与CAP关系

在CAP理论下，分布式系统要么尽可能满足AP（追求可用性）、要么尽可能满足CP（追求一致性），而BASE就是对一致性和可用性之间权衡的结果。其核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但每个应用都可以根据自身的业务特点，采用适当方式来达到最终一致性（Eventual Consitency）。

image.png

BASE与ACID区别

ACID 是传统数据库常用的设计理念，追求强一致性模型。BASE 支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

ACID 和 BASE 代表了两种截然相反的设计哲学。ACID 是悲观的，并在每次操作结束时强制保持一致性，而 BASE 是乐观的，并接受数据库一致性将处于不断变化的状态。

基本可用

基本可用指当分布式系统出现不可预知的故障时，允许损失部分功能的可用性来保障核心功能的可用性。

当系统节点出现大规模故障的时候（专线的光纤被挖断、突发流量导致系统过载「出现了突发事件，服务被大量访问」），这个时候可以通过服务降级，牺牲部分功能的可用性，保障系统的核心功能可用。比如常见一些具体案例：

  • 响应事件上的损失: 正常情况下，12306 订票系统查看余座、购买车票、支付成功。但在春运期间，往往会在队列中排队等待处理，可能几分钟或十几分钟。
  • 功能上的损失: 正常情况下，在一个电子商务网站上进行购物，消费者能够顺利完成每一笔订单，但是在一些节目大促销高峰，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级的页面。

可见，基本可用本质上是一种妥协，也就是在系统出现故障时候，通过牺牲非核心功能的可用性，保障核心功能的稳定运行。

常见的一些技术手段：

  • 流量削峰

    • 令牌桶算法：令牌桶的大小固定，令牌的产生速度固定，但是消耗令牌（即请求）速度不固定（可以应对一些某些时间请求过多的情况）；每个请求都会从令牌桶中取出令牌，如果没有令牌则丢弃该次请求。
    • 漏桶算法：漏桶大小固定，处理速度固定，但请求进入速度不固定（在突发情况请求过多时，会丢弃过多的请求）。
    • 计数器：在一段时间间隔内（时间窗/时间区间），处理请求的最大数量固定，超过部分不做处理。

  • 熔度

    • 异常比例：当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。

    • 异常数：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。

    • 慢调用比例：需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。

软状态

软状态是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统不同节点的数据副本之间进行数据同步的过程存在延时。

比如电商系统中，用户下单完成并付款，由于是分布式架构，是否支付成功，是支付模块完成的，系统不会等支付模块返回是否支付成功再把结果返回给客户的，而是先把状态设置为付款中，返回给客户，然后支付模块确定成功，再把状态设置为付款完成。这样，就可以提高系统的相应速度。付款中，就是中间状态。

最终一致性

最终一致性强调是系统所有的数据副本，在经过一段时间同步后，最终能够达到一个一致状态。也就是说，在数据一致性上，存在一个短暂的延迟。

几乎所有的互联网系统采用的都是最终一致性，只有在实在无法使用最终一致性，才使用强一致性或事务，比如，对于决定系统运行的敏感元数据，需要考虑采用强一致性，对于与钱有关的支付系统或金融系统的数据，需要考虑采用事务。

在实际工程实践中，常用的如下3种方式：

  • 读时修复

​ 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据时 候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。

  • 写时修复

​ 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之远 程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性。

  • 异步修复

    这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。比如Cassandra 的反墒修理，在集群中每个节点都周期性随机选择节点池中的一些节点，通过互相交换所有数据来消除两者之间的差异，实现数据的最终一致性。

内容小结

通过BASE理论学习，我们知道BASE理论面向的是大型高可用可扩展的分布式系统。BASE理论在NOSQL中广泛应用，是NOSQL系统设计的事实上的理论支撑。

如果不是必须的话，不推荐实现事务或强一致性，鼓励可用性和性能优先，根据业务的场景特点，来实现非常弹性的基本可用，以及实现数据的最终一致性。