高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9202 人已学习
课程目录
已更新 38 讲 / 共 40 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计？
免费
基础篇 (6讲)
01 | 高并发系统：它的通用设计方法是什么？
02 | 架构分层：我们为什么一定要这么做？
免费
03 | 系统设计目标（一）：如何提升系统性能？
04 | 系统设计目标（二）：系统怎样做到高可用？
05 | 系统设计目标（三）：如何让系统易于扩展？
06 | 面试现场第一期：当问到组件实现原理时，面试官是在刁难你吗？
演进篇 · 数据库篇 (5讲)
07 | 池化技术：如何减少频繁创建数据库连接的性能损耗？
08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？
09 | 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？
10 | 发号器：如何保证分库分表后ID的全局唯一性？
11 | NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？
演进篇 · 缓存篇 (6讲)
12 | 缓存：数据库成为瓶颈后，动态数据的查询要如何加速？
13 | 缓存的使用姿势（一）：如何选择缓存的读写策略？
14 | 缓存的使用姿势（二）：缓存如何做到高可用？
15 | 缓存的使用姿势（三）：缓存穿透了怎么办？
16 | CDN：静态资源如何加速？
加餐 | 数据的迁移应该如何做？
演进篇 · 消息队列篇 (6讲)
17 | 消息队列：秒杀时如何处理每秒上万次的下单请求？
18 | 消息投递：如何保证消息仅仅被消费一次？
19 | 消息队列：如何降低消息队列系统中消息的延迟？
20 | 面试现场第二期：当问到项目经历时，面试官究竟想要了解什么？
用户故事 | 从“心”出发，我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构：每秒1万次请求的系统要做服务化拆分吗？
22 | 微服务架构：微服务化后，系统架构要如何改造？
23 | RPC框架：10万QPS下如何实现毫秒级的服务调用？
24 | 注册中心：分布式系统如何寻址？
25 | 分布式Trace：横跨几十个分布式组件的慢请求要如何排查？
26 | 负载均衡：怎样提升系统的横向扩展能力？
27 | API网关：系统的门面要如何做呢？
28 | 多机房部署：跨地域的分布式系统如何做？
29 | Service Mesh：如何屏蔽服务化系统的服务治理细节？
演进篇 · 维护篇 (5讲)
30 | 给系统加上眼睛：服务端监控要怎么做？
31 | 应用性能管理：用户的使用体验应该如何监控？
32 | 压力测试：怎样设计全链路压力测试平台？
33 | 配置管理：成千上万的配置项要如何管理？
34 | 降级熔断：如何屏蔽非核心系统故障的影响？
高并发系统设计40问
登录|注册
04 | 系统设计目标（二）：系统怎样做到高可用？
唐扬 2019-09-25
你好，我是唐扬。
开课之后，有同学反馈说课程中偏理论知识的讲解比较多，希望看到实例。我一直关注这些声音，也感谢你提出的建议，在 04 讲的开篇，我想对此作出一些回应。
在课程设计时，我主要想用基础篇中的前五讲内容带你了解一些关于高并发系统设计的基本概念，期望能帮你建立一个整体的框架，这样方便在后面的演进篇和实战篇中对涉及的知识点做逐一的展开和延伸。比方说，本节课提到了降级，那我会在运维篇中以案例的方式详细介绍降级方案的种类以及适用的场景，之所以这么设计是期望通过前面少量的篇幅把课程先串起来，以点带面，逐步展开。
当然，不同的声音是我后续不断优化课程内容的动力，我会认真对待每一条建议，不断优化课程，与你一起努力、进步。
接下来，让我们正式进入课程。
本节课，我会继续带你了解高并发系统设计的第二个目标——高可用性。你需要在本节课对提升系统可用性的思路和方法有一个直观的了解，这样，当后续对点讲解这些内容时，你能马上反应过来，你的系统在遇到可用性的问题时，也能参考这些方法进行优化。
高可用性（High Availability，HA）是你在系统设计时经常会听到的一个名词，它指的是系统具备较高的无故障运行的能力。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(37)
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-25 8 52
Jxin1.本篇讲得主要是系统设计层面的服务高可用。降级，限流，超时熔断，好像主要大方向就这些了。（走mq销峰这种，我认为也是一种降级）。
2.从运维来看，上k8s后，编排控制下，自动维护运行的服务实例节点数量算（包括无状态和有状态服务），这算是一个高可用方面的方案。
3.从部署架构来看，单机房的集群，主备，redis es的多副本等等也算。扯远点还有同城异地，异城异地以及搭建灾备中心等高成本操作。（主要看系统不可用带来的损失有多大，进而做决定）。
总之工作中，感觉追求系统高可用比追求高性能难太多。作者回复: 其实都挺难的：）
2019-09-25 10
mickey希望老师能带来大家一步步设计出一个系统，从简单到复杂，演化出一个高并发、高可用、高性能、可扩展的系统。可以模拟遇到具体的问题，使用什么方法去解决。作者回复: 好滴~
2019-09-25 6
sun我觉得思想最重要，光教你们具体的人家用过的实际案例，那不过是画饼充饥，每个公司的业务都完全不同，侧重点也不同，掌握了思想，明白了了设计方案和要注意的点，接下来只不过是考验个人思维严谨程度和代码水平，思想大于奇淫技巧作者回复: 👍👍👍
2019-09-26 2 5- mickey希望老师能带来大家一步步设计出一个系统，从简单到复杂，演化出一个高并发、高可用、高性能、可扩展的系统。可以模拟遇到具体的问题，具体使用什么方法、使用哪些工具去解决。
作者回复: 好滴~
2019-09-25 5 
Fourty Seven高可用思路，
1.开发设计层面
冗余---主备，负载均衡，failover
取舍----降级，限流，熔断，超时控制
2.运维层面
灰度发布，故障演练，监控报警作者回复: 👍
2019-10-10 3
Julien老师您好，我们产品中用到了MongoDB自带的集群来达到高可用性，但发现当某个节点出现故障时，MongoDB大多数时候并不能自我恢复，从而极大影响了用户体验。对于这种案例，老师有什么好的建议?作者回复: 可以配置replica set，这样主节点故障，付节点可以提升为主节点
2019-09-26 2
任鹏斌讲的思路很清楚，虽然以前也知道高性能高可用，但没看过这么全面的总结。作者回复: 谢谢~
2019-09-25 2- 饭团看来基本就是，避免单点！做好熔断，限流措施！理念是这样。静待老师讲解具体手段，和分享老师的经验！
作者回复: 好嘞~
2019-09-25 2 
小喵喵RPC是什么？是一个调用远程接口的工具，还是一个什么框架？作者回复: Remote Procedure Call，是跨进程调用的方式
2019-09-28 1
罗招材高可用，感觉本质上是冗余，所有关键路径避免单点。
核心要解决的问题是，故障发现 和 故障转移。 故障发现包括，超过处理流量做限流、熔断等，同时某个环节的某个节点故障时，系统能自动转移到冗余备份上，复杂点在于如何保证转移的可靠性。作者回复: 可以这么说吧，不过限流熔断感觉还不是冗余，是一种取舍
2019-09-26 1 1- Lim微服务就是很好的实践。Hystix的降级，熔断。Ribbon的负载均衡。还有zookeeper主备选主Paxos
作者回复: 是的，这些组件归根结底都是使用的文中提到的方法
2019-09-25 1 1 
Lugyedo看来高可用需要DevOps作者回复: 是dev + ops的共同努力~
2019-09-25 1
北天魔狼希望老师在以后章节中推荐一些性能检测工具作者回复: 监控和压测都是性能检测工具
2019-09-25 1
wangbo限流算是个兜底策略吧作者回复: 是的，对业务是有损的
2019-09-25 1
小陈客户端用尽线程不会挂掉吧，应该是没有多余线程再请求了，慢请求也不会导致雪崩吧？作者回复: 客户端指的是调用方~
2019-12-09
🐒王子 ♡桃桃。感谢老师，收获很大作者回复: 谢谢：）
2019-11-29
woshicai主要的高可用手段
1. 限流，原因在于业务核心功能依赖第三方，第三方已经给出拐点，根据给出的数据进行限流；
2. 运维： docker化，不过现在都是k8s了，后续估计还要继续改进；
3. failover： 这个基本都有，重试+约定超时时间，不过这个超时时间一般不出线上问题就不会改了。
4. 提高MTTR， MTBF因为第三方不可控，佛系了
需要改进的点： 灰度上线+故障演练，这个说实话需要正规的运维，目前比较欠缺。2019-11-24
布小丫学编程我的项目中是使用Dubbo框架自带的负载均衡策略，以及Dubbo自带的失败重试功能，还有Dubbo的超时时间设置。还有一次秒杀中使用Hystrix来限流。2019-11-19
峰我记得老师有个文章中说到应用中始终都会存在一个单点，并提到nginx和keepalived，不知道是哪一篇了2019-11-06
收起评论