04 | 系统设计目标(二):系统怎样做到高可用?
唐扬
该思维导图由 AI 生成,仅供参考
你好,我是唐扬。
开课之后,有同学反馈说课程中偏理论知识的讲解比较多,希望看到实例。我一直关注这些声音,也感谢你提出的建议,在 04 讲的开篇,我想对此作出一些回应。
在课程设计时,我主要想用基础篇中的前五讲内容带你了解一些关于高并发系统设计的基本概念,期望能帮你建立一个整体的框架,这样方便在后面的演进篇和实战篇中对涉及的知识点做逐一的展开和延伸。比方说,本节课提到了降级,那我会在运维篇中以案例的方式详细介绍降级方案的种类以及适用的场景,之所以这么设计是期望通过前面少量的篇幅把课程先串起来,以点带面,逐步展开。
当然,不同的声音是我后续不断优化课程内容的动力,我会认真对待每一条建议,不断优化课程,与你一起努力、进步。
接下来,让我们正式进入课程。
本节课,我会继续带你了解高并发系统设计的第二个目标——高可用性。你需要在本节课对提升系统可用性的思路和方法有一个直观的了解,这样,当后续对点讲解这些内容时,你能马上反应过来,你的系统在遇到可用性的问题时,也能参考这些方法进行优化。
高可用性(High Availability,HA)是你在系统设计时经常会听到的一个名词,它指的是系统具备较高的无故障运行的能力。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了高可用性系统设计的重要性以及系统设计和系统运维两方面的方法。作者强调了“Design for failure”原则,提及了故障转移、超时控制、降级和限流等优化方法的重要性。此外,灰度发布和故障演练成为提升系统可用性的关键手段。文章还提到了混沌工程的思路,通过模拟故障来了解系统在异常情况下的表现。总的来说,本文通过实例和概念的结合,为读者提供了系统设计和系统运维两方面的思路和指导,帮助他们快速了解高可用性系统设计的基本概念和方法。文章还强调了在提高系统可用性时需要权衡用户体验和系统性能,并且不同系统对可用性和性能的要求也会有所不同。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统设计 40 问》,新⼈⾸单¥59
《高并发系统设计 40 问》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(60)
- 最新
- 精选
- jc9090kkk感谢老师的分享,对于文章中的心跳检测我个人认为其实是需要做区分的,心跳检测是区分内部检测和外部检测,外部检测伴随着随机性,有时候可能系统的响应时间或者IO已经出现拐点了,但是心跳机制还是有可能会收到响应包,从而被错误的当做系统是“正常”的,所以很多高可用的系统基本都是采用内部心跳机制,比如kafka中的通过zookeeper的watch机制来做检测来做broker中controller的failover,mysql里面是通过内部的performance_schema库中的file_summary_by_event_name表来做监控,都是为了避免外部监测的随机性所带来的影响,不过对于老师提出的可用性和高性能当中出取舍无比赞同,不同的解决方案总是伴随着优势和劣势,无非是优势所带来的效果比劣势对业务更有帮助而已,比如之前在工作中碰到过mysql主从同步有延迟的情况,mysql的高可能性其实就是靠主备同步的数据一致性来保证的,经过排查发现,业务代码中存在有操作大事务的SQL语句,这个导致从库拿到binlog去做重放的时候,时间周期拖长了,从而影响了业务,另外一个情况就是,在做秒杀的时候,除了采用redis外,还会对用户划分成两部分,一部分用户是来了以后直接报秒杀已结束,另外一部分用户才会进入秒杀的逻辑中,心里觉得还是挺对不住那部分抢不到秒杀的用户的,所以,有时候我们需要在可用性和可靠性上需要做一个取舍,没有十全十美的技术解决方案。除此之外,其实大部分的时候采用的策略是需要对业务尽量是无损的,不然运营和产品会请你喝茶的,最后想跟老师提个建议,就是希望后面的一些篇章,能否尽量将之前提到过的知识点实际运用起来或者说串联起来,并且提供一些实际场景的解决方案细节,我举个例子,比如电商秒杀,秒杀如果只采用mysql去做库存判断,会出现什么的问题,为了避免这样的问题出现,该采用什么系统,假如如果采用redis,为什么?redis的一些操作是原子操作,原子操作是什么?如何保证?类似这样的方案的优缺点和延伸,这样的话既能有效的总结之前学习到的知识点,能够将整个知识网络做一个规整,还能了解到每个技术方案的不足加深理解,从而明白什么样的场景说不能采用当前的技术方案的,还有就是在采用技术方案的同时,说明下采用方案的一些基础的理论,知识,比如cas,或者分布式系统中的cap理论,这样对于基础知识欠缺的人,在学习的时候也可以去补一些平时没有刻意学习的知识,上面是我举的例子,再次谢谢老师的分享,期待后面老师的干货文章。
作者回复: 好嘞,接受你的建议,后面会给出多一些的案例来帮助理解~
2019-09-2516147 - Fourty Seven高可用思路, 1.开发设计层面 冗余---主备,负载均衡,failover 取舍----降级,限流,熔断,超时控制 2.运维层面 灰度发布,故障演练,监控报警
作者回复: 👍
2019-10-10432 - sun我觉得思想最重要,光教你们具体的人家用过的实际案例,那不过是画饼充饥,每个公司的业务都完全不同,侧重点也不同,掌握了思想,明白了了设计方案和要注意的点,接下来只不过是考验个人思维严谨程度和代码水平,思想大于奇淫技巧
作者回复: 👍👍👍
2019-09-26617 - Jxin1.本篇讲得主要是系统设计层面的服务高可用。降级,限流,超时熔断,好像主要大方向就这些了。(走mq销峰这种,我认为也是一种降级)。 2.从运维来看,上k8s后,编排控制下,自动维护运行的服务实例节点数量算(包括无状态和有状态服务),这算是一个高可用方面的方案。 3.从部署架构来看,单机房的集群,主备,redis es的多副本等等也算。扯远点还有同城异地,异城异地以及搭建灾备中心等高成本操作。(主要看系统不可用带来的损失有多大,进而做决定)。 总之工作中,感觉追求系统高可用比追求高性能难太多。
作者回复: 其实都挺难的:)
2019-09-25417 - mickey希望老师能带来大家一步步设计出一个系统,从简单到复杂,演化出一个高并发、高可用、高性能、可扩展的系统。可以模拟遇到具体的问题,使用什么方法去解决。
作者回复: 好滴~
2019-09-2510 - Julien老师您好,我们产品中用到了MongoDB自带的集群来达到高可用性,但发现当某个节点出现故障时,MongoDB大多数时候并不能自我恢复,从而极大影响了用户体验。对于这种案例,老师有什么好的建议?
作者回复: 可以配置replica set,这样主节点故障,付节点可以提升为主节点
2019-09-267 - 长期规划网络跟交通真是很像 限流:对应交通中的限号; 降级:比如火车的站票,人太多,坐座没有了,改为站票,但票价没变,这就是有损服务啊 故障转移:轿车上一般都准备一个备胎。有些人找对象时,也会准备一个备胎,以防主胎出问题了,还可以更换。
作者回复: 赞比喻
2019-12-155 - mickey希望老师能带来大家一步步设计出一个系统,从简单到复杂,演化出一个高并发、高可用、高性能、可扩展的系统。可以模拟遇到具体的问题,具体使用什么方法、使用哪些工具去解决。
作者回复: 好滴~
2019-09-255 - 任鹏斌讲的思路很清楚,虽然以前也知道高性能高可用,但没看过这么全面的总结。
作者回复: 谢谢~
2019-09-254 - 小喵喵RPC是什么?是一个调用远程接口的工具,还是一个什么框架?
作者回复: Remote Procedure Call,是跨进程调用的方式
2019-09-2833
收起评论