【面试真题拆解】5秒内限10次HTTP接口访问，结合数据结构和算法说说你的思路

Fri, 20 Mar 2026 15:00:00 +0000

面试官问：

做Web项目的时候，会暴露出一些HTTP接口，我现在想对它进行限流，限制5秒内只能访问10次，结合数据结构和算法，看如何实现，说说你的思路

当时只说了个滑动窗口就没说其他的，然后就没有然后了。。。

首先，为什么要限流？

主要有以下三个原因：

技术选型

方案	数据结构+算法	核心思想	优缺点	适用场景
固定窗口计数器	数组/Map + 时间戳	把时间分成固定的窗口，每个窗口内计数	简单易实现；有临界问题（比如4.9秒刷10次，5.1秒又刷10次，实际0.2秒内刷了20次）	对精度要求不高的场景
滑动窗口计数器	本地：LinkedList（双向链表）分布式：Redis ZSet（有序集合） + 时间戳	窗口是“滑动”的，只保留当前窗口内的请求	解决了固定窗口的临界问题；本地版 LinkedList 删头加尾 O (1)，分布式版 ZSet 按时间范围操作高效；本地版不适合分布式集群	固定时间窗口内精确计数的场景
漏桶算法	队列 + 定时器	像漏桶一样，请求先存到队列里，然后匀速处理	可以削峰填谷；突发流量处理不了（秒杀时很多请求直接被拒）	对流量稳定性要求高的场景（比如消息队列）
令牌桶算法	队列 + 定时器	像令牌桶一样，匀速生成令牌，请求拿到令牌才能通过	可以削峰填谷，也可以处理突发流量	对流量稳定性和突发流量都有要求的场景（比如API网关）

滑动窗口的核心，是窗口不再是静止分段的，而是随当前时间连续移动、互相重叠的：

比如固定窗口，窗口是死的，0-5秒、5-10秒，边界固定不变。

而滑动窗口，窗口的右边界永远是当前请求的时间，左边界永远是当前时间 - 窗口大小，窗口会跟着每一次请求一直往前滑。

选择双向链表是因为我们需要频繁删除链表头部的过期时间戳，并且还需要频繁在链表尾部新增新的请求时间戳，而双向链表的删头、加尾操作时间复杂度都是O(1)，效率极高。

Web项目基本都是集群部署，本地计数器无法多实例同步，考虑用Redis实现。

选择Redis中的ZSet数据结构，ZSet的score字段可以存请求的时间戳，天然支持按时间范围排序。

每次请求进来，执行 3 步：

不能太快（等于没限流），也不能太慢（很多请求被拒），要根据业务场景调整。

要设置成窗口大小+一点缓冲（比如1秒），防止数据提前过期，导致计数不准确。