分布式协议与算法实战
韩健
腾讯资深工程师
23193 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 31 讲
分布式协议与算法实战
15
15
1.0x
00:00/00:00
登录|注册

04 | BASE理论:CAP的碱,追求可用性

思考
如何使用BASE理论
最终一致性
基本可用性
CAP理论
BASE理论

该思维导图由 AI 生成,仅供参考

你好,我是韩健。
很多同学可能喜欢使用事务型的分布式系统,或者是强一致性的分布式系统,因为使用起来很方便,不需要考虑太多,就像使用单机系统一样。但是学了 CAP 理论后,你肯定知道在分布式系统中要实现强一致性必然会影响可用性。比如,在采用两阶段提交协议的集群系统中,因为执行提交操作,需要所有节点确认和投票。
所以,集群的可用性是每个节点可用性的乘积,比如,假设 3 个节点的集群,每个节点的可用性为 99.9%,那么整个集群的可用性为 99.7%,也就是说,每个月约宕机 129.6 分钟,这是非常严重的问题。 而解决可用性低的关键在于,根据实际场景,尽量采用可用性优先的 AP 模型。
讲到这儿,可能会有一些同学“举手提问”:这也太难了,难道没有现成的库或者方案,来实现合适的 AP 模型?是的,的确没有。因为它是一个动态模型,是基于业务场景特点妥协折中后设计实现的。不过,你可以借助 BASE 理论帮助你达成目的。
在我看来,BASE 理论是 CAP 理论中的 AP 的延伸,是对互联网大规模分布式系统的实践总结,强调可用性。几乎所有的互联网后台分布式系统都有 BASE 的支持,这个理论很重要,地位也很高。一旦掌握它,你就能掌握绝大部分场景的分布式系统的架构技巧,设计出适合业务场景特点的、高可用性的分布式系统。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

