必须在Nginx层用漏桶（burst=32、nodelay、429状态码）兜住突发流量，再在Laravel层用Redis+Lua实现令牌桶（非滑动窗口）精细限流，两级联动才能扛住秒杀冲击。
当秒杀活动开启瞬间，Laravel应用在Nginx层被击穿、数据库连接池打满、队列堆积如山——这不是故障复盘，是你还没把漏桶和令牌桶真正配进生产链路。必须让Nginx在请求入口处用漏桶兜住毛刺流量，再让Laravel应用层用令牌桶做精细化放行，两级防线缺一不可。
Nginx层漏桶：用burst缓冲突发，用nodelay控制响应节奏
第一步：在nginx.conf的http块中定义共享内存区，按客户端IP限流，速率设为每秒8个请求：
limit_req_zone $binary_remote_addr zone=nginx_leaky:10m rate=8r/s;
第二步：在server块内对应API location中启用漏桶，并配置burst=32——这个值不是拍脑袋定的，它必须大于单次前端批量请求的最大并发数（比如Vue组件一次性发5个接口，你至少得预留5×3=15），否则burst过小会导致合理请求也被拦截。
第三步：加上nodelay参数，让超出rate的请求立刻消耗burst额度，而不是排队等待；【不加nodelay时，用户点击后要等几百毫秒才收到响应，体验直接变卡顿】配置写成：limit_req zone=nginx_leaky burst=32 nodelay;
第四步：强制返回429状态码，避免前端误判为503或超时：
limit_req_status 429;
Laravel应用层令牌桶：用Redis+Lua原子扣减，防超卖也防穿透
方法一：基于Redis原生命令手写Lua脚本
在app/Http/Controllers/BookingController.php里，预约逻辑开头插入令牌校验：
```php
$key = 'token_bucket:' . auth()->id();
$lua = "local tokens = tonumber(redis.call('get', KEYS[1]) or ARGV[1])\nlocal rate = tonumber(ARGV[2])\nlocal now = tonumber(ARGV[3])\nlocal last = tonumber(redis.call('get', KEYS[2]) or '0')\nlocal delta = now - last\nlocal new_tokens = math.min(tonumber(ARGV[1]), tokens + delta * rate)\nif new_tokens >= 1 then\n redis.call('set', KEYS[1], new_tokens - 1)\n redis.call('set', KEYS[2], now)\n return 1\nelse\n return 0\nend";
$result = Redis::eval($lua, 2, $key . ':tokens', $key . ':last', 20, 2, now());
if (!$result) {
abort(429, '请求太频繁，请稍后再试');
}
```
方法二：用laravel-rate-limiter包快速集成
执行composer require spatie/laravel-rate-limiting，发布配置后，在Kernel.php的$middlewareGroups里插入：
```php
\Spatie\RateLimiting\Middleware\EnsureRateLimitNotExceeded::class . ':api,10,60'
```
其中10是每分钟最大请求数，60是窗口秒数——但注意，这本质是滑动窗口，不是令牌桶，无法应对瞬时毛刺。
【必须选方法一】因为秒杀场景下，滑动窗口在窗口切换临界点会允许双倍流量突刺，而Lua脚本实现的令牌桶能持续平滑放行。
两级联动验证：用ab压测确认漏桶未被绕过
第一步：启动ab工具，模拟100并发请求，持续30秒：
ab -n 3000 -c 100 'https://api.example.com/booking'
第二步：观察Nginx access.log，确认429响应数占比稳定在（100−8×30）÷3000≈73%左右——说明漏桶生效，且burst缓冲区被充分使用。
第三步：登录Redis，执行redis-cli --scan --pattern "token_bucket:*" | wc -l，确认令牌桶Key数量与真实活跃用户数基本一致，排除Key爆炸风险。
第四步：在Laravel日志中grep "429"，确保应用层令牌桶拦截发生在Nginx之后——如果应用层429占比过高，说明Nginx漏桶配置过松，需调低rate或burst。
