高并发下的限流守卫-动态令牌桶
plus 版本专属
此章节是黑马点评 Plus 版本中专有的内容，而在整套文档中将普通版本和 Plus 版本都融合在了一起，让大家更方便的学习。
如果没有限流会存在哪些问题？
- 秒杀流量瞬时暴涨： 入口在毫秒级出现尖峰并发，直接把请求压到库存扣减脚本与数据库会导致系统过载，响应抖动、超时飙升乃至雪崩
- 不公平竞争与刷子横行： 同一 IP 或用户的高频刷新会挤占配额，导致普通用户难以下单
- 下层链路被动背锅： 即使在 Redis 执行 Lua 的扣减是原子性，但是过高 QPS 仍会让 Redis CPU 层面、网络 I/O、日志写入成为瓶颈
- 双重拦截与重复计数风险： 如果把限流放在更深一层（如 Service），可能与其他入口叠加，造成一次操作被多次计数，出现“误伤”
- 可观测与处置能力缺失： 没有统一入口的限流事件与处罚策略，无法基于阻断原因做黑名单封禁或运营分析
引入限流功能后，有什么优势？
在秒杀优惠券的入口处加入限流，能在业务逻辑之前进行“早拒绝、轻负载”的流量治理：
- 单次判定即止损： 在令牌校验/下单前统一裁决，避免把大量无效请求推入扣减脚本与数据库
- 双维度公平： 同时按 IP 与用户维度控制速率，限制恶意刷新与重复点击
- 场景化阈值： 通过使用“下单场景”的窗口与阈值，和“发令牌场景”解耦
- 统一事件与处罚闭环： 允许/阻断都能触发事件与处罚策略，形成观测与黑名单反哺
- 避免重复计数： 统一在控制器层执行，防止深层服务再次计数造成双重拦截
能够解决的问题
- 抗峰值与稳响应： 在入口把突发流量削峰，保护后端资源与用户体验
- 公平性保障： 避免少数高频用户/脚本占用大部分配额
- 安全与合规： 快速发现恶意行为并临时封禁（黑名单），减小二次冲击
- 可观测与调优： 限流事件可被采集与分析，支持动态调参与运营策略
限流功能的实现
为了让大家能更好的理解，采取线性执行的讲解方式，这样可以和程序执行的流程一致，等涉及到配置参数的读取，bean 的加载时，再分析是如何生成的。
一、代码实现
为了让大家能更好的理解，采取线性执行的讲解方式，这样可以和程序执行的流程一致，等涉及到配置参数的读取，bean 的加载时，再分析是如何生成的。