高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9308 人已学习
课程目录
已更新 42 讲 / 共 45 讲
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:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (7讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
35 | 流量控制:高并发系统中我们如何操纵流量?
36 | 面试现场第三期:你要如何准备一场技术面试呢?
实战篇 (2讲)
37 | 计数系统设计(一):面对海量数据的计数器要如何做?
38 | 计数系统设计(二):50万QPS下如何设计未读数系统?
高并发系统设计40问
登录|注册

35 | 流量控制:高并发系统中我们如何操纵流量?

唐扬 2019-12-13
你好,我是唐扬。
上一节课里,我带你了解了微服务架构中常见的两种有损的服务保护策略:熔断和降级。它们都是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性。但是,并不是所有的场景下都可以使用熔断降级的策略,比如,电商系统在双十一、618 大促的场景。
这种场景下,系统的峰值流量会超过了预估的峰值,对于核心服务也产生了比较大的影响,而你总不能把核心服务整体降级吧?那么在这个时候要如何保证服务的稳定性呢?你认为可以使用限流的方案。而提到限流,我相信你多多少少在以下几个地方出错过:
限流算法选择不当,导致限流效果不好;
开启了限流却发现整体性能有损耗;
只实现了单机的限流却没有实现整体系统的限流。
说白了,你之所以出现这些问题还是对限流的算法以及实际应用不熟练,而本节课,我将带你了解这些内容,期望你能将这些经验应用到实际项目中,从而提升整体系统的鲁棒性。

究竟什么是限流

限流指的是通过限制到达系统的并发请求数量,保证系统能够正常响应部分用户请求,而对于超过限制的流量,则只能通过拒绝服务的方式保证整体系统的可用性。限流策略一般部署在服务的入口层,比如 API 网关中,这样可以对系统整体流量做塑形。而在微服务架构中,你也可以在 RPC 客户端中引入限流的策略,来保证单个服务不会被过大的流量压垮。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 阿土
    令牌桶以及漏桶算法的分布式实现有可以参考的么?

    作者回复: guava 的RateLimit

    2019-12-13
    2
  • leslie
    这周刚开始学习老师的课程,算法训练营刚基本结束,就继续开始知识的强化,下周老师基本上能赶上进度,学习中可能会在后续的提出一些前面课程的困惑希望老师不吝赐教。
       限流的用户体验太差了:令牌桶算法和漏桶算法确实不错,有生产环境用限流不过体验非常差,每年次数不多且.net系的似乎没用好的策略,故而都是暴力的增加带宽去解决。
        老师在课程小结前面的"我们可以在每次取令牌的时候,不再只获取一个令牌,而是获取一批令牌,这样可以尽量减少请求 Redis 的次数。"这个其实稍有问题,个人觉得改成"我们可以在每次取令牌的时候,不再只获取一个令牌,而是通过MQ获取一批令牌,这样可以尽量减少请求 Redis 的次数。"更为符合生成环境的操作。
        数据系统/中间件存储已经不再是当初的CS或BS开发架构:高并发分布式架构其实就是要充分利用这些组件,带来的问题就是运维复杂。不过我记得陈皓老师说过"运维优先,做平台的思路就是一定要能维护好",这其实是许多中小企业不重视的方面且觉得无所谓的方面,从而导致了大量设计思路的错误,造成了大量的不必要的高并发。有时加个组件就能完成-前提是你对它足够了解。
         今年在中小电商平台经历过其多套系统,典型的问题还是系统的合理性已经维护的问题带来了大量的高并发,数据系统中的某些组件性能优化做到后相比过去有了极其显著的提升,让慢查询比例缩短至过去10-15%,可是依然在某些峰之上还是有问题。流量控制其实涉及到的不是数据库而是数据系统和整体系统的性能维护,这是我觉得很多技术负责人没有看到的问题。
         期待老师后续的分享:后续的课程中会有一些前面的问题,还望老师不吝赐教-谢谢。

    作者回复: 加油~

    2019-12-13
    2
    2
  • 台风骆骆
    听老师的课,每次都有收获,给老师点个赞。
    限流方式有如下:
    1、固定窗口
    2、滑动窗口
    3、漏斗,一般用队列来实现,但是会造成请求有延迟并且也对处理突发流量不友好。
    4、令牌桶,通过往桶内定时放入一个令牌,请求过来时先要申请到令牌才能继续,否则请求失败,这个对于处理突发流量时比较友好,即平时可以攒,到突发流量时可以直接用起来,guava的ratelimiter就是令牌桶算法实现的,分布式令牌桶可以用redis来实现,可以一次申请多个而不是一个这样可以降低每次请求的开销。

    作者回复: 赞总结,谢谢~

    2019-12-13
    1
  • Keith
    接着上个问题(好像二次回复通知不到作者), 所以相对于漏桶算法, 为什么推荐使用令牌桶算法呢?
    2019-12-20
  • JackJin
    原话:我们可以在每次取令牌的时候,不再只获取一个令牌,而是获取一批令牌,这样可以尽量减少请求 Redis 的次数。
    那么获取的一批令牌没使用完,怎么处理呢?或者是基于什么去判断这一批令牌的数量?

    作者回复: 你在请求的时候就要消耗令牌,如果请求的时候发现令牌没有了,就是消耗完了

    2019-12-19
  • 知行合一
    感觉都是知道一些概念但是都没有深入展开
    2019-12-18
  • 大鸡腿🍗
    看到评论说业界,没有成熟的方案,这里就要捶你了。开发:rateLimit,semaphore,框架:阿里的sentiel以及它的各种限流产品

    作者回复: 文章中也提到有guava的RateLimit

    2019-12-15
  • Keith
    "而令牌桶算法可以在令牌中暂存一定量的令牌,能够应对一定的突发流量,所以一般我会使用令牌桶算法来实现限流方案", 相对于漏桶算法, 令牌桶算法的优势是保证请求的实时处理吗? 怎么是能够应对一定的突发流量? 漏桶算法也可以应对一定的突发流量, 而且更多(至少多一桶), "能够应对一定的突发流量"这个理由有问题吧?

    作者回复: 是说会允许有突发的流量

    2019-12-14
    1
  • 阿卡牛
    关于动态限流,目前业界应该没有比较成熟的方案,可以借鉴TCP 协议的拥塞控制的算法。TCP 使用 RTT - Round Trip Time 来探测网络的延时和性能,从而设定相应的“滑动窗口”的大小,以让发送的速率和网络的性能相匹配,可以借鉴在我们的流控技术中。

    作者回复: 有一些令牌桶算法的实现

    2019-12-13
  • 阿卡牛
    很详细,就是对鲁棒性这个翻译比较不满,不知道是不是业界对robust的统一叫法了。第一眼看真是不明觉厉:(

    作者回复: 额 中国式英语

    2019-12-13
  • 斐波那契
    这两个方法也是阿里在用的方法 阿里有一本书叫决战双11中提到的限流 就是这两个方法

    作者回复: 是通用的做法

    2019-12-13
  • Loony
    每次获取一批令牌数,如何确保请求的准确下发呢?

    作者回复: 这个只是获取多个令牌,不会影响请求的下发的

    2019-12-13
  • 阿土
    前不久做了一个一句话需求:同一个用户每5秒只能提交一次订单,每天只能提交最多200次订单。采用的方式就是固定窗口请求计数的粗爆算法,简单快捷。最终每天的请求量汇总用来做数据分析。我在考虑是不是可以用令牌桶算法来实现地更优雅一些呢?

    作者回复: 可以的,固定窗口应该会有所说的边界问题

    2019-12-13
收起评论
13
返回
顶部