某接口部署在 20 个实例上,业务上要求整个集群对外总限流 1000 QPS。如果直接给每个实例配 50 QPS 的单机令牌桶,会有什么问题?如果要做到真正的集群级限流,你会怎么实现,以及你的方案会付出什么代价?
面试官在考什么
判断候选人是否理解单机限流在实例不均衡和流量倾斜下的失效,以及集中式限流的性能代价与近似方案之间的取舍。
回答框架 · 前两步
- 单机 50 QPS 的致命问题是假设流量在 20 个实例上均匀分布:实际会因负载均衡策略、连接复用、实例冷热、慢节点导致倾斜,总量要么超过 1000 要么远低于 1000,同时实例扩缩容时阈值还得人工改
- 集群限流的实现路径有代价梯度:Redis + Lua 精确但每请求一次 RTT、有单点和性能上限;令牌预取(实例按批租借令牌,本地消耗)能大幅降低 Redis 压力,代价是精度下降(最坏会瞬时超发一批令牌的量);也可以用一致性哈希把某个 key 的配额固定到某台机器,本质是精度和可用性的权衡
还有 3 条答案要点、 3 层追问、 5 个常见坑, 以及针对你简历的追问路径,在定制报告里。
同一能力域的其他题
- 一个下单接口要扛峰值 2 万 QPS,库存只有 1000 件且不能超卖,MySQL 单实例写入大约只能承受 3000 TPS,Redis 可用。你会按什么顺序做改造?每一步解决的是哪一段瓶颈,做完之后怎么验证它确实有效?
- 一个限时抢购活动:商品库存 500 件,预计开抢后 1 秒内涌入 10 万个下单请求。硬性要求是绝对不能超卖,成功下单的响应时间要在 200ms 内,没抢到的用户也要在 1 秒内收到明确的失败提示(不能一直转圈)。请给出你的整体链路设计,并说明每一层分别在挡什么、为什么放在那一层。
- 假设你负责一个核心交易 API,日常峰值 1 万 QPS,大促峰值是日常的 20 倍(约 20 万 QPS),P99 要求 <200ms,可用性 99.95%。现有架构是单体应用 + MySQL 主从 + Redis 缓存,团队 8 人,大促预算只能覆盖当前机器成本的 1.5 倍。请你给出从大促前 3 个月到当天的完整方案:容量怎么估算、瓶颈怎么定位、哪些环节做异步/削峰、降级预案怎么定、成本怎么控制。
- 某活动接口预估峰值 3 万 QPS。压测结果:单台 4C8G 服务处理该接口的极限约 2000 QPS(平均响应 200ms,接口无状态,每次请求查一次数据库)。现在有 20 台同规格机器。问:(1) 这 20 台能不能扛住?(2) 如果只能做一件事来提升承载能力,你先做什么?
- 商品详情用 Redis 缓存,key 是商品 ID,TTL 统一 10 分钟。运营改了价格后最坏要 10 分钟才生效,同时线上偶发用户看到旧价格(已排除浏览器缓存)。现在 Redis 内存使用率 90%,缓存命中率 92%。你打算怎么调整?更新策略、TTL、淘汰策略分别怎么定,依据是什么?
- 商品详情页读多写少,峰值 5 万 QPS,缓存命中率 99%,底层是 MySQL。现在运营做一次批量调价,一次要改 2000 个商品的价格。请说明你的缓存更新方案:删缓存还是更新缓存、先动 DB 还是先动缓存、批量改价时怎么避免缓存集中失效把 DB 打穿。