BASE 理论是由 Dan Pritchett 在 ACM 上发表的一篇论文中提出的理论。是在 CAP 理论基础上提出的一种更实际的理论指导,和 PACELC 理论是有些相近的地方的。

BASE 是指 基本可用Basically Available)、软状态Soft State)、最终一致性Eventual Consistency)。

对于目前的互联网应用,基本上都不会是单机系统,而是多机分布式系统,所以 CAP 中的 P 是一定要的特性。剩下的 C P 根据实际场景取舍。BASE 就是一种取舍方案的指导。

假设我们微服务系统结构是:

假设我们系统有如下几个业务需求:

  1. 查询账户余额(涉及账户微服务)
  2. 商品下单(涉及账户微服务,订单微服务,商品微服务)
  3. 商品剩余库存(涉及商品微服务)
  4. 查看用户订单(涉及订单微服务,商品微服务)

1. 基本可用(Basically Available)

基本可用主要包括三点:

  1. 目前系统能承受的压力范围内的请求是正常处理的,超过范围的可能处理不正常,但是不能因为这些请求影响正常的请求。
  2. 响应时间正常,在压力大的时候,响应时间可能增长,但是不能超过一定时间
  3. 可以忍受一定的功能损失,在某些系统出问题的时候,其他系统应该保证本身业务接口正常的运行。

1.1. 目前系统能承受的压力范围内的请求是正常处理的

在双 11 的时候,用户量会突然增高,并且这个量很难预测,尤其是商品下单的业务压力会增大很多,可能超过系统的极限。在超过系统极限的时候,可能会导致整个系统都不可用(例如超过超时极限导致很多请求在队列排队导致后续请求也排队从而雪崩),这是不可取的。

所以,一般会考虑动态扩容,根据业务压力,进行相应的系统微服务的扩容。并且由于动态扩容一般具有滞后性,还需要加上限流器,对某些敏感业务请求根据微服务数量进行动态限制,防止雪崩的出现。

1.2. 响应时间正常

在闲时,用户请求下单可能是毫秒级返回,在系统压力大的时候,这个响应时间可以适当加大,例如 3s 返回。但是这个响应超时时间不要设置太长,第一影响用户体验,第二会导致更多请求排队。

对于不同的业务接口最好设置不同的响应超时时间,例如查询账户余额超时时间短一些,查看用户订单可以稍微长一些。

可以根据系统接口的平均响应时间,请求的个数,制定系统扩容策略

1.3. 可以忍受一定的功能损失

这个主要在于微服务的拆分,以及服务降级策略

比如现在商品微服务因为压力过大挂了,或者重启,这时候的业务:

  1. 查询账户余额(涉及账户微服务),这个由于微服务隔离不受影响
  2. 查询商品剩余库存(涉及商品微服务),这个系统挂了,需要服务降级,例如返回商品库存加载中(前端定时查询),或者商品库存为 0.
  3. 商品下单,目前不可用
  4. 查看用户的订单,可能里面的商品信息显示不出来(服务降级),但是订单列表,以及其中的订单金额、交易时间信息等等应该可以展示,而不是整个接口报异常。

2. 软状态(Soft State)

指的是允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时。

例如下单,订单可以有 初始化 -> 已冻结金额 -> 已扣库存 -> 已扣款 -> 下单成功 这几个状态,如果扣库存失败则变为 待解冻金额 -> 下单失败 状态,分别对应下单的几个中间逻辑。除了下单成功下单失败以外,其他的都是软状态,并不是最终状态。基本上所有的软状态都需要对应的补偿任务。有了这些中间状态,即使系统重启,也可以通过这些中间状态补偿重试将下单逻辑走下去。

查询订单的时候,在已冻结金额状态之后的订单就可以展示给用户看了,在下单成功之前,都可以显示为处理中。在扣库存失败之后,可以显示为退款中

3. 最终一致性(Eventually Consistent)

上面提到的软状态,并不会一直保持在这个软状态,而是最终通过系统正常逻辑或者补偿逻辑走向最终状态,各个节点也会同步这个最终状态,这就是最终一致性。

Werner Vogels针对这个最终一致性,总结了五种实现最终一致性的不同场景方案,分别是:

  • Causal consistency(因果一致性)
  • Read-your-writes consistency(读你所写一致性)
  • Session consistency(会话级别一致性)
  • Monotonic read consistency(单调读一致性)
  • Monotonic write consistency(单调写一致性)

在实际的实践中,这 5 种设计方案往往会互相结合使用,以构建一个具有最终一致性的分布式系统。

3.1. Causal consistency(因果一致性)

因果关系的意思是进程 A 的修改会通知进程 B,没有因果一致性的就是进程 A 的修改不会通知进程 C。对于有因果关系的进程,他们访问的数据应该是强一致性的,没有这个关系的走的是最终一致性。

举一个例子,用户查看商品库存的请求是非常巨大的,并且能接受一点时间内的不一致。假设为了应对这么大的请求,这个库存在商品微服务实例本地也缓存了一份,并且会随着收到下单请求就会将缓存失效重新获取扣库存后最新的库存量,同时这个缓存 5s 后一定会过期(真正扣库存不会使用这个缓存,这个仅仅展示用)。那么下单请求通过订单微服务 RPC 请求的商品微服务实例上面的库存就是最新的库存,其他实例的库存可能有点滞后性。

3.2. Read-your-writes consistency(读你所写一致性)

进程 A 在更新了数据项之后,总是访问更新的值,永远不会看到旧的值。这是因果一致性模型的一个特例

