分布式系统的妥协——Base定理

大家好,我是徒手敲代码。

上篇文章中,我们介绍了CAP定理,也知道在分布式系统当中,三个特性只能同时满足两个:分区容错性 + 一致性或可用性。想要一致性,就必须舍弃可用性,反之亦然。

想象一下,当我们在网上购物的时候,希望看到的库存数量总是准确无误,这是一致性;而无论何时点击购买都能顺利完成交易,这是可用性。那么如何满足如此苛刻的要求呢?

对此,大佬们提出了一个叫做Base定理的东西,这是一个更加实际的解决方案。它代表了三个原则:

  • 基本可用(Basically Available)

  • 软状态(Soft State)

  • 最终一致性(Eventual Consistency)

下面来逐个解释一下,这三个原则是什么意思,并结合高铁购票系统作为实际场景。

基本可用

这是一门妥协的艺术,它的意思是系统在绝大多数情况下都能提供服务,即使某些功能暂时受限性能下降。注意,某些功能不可用,不代表整个系统都不可用。

这个说白了就是服务降级,在服务器压力过大的时候,将一些非核心业务暂停,优先保证核心业务的正常运行。

比如:春节期间购票高峰期,系统可能会限制某些非关键功能,像如余票的查询速度会稍微变慢,以确保核心的购票流程能够继续进行。这样,尽管体验可能不如平常流畅,但乘客至少还能买到票,系统不至于崩溃。

软状态

软状态指的是,系统中的数据在一段时间内可以处于不一致的状态,直到最终达到一致。系统中的数据不必总是实时同步的,可以允许一定时间内的不一致。

比如:在购票场景中,当一位乘客刚刚在线买了一张票,系统正在处理这个事务,此时其他乘客查询同一车次的余票时,可能会看到旧的、未更新的余票信息。也就是说,在购票操作完成与系统全面更新显示之间,存在一个短暂的时间差,这段时间内系统处于软状态。

最终一致性

最终一致性的意思是,尽管系统在某个时间点可能存在数据不一致,但经过一段时间后,所有的副本都会达成一致。

比如:一个乘客成功购买了最后一张票,但由于网络延迟或系统的异步处理,其他查询渠道暂时显示还有票。但随着时间的推移,所有查询请求最终,都将得到没有余票的准确信息,这就达到了最终一致性。

今天的分享到这里结束了。

关注公众号“徒手敲代码”,免费领取由腾讯大佬推荐的Java电子书!

  • 3
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值