设计模式之美
王争
前 Google 工程师,《数据结构与算法之美》专栏作者
123426 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 113 讲
设计模式与范式:行为型 (18讲)
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

91 | 项目实战一:设计实现一个支持各种算法的限流框架(设计)

验证设置的合理性
时间粒度和限流值选择
集成使用设计
分布式限流设计
算法选择与扩展
配置规则设计
RateLimiter-Spring类库设计
松耦合设计
低侵入设计
低延迟设计
高容错设计
分布式限流
单机限流
扩展性设计
漏桶限流算法
令牌桶限流算法
滑动时间窗口限流算法
固定时间窗口限流算法
配置文件加载方式
时间粒度选择
配置文件格式支持
语法格式定义
面向对象实现
面向对象设计
划分模块
系统设计
非功能性需求
功能性需求
课堂讨论
重点回顾
集成使用
限流模式
限流算法
限流规则
实现
设计
需求分析
项目背景
设计实现一个支持各种算法的限流框架

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

上一节课,我们介绍了限流框架产生的项目背景,并且对需求做了分析,这其中包括功能性需求和非功能性需求,算是在正式开始设计之前的一个铺垫。
前面提到,我们把项目实战分为分析、设计、实现三部分来讲解。其中,分析环节跟之前讲过的面向对象分析很相似,都是做需求的梳理。但是,项目实战中的设计和实现,跟面向对象设计和实现就不是一回事儿了。这里的“设计”指的是系统设计,主要是划分模块,对模块进行设计。这里的“实现”实际上等于面向对象设计加实现。因为我们前面讲到,面向对象设计与实现是聚焦在代码层面的,主要产出的是类的设计和实现。
今天,我们分限流规则、限流算法、限流模式、集成使用这 4 个模块,来讲解限流框架的设计思路。上节课我们提到,限流框架的基本功能非常简单,复杂在于它的非功能性需求,所以,我们今天讲解的重点是,看如何通过合理的设计,实现一个满足易用、易扩展、灵活、低延时、高容错等非功能性需求的限流框架。
话不多说,让我们正式开始今天的学习吧!

限流规则

框架需要定义限流规则的语法格式,包括调用方、接口、限流阈值、时间粒度这几个元素。框架用户按照这个语法格式来配置限流规则。我举了一个例子来说明一下,如下所示。其中,unit 表示限流时间粒度,默认情况下是 1 秒。limit 表示在 unit 时间粒度内最大允许的请求次数。拿第一条规则来举例,它表示的意思就是:调用方 app-1 对接口 /v1/user 每分钟的最大请求次数不能超过 100 次。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了设计实现一个支持各种算法的限流框架的设计思路,包括限流规则、限流算法、限流模式和集成使用四个模块。在限流规则方面,框架支持多种配置文件格式,并提供兼容其他数据源获取配置的方式。在限流算法方面,介绍了常见的限流算法,并强调了固定时间窗口限流算法的应用和扩展性设计。同时,讨论了限流模式的单机限流和基于Redis实现的分布式限流。文章通过详细的技术讲解,为读者提供了设计限流框架的思路和方法,使读者能够快速了解限流框架的设计特点和实现原理。此外,还提到了框架的易用性、灵活性、易扩展性、低延迟和高容错的设计需求,以及如何满足这些需求。文章还探讨了如何选择合理的时间粒度和限流值以及验证设置的合理性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《设计模式之美》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(16)

  • 最新
  • 精选
  • 马以
    限流框架文档哪里可以看到?

    作者回复: https://github.com/wangzheng0822

    2020-06-01
    5
    17
  • cricket1981
    背压等于限流吗?如果是的话,要如何实现基于HTTP的restful api背压?

    作者回复: 限流<你说的背压。如何做压力测试,你可以看下我github上的文章:https://github.com/wangzheng0822

    2020-06-25
    2
  • cricket1981
    这种限流是不是应该结合物理资源监控动态调整比较好?

    作者回复: 太复杂了~效果并不一定好~

    2020-06-25
    1
  • 小晏子
    在不同的业务场景下,对于每个接口,时间粒度和限流值的选择都是不同的,比如在平时和大促(如618,11.11)时,因为服务器数量不同,所以选择也不同,比如在618时,流量可能都集中在几秒内,TPS 会非常大,几万甚至几十万,需要选择相对小的限流时间粒度,相反,如果接口 TPS 很小,则使用大一点的时间粒度,比如限制 1 分钟内接口的调用次数不超过 1000 。 对于限流值的选择,需要结合性能压测数据、业务预期流量、线上监控数据来综合设置,最大允许访问频率不大于压测 TPS,不小于业务预期流量,并且参考线上监控数据。 如何验证设置的合理性?可以通过导流的方式将流量集中到一小组机器上做真实场景的测试,并记录下每个请求的对应接口,请求时间点,限流结果,进行分析。另外我们还需要时刻监控限流的工作情况,实时了解限流功能是否运行正常。一旦发生限流异常,能够在不重启服务的情况下,做到热更新限流配置。
    2020-06-01
    1
    106
  • Jie
    以前在耗子叔专栏看到过动态流控的文章(左耳听风49节),可以借鉴了TCP使用RTT来探测网络延时和性能,从而设定相应滑动窗口,根据调用方一段时间内响应时间的P90或P99值,来作为限流的参考。这个一样可以用在限流框架上的。
    2020-06-01
    2
    33
  • Jxin
    1.限流值的大小一般在预估流量~压测流量满足响应时长下的最大吞吐之间。 2.时间力度的选择要看场景。首先明确一点,时间力度越小,流量峰值则越小。服务群能否正常提供服务,看的是流量峰值是否小于压测流量最大值(拐点)。那么在整点秒杀这种场景,时间力度就要尽可能小,结合人机检验和先抢购买权等策略降低并发度后,时间窗口应该也能使用。但如果是阿里京东这种大型电商公司的双11,时间窗口就不合适了,除非你的集群规模大于当前时间力度的最大峰值(并行度很可能真达到峰值),不然限流策略都很难保护服务群。而这样的规模服务,在serverless普及前,成本是接受不了的(请求上来时服务瞬间扩容,过去后又瞬间缩容)。这时采用类似均速发牌的算法就合适些。而在平时业务稳定期,时间力度就可以长一些,因为这个时候流量比较平缓,峰值一般都不会很高,只需要做粗力度的流量控制即可。 3.验证是否合理:模拟或则镜像流量压测不能压垮服务,且尽量去减少计算资源。满足稳定服务的前提下,尽量减少计算成本。用合适的成本,提供稳定的服务才叫合理。
    2020-06-01
    3
    12
  • 迷羊
    可以先测试自己的应用调用接口的次数,合理的使用。怎么验证合理性,主要还是看具体的应用调用次数,可以测出来的。
    2020-06-01
    3
  • Jackey
    实践一下吧,可以拿正常的线上流量回放保证不被限流。再用压测流量压一下,保证服务不down就ok
    2020-06-01
    2
  • test
    思考题:需要结合线上流量的情况,包括均值和峰值
    2020-06-01
    2
  • 程序员小跃
    项目里现在就是从单一的程序进行拆分到多个,有公用的模块,有独立的模块,但是还不是很熟练,还在摸索中前进。看到评论区都说很有收获,这实战,我得看好几遍利用起来
    2020-10-19
    1
收起评论
显示
设置
留言
16
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部