3.3. Session consistency(会话级别一致性)

在同一个会话内的修改,是可以立刻读取到最终修改的。在其他会话可能不会立刻读取到。

例如数据库的主从同步,请求在这个会话内写入主数据库,那么主数据库会话能立刻读取到这个修改,根据数据库的双 1 同步配置,默认情况下,只有同步完成后才能读取到这个修改。

3.4. Monotonic read consistency(单调读一致性)

如果一个节点从系统中读取出一个数据项的某个值后,那么系统对于该节点后续的任何数据访问都不应该返回更旧版本的值。

3.5. Monotonic write consistency(单调写一致性)

系统要保证同一个节点的写操作是顺序执行的。

微信搜索“我的编程喵”关注公众号,每日一刷,轻松提升技术,斩获各种offer

2021-2-20:请你说说分布式系统 BASE 理论是什么?的更多相关文章

  1. 分布式系统的BASE理论

    一.BASE理论 eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结,在ACM上发表文章提出BASE理论,BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(St ...

  2. 分布式系统的CAP和BASE理论

    1. 背景 网络分区:俗称“脑裂”.当网络发生异常情况,导致分布式系统中部分节点之间的网络延时不断变大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够进行正常通信,而另一些节点则不能. 当网 ...

  3. 2021.07.20 P3951 小凯的疑惑(最大公因数,未证)

    2021.07.20 P3951 小凯的疑惑(最大公因数,未证) 重点: 1.最大公因数 题意: 求ax+by最大的表示不了的数(a,b给定 x,y非负). 分析: 不会.--2021.07.20 代 ...

  4. 2021.07.20 CF1477A Nezzar and Board(最大公因数,未证)

    2021.07.20 CF1477A Nezzar and Board(最大公因数,未证) CF1477A Nezzar and Board - 洛谷 | 计算机科学教育新生态 (luogu.com. ...

  5. 分布式系统中的CAP原理和BASE理论

    CAP是一致性(Consistency).可用性(Availability).分区容忍性(Partition tolerance)的缩写.CAP原理指的是这三个要素最多只能同时实现两点,不可能三者兼顾 ...

  6. 从分布式一致性谈到CAP理论、BASE理论

    问题的提出 在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景. 1.火车站售票 假如说我们的终端用户是一位经常坐火车的旅行家,通常他是去车站的售票处购买车票,然 ...

  7. 分布式之 BASE理论

    ------------------------------珍惜眼前的学习机会,当你现在有机会学习各种经验时,一定要倍加珍惜.靠混日子是混不了一辈子的,许多过程都是不能省略的,至少学会这些经验可以让你 ...

  8. 【分布式】1、CAP原则(CAP定理)、BASE理论

    CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性). Availability(可用性).Partition tolerance(分区容错性),三者不可得兼. CA ...

  9. 分布式系统理论--CAP理论、BASE理论

    问题的提出 在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景. 1.火车站售票 假如说我们的终端用户是一位经常坐火车的旅行家,通常他是去车站的售票处购买车票,然 ...

随机推荐

  1. 七:Spring Security 前后端分离登录,非法请求直接返回 JSON

    Spring Security 前后端分离登录,非法请求直接返回 JSON 解决方案 在 Spring Security 中未获认证的请求默认会重定向到登录页,但是在前后端分离的登录中,这个默认行为则 ...

  2. (七)整合 Redis集群 ,实现消息队列场景

    整合 Redis集群 ,实现消息队列场景 1.Redis集群简介 1.1 RedisCluster概念 2.SpringBoot整合Redis集群 2.1 核心依赖 2.2 核心配置 2.3 参数渲染 ...

  3. Django(orm)转

    转载自 https://www.jianshu.com/p/d92ecd3644f7?utm_campaign=hugo&utm_medium=reader_share&utm_con ...

  4. Django(静态文件or路由)

    静态文件 在开发中同创会使用到 css,js,img等静态文件,这里带大家简单的介绍一下django如何处理静态页面, 配置 setting.py文件 STATIC_URL = '/static/' ...

  5. PHP-mysql存储照片的两种方式

    PHP-mysql存储照片的两种方式 方式一:把图片数据存储在数据库中(二进制) 数据库代码: CREATE TABLE `photo` (    `id` int(10) unsigned NOT ...

  6. F - Cheapest Palindrome

    有一个长度为m的字符串,由n种小写字母组成.对应的n种字母在这个字符串加上或者减去都有相应的费用,现在要将这个字符串变成回文串,问最低消费是多少? Keeping track of all the c ...

  7. K - Japan(线段树)

    Japan plans to welcome the ACM ICPC World Finals and a lot of roads must be built for the venue. Jap ...

  8. Educational Codeforces Round 9 C. The Smallest String Concatenation(字符串排序)

    You're given a list of n strings a1, a2, ..., an. You'd like to concatenate them together in some or ...

  9. Codeforces Round #555 (Div. 3) C2. Increasing Subsequence (hard version) (贪心)

    题意:给你一组数,每次可以选队首或队尾的数放入栈中,栈中元素必须保持严格单增,问栈中最多能有多少元素,并输出选择情况. 题解:首先考虑队首和队尾元素不相等的情况,如果两个数都大于栈顶元素,那么我们选小 ...

  10. 2017, X Samara Regional Intercollegiate Programming Contest B.Pursuing the Happiness (string函数)

    题意:给你一个字符串,可以交换两个字符的位置,问操作后能否在字符串中找到子串\("happiness"\),如果不能,输出交换的两个位置. 题解:这题其实用string中的find ...