后端存储实战课
李玥
美团高级技术专家
44006 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语 (1讲)
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

特别放送 | 如何平衡存储系统的一致性和可用性?

增量同步
全量同步
回滚
重试
自动修复不一致问题
状态数据一致性比对
状态版本号
保持会话
多数派机制
一致性约束
最终一致
软状态
基本可用
最终一致性
服务停止
数据同步
更新失败处理
网络分区容忍性
可用性
一致性
数据同步机制
故障恢复
实例状态一致性
复制状态机理论
主从同步
多副本
冗余
防御性设计
保证单调读写
防止脑裂
牺牲强一致性
BASE理论
宽松一致性
避免不必要的副本
网络分区
节点不可用
更新操作难题
CAP理论
分布式系统
数据一致性
高可用性
思考题
实践BASE理论
平衡策略
一致性与可用性的矛盾
核心概念
存储系统的一致性和可用性平衡

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

你好,我是李玥。
非常开心在结课近两年后的今天,我又有机会和你分享这段时间,我对存储技术一点新的思考。
最近我的工作重心有了一些变化,更加关注高可用架构在大规模系统落地工程实践方法。在存储技术领域,对平衡存储系统的一致性和可用性的设计方法,也有了一些新的认知,在这里分享给你。
无论技术如何发展,保证系统高可用最基础也是最本质的方法从没有改变过。相信你已经猜到这种方法是什么了,是的,就是冗余。简单地说,冗余就是为你的系统准备多个副本,或者说是多个实例,它们提供同样的服务,共同工作。这样即使其中一个副本或者实例出现了故障,其它的实例仍然可以替这个故障实例承担工作,保证你的系统持续可用。
对于数据库、KV 存储等存储系统来说,同样是通过冗余,或者说多副本的方法来实现其高可用架构的。但相比于无状态的系统,有状态的存储系统使用这种冗余的方法时,需要额外维护多个副本上的数据一致性。第 13 讲中,我们讲的 MySQL 主从同步,以及在这一讲末尾给你总结的复制状态机理论,就是 MySQL 维护主库和从库数据一致性的方法。
在分布式存储系统中,让系统中多个实例的状态保持一致,是一个比较难处理的问题。尤其是当系统出现故障时,系统能否始终保持一致性,很大程度上影响了系统的可用性和数据的可靠性。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式系统中的一致性与可用性一直是一个难题。文章《一致性与可用性的矛盾》深入探讨了在现有硬件技术条件下,分布式系统中一致性的挑战和解决方案。作者指出,要在分布式系统中同时保证高可用和一致性几乎是不可能的。为了解决这一问题,文章提出了宽松一致性的概念,并介绍了实现方式。同时,文章还讨论了在系统故障时需要更长的时间达成最终一致的问题,并提出了防止脑裂和保证单调读写的方法。总的来说,文章强调了放弃对严格一致性的约束,让系统适应相对宽松一致性,从而在一致性、可用性和性能上取得平衡的理性选择。这些观点对于存储技术领域的从业者具有一定的参考价值,能够帮助他们更好地理解和应对分布式系统中的一致性与可用性挑战。文章提出了在设计分布式系统时需要避免未经仔细思考而随意增加副本的行为,并推荐设计者在设计系统一致性时能够兼容最终一致,从而在一致性和可用性上取得相对较好的平衡。同时,文章还提到了一些防御性设计,如定期比对各副本状态数据的一致性,用于自动发现和修复状态数据不一致的问题。这些观点对于分布式系统设计者具有重要的指导意义,能够帮助他们更好地应对系统设计中的一致性与可用性挑战。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端存储实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(10)

  • 最新
  • 精选
  • 默默且听风
    我以为消息队列高手课给我的启发就够多了,万万没想到,这门课更厉害
    2022-05-05
    5
  • Geek_a8ce05
    我觉得是必要的。系统可能出现各种问题导致数据不一致,有了这层防御性设计,可以更早的发现系统不一致 的问题,避免错误进一步扩大。
    2022-04-04
    4
  • 蓝萧
    思考题: 个人认为不是必要的,1. 数据不一致是因为系统设计或者代码有问题才会出现 2. 大量数据的比对修复速度也很慢。只有在上线新代码可能影响数据一致性时,防御性的设计才会派上用场,用于发现并修复问题。
    2022-02-09
    4
  • 奔跑的小黄牛
    感谢老师的分享!
    2022-01-20
    3
  • 砥砺奋进
    通过定期比对各副本状态数据的一致性,可以及时发现和修复数据不一致的问题,从而避免数据损失或系统崩溃。可以提高系统的可靠性和健壮性,从而确保系统能够在各种情况下都能够正常运行。因此,我认为这种防御性设计是非常必要的。
    2023-03-29归属地:广东
    1
  • 李正g
    我认为有必要,项目执行过程中没有办法100%避免因为人为因素(bug)导致的数据不一致, 通过防御报警机制及时发现问题,人工介入处理是有必要的。 这个防御机制只应该是一个报警机制, 不应该自动修复数据之类的。
    2022-07-28归属地:北京
    1
  • 好运来
    在系统上线的初期可以引入防御式设计自动发现、提醒并修复数据状态不一致的数据,一方面用于修复Bug,另一方面可以提前发现,避免业务逻辑错乱。然后在系统稳定运行期可以逐渐下限这个模块。
    2022-04-29
    1
  • 被过去推开
    个人认为是有必要的。前段时间公司给甲方做数据双轨同步,数据同步过来后,发现很多问题,比如数据不一致,数据丢失等情况。有些数据需要人工对比,人工对比的效率很低。
    2023-06-27归属地:云南
  • ifelse
    点赞
    2022-12-20归属地:浙江
  • piboye
    是不是可以从成本来看, 比如 不可用的损失 > 不一致性的损失 , 就要保可用性; 我们多数业务其实更在意的是可用性; 事后数据恢复的方法, 我们好像讨论都很少, 是因为通用性不够?
    2022-09-19归属地:广东
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部