BASE理论是CAP理论中的AP的延伸,强调可用性。它的核心是基本可用(Basically Available)和最终一致性(Eventually consistent)。基本可用是指在出现不可预知的故障时,允许损失部分功能的可用性,保障核心功能的可用性。最终一致性则是指系统的所有副本经过一定时间的同步最终达到一致的状态。在实践中,可以通过流量削峰、延迟响应、体验降级、过载保护等方法实现基本可用。这些策略在12306订票系统等实际案例中得到了应用,有效地保障了系统的核心功能可用性。通过理解和应用BASE理论,可以帮助开发者灵活地处理分布式系统中的突发问题,提升系统的可用性。 最终一致性是指系统中所有的数据副本在经过一段时间的同步后,最终能够达到一个一致的状态。在实践中,可以通过读时修复、写时修复和异步修复等方式实现最终一致性。此外,推荐同时实现自定义写一致性级别,让用户可以自主选择相应的一致性级别,以满足不同业务需求。 在实践中,可以通过分片和多副本实现基本可用,同时通过写时修复和异步修复实现最终一致性。BASE理论的应用主张通过牺牲部分功能的可用性,实现整体的基本可用,以及实现数据的最终一致性。它在很大程度上解决了事务型系统在性能、容错、可用性等方面的痛点,尤其在NoSQL系统设计中得到广泛应用。 总的来说,BASE理论的核心思想是在分布式系统中,通过牺牲强一致性获得高可用性,并通过各种策略和修复机制来保障系统的可用性和数据的一致性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式协议与算法实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(38)

  • 最新
  • 精选
  • lupguo
    在系统过载情况,一方面考虑提供有损服务,弃朱保帅,另一方面积极寻求资源扩容,提升整体系统的吞吐量 1. 流量错峰(不同地区售票时间错峰出售) 2. 异步处理(买票排队,基于队列先收到用户买票请求,排队异步处理,延迟响应) 3. 服务降级(看到非实时数据,采用缓存数据提供服务) 4. 过载保护(熔断/限流,直接拒绝掉一部分请求,或者当请求队列满了,移除一部分请求,保证整体系统可用) 5. 故障隔离(出现故障,做到故障隔离,避免影响其他服务) 6. 弹性扩容(基于Metric和Monitor实现系统态势感知,做到弹性伸缩)

    作者回复: 加一颗星:)

    2020-03-30
    49
  • cricket1981
    All、Quorum、One、Any一致性级别中One和Any的区别是什么?

    作者回复: one表示必须写成功一个节点,any表示所有节点都没写成功,如果请求成功保存到了失败重传的缓存队列中,也算成功。any是最弱的写一致性级别。

    2020-02-20
    31
  • Purson
    还有熔断和限流。 发现文稿里面关于最终一致性中,写的描述有矛盾:“写时修复:在写入数据,检测数据的不一致时,进行修复。” 后面 “在这里,我想强调的是因为写时修复不需要做数据一致性对比,性能消耗比较低,” 前面说写的时候有做一致性对比,后面说写的时候没有做一致性对比。其实写的时候修复主要通过失败重试的方式吧?

    作者回复: 加一颗星:),是的,通过写操作的失败错误,发现不一致,然后通过重传修复数据的不一致。

    2020-02-19
    3
    20
  • ヾ(◍°∇°◍)ノ゙
    acid是数据库系统经典之作;base是在实践中受挫后的思想松绑,提出一种重要的指导,给人以信心

    作者回复: 加一颗星:),互联网只能base,可用性和钱,低性能堆机器,都是钱:)

    2020-02-20
    15
  • Sinclairs
    从微服务的角度来考虑, 有这些方式能够尽可能地保证系统的基本可用: 1. 使用消息队列, 对偶然的高并发写操作进行削峰填谷; 2. 对进程间的服务调用做好熔断保护; 3. 在系统能力无法支撑高并发访问时, 对非核心业务降级; 4. 对关键服务做好限流.

    作者回复: 加一颗星:)

    2020-02-19
    2
    10
  • fcb的鱼
    实现最终一致性的方案中,更侧重于存储层面的事情吧。假设有A,B,C三个节点,那么"读时修复"方案是不是意味着每个读操作,会同时访问这三个节点吗,然后比对三个节点返回的数据是否一样,一样的话返回任意一个节点的数据,不一样了再以最新的数据为准,并且修复其他不同节点的数据?在AP模型的应用中,是不是得同时校验几个节点的数据是否一致?

    作者回复: 每种方案,都有自己比较适合的场景的,比如读时修复,在实现了Quorum NWR时,意义比较大,因为,本来就需要读多副本,发现不一致了,就顺便修复。 在AP模型系统中,一般是需要实现异步修复的,不过具体的技术方案,还是取决于场景。 咱们这么理解哈,技术是解决场景问题的,使用哪些技术?如何使用技术?是取决于场景的,也就是需求。

    2020-02-20
    8
  • NEO🍋
    All、Quorum、One、Any 是什么?没有介绍; 读写时修复 异步修复 又是个什么?修复什么?为什么需要修复?怎么修复?没讲清楚 难以理解 记住; 建议优化讲课方式 关键术语前置介绍 关键动作配合案例(不是一个大而泛的案例-比如文中的自研库 而是非常具体的数据例子)

    作者回复: 加一颗星:),感谢反馈。修复的是数据的不一致性,因为为了实现最终一致性。All、异步修复,在11、12讲有更细节的介绍,已修正,加链接。关于文中案例,或者没有细节案例演示的内容,比如读时修复,我后面会迭代和补充。

    2020-04-23
    7
  • 远方
    hadoop的hdfs文件系统和kafka消息队列,按我的理解,也是基于ap的扩展base理论开发的,是这样的吧?

    作者回复: 这两个之前没怎么研究过。这样哈,这个问题我先记下,后面,我研究下,做个补充:)

    2020-02-21
    5
    6
  • hello
    重试、幂等、异步、负载均衡、故障隔离、流量切换、自动扩缩容、兜底(熔断限流降级)、容量规划

    作者回复: 加一颗星:)

    2020-02-19
    6
  • 川杰
    请问:写时修复:在写入数据,检测数据的不一致时,进行修复;这个比对,是指和其它节点数据比对吧?那么数据以谁为准呢?极端情况下,每个节点上的数据都不一样,我该听谁的?

    作者回复: 可以这么理解,写时修复,写失败时,将数据缓存到本地磁盘上,然后周期性的重传,本质上,就是失败重传。 第二个问题,所有数据,都不一样,这时现实场景肯定会出现的情况,可以通过多次执行异步修复,来实现一致性。具体的实现方法,我会在11讲,具体说说:)

    2020-02-19
    5
收起评论
显示
设置
留言
38
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部