最有效务实的限流方式是在接口入口加“阀门”控制单位时间请求量；需按场景选维度（IP、路径、用户ID、业务类型），单机用Guava RateLimiter，分布式用Redis+Lua原子计数，并通过AOP注解无感接入。
直接在接口入口加一道“阀门”，控制单位时间内的请求量，是最有效也最务实的限流保护方式。关键不是选多复杂的算法，而是让规则能快速生效、不拖慢正常请求、还能应对分布式场景。
按场景选对限流维度
限流不是一刀切，得看你要防什么：
- 防爬虫或恶意调用 → 按 客户端 IP 限流，比如每分钟最多 30 次
- 防前端轮询失控 → 按 请求路径（如
/api/order/status）统一限流 - 保障 VIP 用户体验 → 按 用户 ID 独立计数，不同用户互不影响，配额还可分级（普通用户 10 次/分钟，VIP 100 次/分钟）
- 保护下游数据库 → 按 业务类型（如“查库存”“下订单”）做资源级隔离限流
单机够用就别急着上 Redis
如果你的服务是单实例、QPS 不高（比如日活几千的小系统），用 Guava 的 RateLimiter 最轻量：
- 基于令牌桶，平滑处理突发流量
- 无需外部依赖，代码几行就能跑起来
- 适合在 Service 层或 Controller 方法内嵌入，比如下单前先
rateLimiter.tryAcquire()
注意：它只在当前 JVM 生效，集群部署时会失效 —— 这时候就得升级方案。
生产环境推荐 Redis + Lua 原子计数
分布式系统必须保证限流状态全局一致，Redis 是事实标准。重点不是存数据，而是“原子性”和“自动过期”：
- 用
INCR+EXPIRE组合有竞态风险，推荐封装成 Lua 脚本一次执行 - Key 设计带上下文，例如：
rate:ip:192.168.1.100:60s或rate:uid:12345:1m - 窗口用滑动时间（如基于当前秒的时间戳哈希）比固定窗口更抗毛刺
用 AOP 或注解让限流“无感接入”
别把限流逻辑硬塞进业务代码。定义一个 @RateLimit 注解，配合切面统一拦截：
- 支持参数化：指定
count=5、time=60、type=IP - 拦截器里自动拼 Key、调用 Redis 计数、返回
429 Too Many Requests - 异常统一捕获，避免业务方法里到处写 if 判断
这样加限流就像打标签一样简单，上线、调整、下线都只改个注解。
