阿里三面：说一说你在上家公司都用过哪些限流方案？，java服务器面试题

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

1、熔断

====

将熔断措施嵌入到系统设计中，当系统出现问题时，若短时间内无法修复，系统会自动开启熔断开关，拒绝流量访问，避免大流量对后端的过载请求。

除此之外，系统还能够动态监测后端程序的修复情况，当程序已恢复稳定时，就关闭熔断开关，恢复正常服务。

常见的熔断组件有 Hystrix 以及阿里的 Sentinel。

在 Spring Cloud 框架里，熔断机制通过 Hystrix 实现。Hystrix 会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是 5 秒内 20 次调用失败，就会启动熔断机制。

熔断机制的注解是 @HystrixCommand，Hystrix 会找有这个注解的方法，并将这类方法关联到和熔断器连在一起的代理上。

2、服务降级

======

将系统的所有功能服务进行一个分级，当系统出现问题需要紧急限流时，可将不是那么重要的功能进行降级处理，停止服务，保障核心功能正常运作。

例如在电商平台中，如果突发流量激增，可临时将商品评论、积分等非核心功能进行降级，停止这些服务，释放出机器和 CPU 等资源来保障用户正常下单。

这些降级的功能服务可以等整个系统恢复正常后，再来启动，进行补单/补偿处理。

除了功能降级以外，还可以采用不直接操作数据库，而全部读缓存、写缓存的方式作为临时降级方案。

熔断 &降级

• 相同点：目标一致 都是从可用性和可靠性出发，为了防止系统崩溃；用户体验类似，最终都让用户体验到的是某些功能暂时不可用。

• 不同点：触发原因不同，服务熔断一般是某个服务（下游服务,即被调用的服务）故障引起；

• 而服务降级一般是从整体负荷考虑。

3、延迟处理

延迟处理需要在系统的前端设置一个流量缓冲池，将所有的请求全部缓冲进这个池子，不立即处理。后端真正的业务处理程序从这个池子中取出请求依次处理，常见的可以用队列模式来实现。

这就相当于用异步的方式去减少了后端的处理压力，但是当流量较大时，后端的处理能力有限，缓冲池里的请求可能处理不及时，会有一定程度延迟。

4、特权处理

这个模式需要将用户进行分类，通过预设的分类，让系统优先处理需要高保障的用户群体，其它用户群的请求就会延迟处理或者直接不处理。

二、限流算法

======

常见的限流算法有三类：计数器算法、漏桶算法和令牌桶算法。

1、计数器算法

=======

计数器算法是限流算法中最简单最容易的一种，如上图每分钟只允许 100 个请求，第一个请求进去的时间为 startTime，在 startTime + 60s 内只允许 100 个请求 。

当 60s 内超过十个请求后，则拒绝请求；不超过的允许请求，到第 60s 重新设置时间。

View Code

利用计数器算法比如要求某一个接口，1 分钟内的请求不能超过 100 次。

可以在开始时设置一个计数器，每次请求，该计数器+1；如果该计数器的值大于 10 并且与第一次请求的时间间隔在 1 分钟内，那么说明请求过多则限制请求直接返回或不处理，反之。

如果该请求与第一次请求的时间间隔大于 1 分钟，并且该计数器的值还在限流范围内，那么重置该计数器。

计算器算法虽然简单，但它有一个很致命的临界问题。

上图可以看出假若有一个恶意用户，他在 0:59 时，瞬间发送了 100 个请求，并且在 1:00 时，又瞬间发送了 100 个请求，那么其实这个用户在 1 秒后，瞬间发送了 200 个请求。

而上述计数器算法规定的是 1 分钟最多 100 个请求，也就是每秒钟最多 1.7 个请求，而用户通过在时间窗口的重置节点处突发请求，可以瞬间超过限流的速率限制，这个漏洞可能会瞬间压垮服务应用。

上述漏洞问题其实是因为计数器限流算法统计的精度太低，可以借助滑动窗口算法将临界问题的影响降低。

2、滑动窗口

======

上图中，整个红色的矩形框表示一个时间窗口。在计数器算法限流的例子中，一个时间窗口就是一分钟。在这里将时间窗口进行划分，比如图中，将滑动窗口划成了 6 格，每格代表的是 10 秒钟。每过 10 秒钟，时间窗口就会往右滑动一格。每一个格子都有自己独立的计数器 counter，比如当一个请求在 0:35 秒的时候到达，那么 0:30~0:39 对应的 counter 就会加 1。

那么滑动窗口是怎么解决刚才的临界问题的呢？

上图，0:59 到达的 100 个请求会落在灰色的格子中，而 1:00 到达的请求会落在橘黄色的格子中。当时间到达 1:00 时，窗口会往右移动一格，那么此时时间窗口内的总请求数量一共是 200 个，超过了限定的 100 个，所以此时能够检测出来触发了限流。

经过比较发现发现，计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分，所以只有 1 格。所以，当滑动窗口的格子划分得越多，则滑动窗口的滚动就越平滑，限流的统计就会越精确。

3、漏桶算法

======

漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会超过桶可接纳的容量时直接溢出，可以看出漏桶算法能强行限制数据的传输速率。

使用漏桶算法，可以保证接口会以一个常速速率来处理请求，所以漏桶算法必定不会出现临界问题。

面试准备+复习分享：

为了应付面试也刷了很多的面试题与资料，现在就分享给有需要的读者朋友，资料我只截取出来一部分哦

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-RDWw5XiO-1713553548260)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！