分布式限流算法

分布式限流算法：应对高并发的核心技术

2025年Java面试宝典抢先看： 点此获取 提取码: 9b3g （涵盖分布式限流等高频考点）

在高并发、微服务架构大行其道的今天，分布式限流算法是面试官必问的压轴题。当单机限流遇到集群环境，如何精准控制全局流量？今天咱们就深入聊聊常见的分布式限流解决方案。

为什么需要分布式限流？

想象一下：你的电商服务部署在10台机器上，单机限流1000QPS。若流量集中在某一台，其他机器空闲，总体QPS远低于10000。更糟的是，突发流量可能直接打垮某一节点！分布式限流的核心目标就是统一管控集群流量配额，防止雪崩效应。

---

主流分布式限流算法解析

1. 令牌桶算法 (Token Bucket)

令牌桶是最易理解的分布式限流思路：

1. 系统以固定速率（如10个/秒）向桶中添加"令牌"。
2. 请求到达时，必须拿到令牌才能执行，否则拒绝。

分布式实现难点：

• 桶状态同步： 所有节点需共享剩余令牌数。
• 方案： 通常依赖Redis的INCR或Lua脚本保证原子性，例如用redis.call('incr',KEYS[1])判断计数。

2. 漏桶算法 (Leaky Bucket)

漏桶算法像个固定出水速率的水桶：

1. 请求如水流进入桶中。
2. 桶底以恒定速率（如100个/秒）漏出请求处理。
3. 水满则溢出（拒绝请求）。

特点： 能强行平滑流量，但无法应对突发流量（请求需排队等待）。

3. 计数器算法 (固定窗口/滑动窗口)

• 固定窗口： 粗暴划分时间窗（如1分钟），窗口内计数超过则限流。缺点：窗口切换时可能双倍流量冲击！
• 滑动窗口： 精细化划分（如将1分钟拆成6个10秒子窗口）。当前时间点向前滚动统计，更精确但计算稍复杂。

分布式核心： 同样需用Redis等中心存储计数，并确保时间同步。

---

分布式限流落地关键点

1. 存储选型： Redis因高性能、原子操作成首选。INCR+EXPIRE实现简单计数，令牌桶常用Redis-Cell模块（封装了令牌桶算法）。
2. 一致性与性能： 强一致性影响吞吐量。多数场景采用最终一致性（如异步同步计数）。
3. 动态调整： 结合系统监控（CPU、线程池）动态调整限流阈值（如Sentinel热点规则）。
4. 容错与降级： 限流服务不可用时，如何降级（如本地fallback）？避免单点故障！
5. 热点处理： 对高频访问的限流Key（如用户ID）进行分片存储，减轻单点压力。

---

场景案例：抢购活动

某次秒杀，你们团队如何做分布式限流？

1. 网关层限流： Nginx/Lua或Spring Cloud Gateway做集群级QPS控制。
2. 服务层限流： 商品详情服务使用Redis滑动窗口限制用户级访问频次。
3. 热点商品隔离： 对爆款商品单独配置更低的分布式限流阈值。
4. 排队兜底： 超过阈值请求进入MQ队列异步处理并返回"排队中"。

---

面试避坑指南

被问"如何设计分布式限流"时，别只答算法名字！要体现工程思维：

1. 明确场景（防爬虫？保护DB？熔断降级？）。
2. 选择合适算法（突发流量用令牌桶，平滑流量用漏桶）。
3. 说明技术组件（Redis/ZooKeeper/Sentinel）。
4. 强调容错策略（本地缓存降级、超时处理）。
5. 提性能优化（Lua脚本减少网络交互、Key分片）。

💡 小福利： 如果大家需要购买「面试鸭」会员解锁海量真题详解，可以通过 面试鸭返利网 下单，立享25元返利！限流策略学得好，Offer拿到手软~

分布式限流是构建健壮高并发系统的基石。理解其原理并掌握工程实践，面试时你就能游刃有余。快去网盘领取宝典查漏补缺吧！