最近整理到一道 eBay 面试真题，题目是比较经典的 Rate Limiter（限流器）设计。

题目本身不算长，但可以延伸出时间窗口、数据结构、并发和分布式等不少讨论点，这里把题目和一个比较直观的思路整理出来，给正在准备类似面试的同学参考。

Implement a rate limiter that allows at most N requests per user within a T-second window.

class RateLimiter {
    boolean allowRequest(String userId, long timestamp);
}

Example: N = 3, T = 10 seconds

Request(user1, t=0) → true
Request(user1, t=2) → true
Request(user1, t=5) → true
Request(user1, t=7) → false
Request(user1, t=11) → true

一个比较直接的思路

可以考虑使用：

HashMap + Queue / Deque

HashMap 根据 userId 保存每个用户自己的请求记录，Queue 中保存最近几次请求对应的时间。

每次新的请求到来时：

先移除已经不在当前时间窗口内的 timestamp，再判断剩余请求数量是否已经达到 N。

如果没有达到限制，就把当前 timestamp 加进去并返回 true；否则返回 false。

这个方案比较容易实现，也方便继续讨论时间和空间复杂度。

Follow-up

Rate Limiter 这类题通常还有比较大的延伸空间：

• 用户数量很多时，历史数据如何清理
• 多线程环境下如何处理并发
• 多台服务器之间如何共享限流状态
• Fixed Window 和 Sliding Window 的区别
• 是否可以使用 Token Bucket / Leaky Bucket
• timestamp 是否保证递增

具体会不会问到这些，要看当场面试官希望把题目展开到什么程度。

csoahelp 面试辅助

像 eBay 这种题，真正困难的往往不是“完全不会”，而是面试过程中突然出现 follow-up 后，需要在几十秒内重新调整思路。

csoahelp 提供实时文本面试辅助，可以根据面试官当前的问题快速给出：

题意拆解、数据结构选择、复杂度分析、边界情况以及 follow-up 应对思路。

如果距离正式面试还有时间，也可以通过 Mock Interview 提前模拟类似的 Coding + Follow-up 场景，把 Rate Limiter、Cache、Queue、Scheduler 这类高频设计题完整练一遍。

对于已经刷过不少 LeetCode，但容易在真实面试里因为沟通、追问或者设计题卡住的同学，这类针对真实面试节奏的训练会更加有效。

我们也有代面试，面试辅助，OA代写等服务助您早日上岸~