后端工程师的高阶面经
邓明
前 Shopee 高级工程师,Beego PMC
6888 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 50 讲
后端工程师的高阶面经
15
15
1.0x
00:00/00:00
登录|注册

05|限流:别说算法了,就问你“阈值”怎么算?

你好,我是大明。今天我们来聊一聊微服务架构下的限流功能。
熔断、降级和限流是最常见的三种微服务架构可用性保障措施。和熔断、降级比起来,限流要更加复杂一些。大部分情况下,面试官面试限流就是随便问问算法,最多就是问问 BBR 之类的动态算法。但是有一个问题,很多人都答不好,就是限流需要确定一个流量阈值,这个阈值该怎么算?
今天我就带你深入讨论限流的这个问题。

前置知识

限流是通过限制住流量大小来保护系统,它尤其能够解决异常突发流量打崩系统的问题。例如常见的某个攻击者攻击你维护的系统,那么限流就能极大程度上保护住你的系统。
要想全面掌握限流这个知识点,我们需要深入理解限流的算法、对象,以及限流后的做法。下面我们一个一个来看。

算法

限流算法也可以像负载均衡算法那样,划分成静态算法和动态算法两类。
静态算法包含令牌桶、漏桶、固定窗口和滑动窗口。这些算法就是要求研发人员提前设置好阈值。在算法运行期间它是不会管服务器的真实负载的。
动态算法也叫做自适应限流算法,典型的是 BBR 算法。这一类算法利用一系列指标来判定是否应该减少流量或者放大流量。动态算法和 TCP 的拥塞控制是非常接近的,只不过 TCP 控制的是报文流量,而微服务控制的是请求流量。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了微服务架构下的限流功能,作为保障系统可用性的重要措施之一。文章介绍了限流算法的分类,包括静态算法(如令牌桶、漏桶、固定窗口和滑动窗口)和动态算法(如BBR算法),并探讨了限流对象和限流后的处理方法。作者建议读者掌握各种算法的基本原理,了解公司的限流情况,并为自己打造一个掌握了高可用微服务架构的人设。此外,文章还提到了突发流量和请求大小对限流的影响,以及动态限流算法对问题的缓解作用。总之,了解限流的原理和应用场景将有助于提升技术水平。文章还讨论了如何确定限流阈值,包括通过观测数据、压测、借鉴其他服务的阈值以及手动计算。最后,文章提出了思考题,引发读者对IP限流和业务应该使用哪个点的思考。整体而言,本文内容丰富,涵盖了微服务架构下的限流功能及相关技术细节,对于从事微服务架构开发和运维的技术人员具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端工程师的高阶面经》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(18)

  • 最新
  • 精选
  • 3.0的A7
    获取用户的真实IP,有一下集中方法,分别是应用层方法、传输层方法、网络层方法: 1、应用层方法:X-Forwarded-For 缺点:会被伪造、多个X-Forwarded-For头部、不能解决HTTP和SMTP之外的真实源IP获取的需求 2、传输层方法:利用 TCP Options 的字段来承载真实源 IP 信息、Proxy Protocol、NetScaler 的 TCP IP header 3、网络层:隧道 +DSR 模式 贴一下参考(照抄)来源吧:https://time.geekbang.org/column/article/497864

    作者回复: 优秀优秀!哈哈哈,能够找准资料也是一种能力!

    2023-06-26归属地:北京
    19
  • 虎虎生威的程坚强
    一般代理服务器把http请求转发到下一个节点时,会在http header头中加入“X-Forwarded-For”字段,用以记录这个请求从哪里来的,所以看这个字段的第一个值就是原始的用户ip

    作者回复: 赞!要小心 X-Forwarded-For 是可以伪造的。

    2023-06-26归属地:广东
    8
  • penbox
    1. 针对 IP 限流是一个非常常见的限流方案,那么怎么获取用户的 IP 呢?尤其是在请求经过网关的情况下,怎么避免拿到的是网关的 IP ? 可以是用 HTTP 请求头中的,X-Forwarded-For(XFF)自定有头字段。可以获取客户端的真实地址,还可以获取整个请求链中的所有代理服务器 IP 地址。 但要注意 X-Forwarded-For 头是可伪造的字段。 2. 我在阈值里面提到的 ABC 三点,你能说出你的业务应该使用哪个点吗? 我觉得需要根据系统的整体情况来考虑。 如果系统很少会触发阈值,可以考虑 B 点,追求最大并发数。触发限流之后,系统一般阻塞下,扛一扛就过去了。 如果系统长时间在阈值附近徘徊,说明系统性能已经接近极限了,就算把请求阻塞下,最后多半也是超时。这个时候选 C 点更好,最大吞吐量,能处理掉最多的请求。 如果系统对性能要求苛刻,比如整条链路超时时间很短,那就只能选 A 点,最大化性能。但凡请求的响应时间长一点,可能就整体超时了。

    作者回复: 赞!

    2023-07-03归属地:四川
    4
  • 有何不可
    限流还分单机限流和集群限流两种模式。单机限流即每台实例维护自己的计数器,而集群限流则是共用一个中央模式的计数器; 单机限流有以下特点: 1、会出现误限的情况,比如说有两台实例 A 和 B,每个单机限流阈值为 10,那么整体限流阈值是 20,但是如果出现负载不均,某一秒 A 接收的请求是 15,B 接收的请求是 5,那么根据单机阈值,A 将放行 10 个请求,B 放行 5 个请求,这一秒内实际只承接了 15 个请求,而我们的期望是 20; 2、无法很好的设置精确的限流值,一般情况下,单机限流阈值 = 整体限流阈值 / 实例数。比如说实例数有 50 个,但是想要 80 的限流值就无法精确匹配。 单机限流阈值设置为 1 的情况下整体限流阈值只有 50 ,单机限流阈值设置为 2 的情况下整体限流阈值则达到了 100。 3、如果整体限流值不变,实例进行扩、缩容是单机限流阈值要跟着更新单机限流阈值; 集群限流的特点: 1、使用中央模式的计数器,不会出现单机限流出现的误限、无法精确匹配限流值以及扩、缩容调整问题,限流值比较准确; 2、依赖提供中央技术器的服务,如果该服务不可用,那么限流功能将不可用,此时可以考虑降级到单机限流;

    作者回复: 总结很到位! 单机限流第三点是值得讨论的。因为本身在单机限流的时候,你可以不再考虑集群整个流量限制多少了。比如说每台机器限流 100,已经有两台了,也就是整个限流是 200。但是如果你再加一个机器,这个机器其实也可以限流 100。 这也就是说,你单机限流是从单机的处理能力角度考虑的。

    2023-06-29归属地:北京
    2
  • spark
    老师,能不能每次更新的章节多一点,因为课程题目是面经,那么订阅的人肯定目前都是有面试需求的,拜托了

    作者回复: 在努力写了,尽量更新!

    2023-06-27归属地:浙江
    2
  • sheep
    "这个 50 充分考虑到了公共 IP 的问题",这里指的是,用户可能连这个wifi或者另外一个wifi,又或者使用流量。以至于ip不一样,这种情况么

    作者回复: 不是。比如说,我和女朋友在家里用一个路由器,又或者运营商给我们整个小区的公共 IP 都是同一个。或者你可以认为,你到某地连上 wifi 之后,可能共享这个 wifi 的所有人,在对外的 IP 都是同一个。

    2023-09-04归属地:广东
    1
  • nadream
    关于贵公司的监控,可以详细展开说说吗,怎么破?

    作者回复: 已经离职了,不好说了。不过你可以参考别的大厂出来做的分享,他们很喜欢分享 xxx 系统的监控之类的主题。

    2024-01-16归属地:浙江
  • Geek_6c2524
    请问老师,QPS和吞吐量有什么区别?Jmeter通常展示的结果里的throughput(吞吐量)好像就是QPS;这两者在您的图里面有什么区别呢?

    作者回复: QPS 侧重的是请求数量,吞吐量侧重的是任务数量或者数据数量。在互联网里面,这两个是很接近的,但是在批处理之类的场景里面,这两者会有点区别。

    2024-01-12归属地:上海
  • 梦倚栏杆
    关于压测和阈值我想问,一个服务肯定有多个接口,这多个接口有些处理时间长,有些慢,他们共用一系列资源,相互之间是有影响的,单独一个接口压到顶峰,可能其他接口直接就凉凉了,这个时候应该怎么来设置,怎么压测呢?另外写接口或者post接口也可以压测吗?

    作者回复: 这算是一个非常好的问题。如果你要综合考虑多个服务的话,你需要模拟线上流量的比例来进行压测。比如说 A 接口和 B 接口各自占据了 70% 和 30%,那么你在压测的时候,压测流量额的 70% 是给 A 的,30% 是给 B 的。

    2023-12-04归属地:北京
  • 3.0的A7
    关于限流有几个疑问: 1、目前一些方案都是基于接口粒度的,这样的话,是需要针对每一个接口都要进行限流的配置吗,这样的话,如果一个服务能承受的最大qps是3000,共有10个接口,假设每个接口的访问频率都差不多,是不是要针对每个接口设置最大300? 2、如果针对单机维度进行3000的限流,会不会出现一种情况,就是如果一个完整的业务需要n多个接口,前m个都通过了,结果后边突然被限制,这样前边m个接口的计算资源是不是也被浪费了? 3、目前sentinel、Hystrix 都是针对java的,如果公司内部技术栈比较多,有没有通用的限流方案呢?nginx可以限,但是可能解决不了上面的两个问题。

    作者回复: 1. 实际上,我就搞过全部接口有一个限流阈值,以及单一的核心接口又有一个阈值,双重限流。 2. 是的,但是没办法,因为你作为一个服务端你不知道他们是归属于同一个业务的请求。 3. 其实我也见过 Go 的客户端。如果你要跨语言的话,最好就是手写了。比如说用 Redis,那么写好一个 lua 脚本,各个语言都调用同一个脚本。又或者,自己照着抄一个别的语言的 sentinel, hystrix。

    2023-10-11归属地:北京
收起评论
显示
设置
留言
18
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部