12. Rate Limiter 限流器

V1 — 1个用户：浏览器端防抖节流

场景

你做了一个表单页面，用户疯狂点击”提交”按钮，导致重复请求。你需要在前端限制点击频率。

你要解决什么

用纯JavaScript实现按钮防抖和API调用节流，防止重复操作。

给AI的Prompt

帮我用纯HTML+JavaScript实现一个前端限流器：

1. 一个表单页面，包含输入框和提交按钮
2. 实现两种限流：
   - debounce：输入框停止输入300ms后才触发搜索
   - throttle：提交按钮每2秒最多点击1次
3. 限流状态可视化：
   - 按钮在冷却期间变灰，显示倒计时
   - 显示"请求被拦截"或"请求已发送"的日志列表
4. 用一个简单的计数器对象记录：总点击数、实际发送数、拦截数
5. 所有状态存localStorage，刷新页面保留统计

不要用任何框架，纯原生JS实现debounce和throttle函数。

验证清单

• 快速连点10次按钮，只发出1次请求
• 输入框快速输入，停止后才触发搜索
• 冷却期间按钮显示倒计时
• 统计数据刷新后保留

你学到了什么

• debounce vs throttle 的区别和适用场景 → Module: 前端性能优化
• 为什么限流要在多层实施（前端只是第一层） → Module: 防御性编程

---

V2 — 10个用户：Go中间件 IP限流

场景

你的API上线了，有10个用户在用。你发现有人写脚本刷接口，需要在后端按IP限制请求频率。

你要解决什么

用Go中间件实现基于内存map的IP限流，滑动窗口算法。

给AI的Prompt

帮我用Go+Gin实现一个IP限流中间件：

1. 滑动窗口算法实现：
   - 用map[string][]time.Time存储每个IP的请求时间戳
   - 窗口大小：1分钟
   - 限制：每个IP每分钟最多60次请求
2. 中间件逻辑：
   - 获取客户端真实IP（支持X-Forwarded-For）
   - 超限返回429 Too Many Requests + Retry-After头
   - 响应头包含：X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset
3. 过期清理：
   - 每5分钟启动goroutine清理过期记录
   - 用sync.RWMutex保证并发安全
4. 白名单：配置文件指定不限流的IP列表
5. 写一个测试：模拟同一IP快速发送100个请求，验证第61个被拦截

注意：这是单机方案，不需要Redis。用sync.Map或带锁的map即可。

验证清单

• 同一IP超过60次/分钟返回429
• 响应头正确显示限流信息
• 过期记录被自动清理
• 白名单IP不被限流
• 并发请求不会panic

你学到了什么

• 滑动窗口 vs 固定窗口的区别 → Module: 限流算法
• HTTP 429和限流响应头规范 → Module: HTTP协议
• Go并发安全（sync.Mutex） → Module: Go并发

---

V3 — 100个用户：Redis令牌桶

场景

你的服务部署了多个实例，内存限流器只能限制单机。用户切换到不同实例就绕过了限制，需要分布式限流。

你要解决什么

用Redis实现令牌桶算法，多个服务实例共享限流状态。

给AI的Prompt

帮我用Go+Redis实现分布式令牌桶限流：

1. Redis令牌桶实现（Lua脚本保证原子性）：
   - Key: rate_limit:{identifier}
   - 字段：tokens(当前令牌数), last_refill(上次填充时间)
   - 参数：capacity(桶容量), refill_rate(每秒填充数)
   - Lua脚本逻辑：计算应填充令牌 → 扣减 → 返回结果
2. Go中间件集成：
   - 从Redis执行Lua脚本判断是否放行
   - Redis不可用时降级到本地限流（内存map兜底）
3. 不同API不同限制：
   - GET请求：100次/分钟
   - POST请求：20次/分钟
   - 登录接口：5次/分钟
4. 限流信息API：GET /api/rate-limit/status 查看当前用户限流状态
5. 提供docker-compose.yml包含Redis

请给出完整的Lua脚本和Go调用代码。

验证清单

• 两个服务实例共享限流计数
• 令牌按配置速率恢复
• Redis宕机时降级到本地限流
• 不同API路径限流策略不同

你学到了什么

• 令牌桶 vs 漏桶 vs 滑动窗口 → Module: 限流算法对比
• Redis Lua脚本保证原子性 → Module: Redis进阶
• 降级策略：外部依赖不可用时的兜底方案 → Module: 容错设计

---

V4 — 1000个用户：多维度限流

场景

业务增长，简单的IP限流不够了。VIP用户要更高额度，某些API需要更严格的限制，运营想动态调整限流规则。

你要解决什么

实现多维度（用户/IP/API路径）配置化限流，支持运营后台动态修改规则。

给AI的Prompt

在V3基础上扩展多维度限流系统：

1. 限流维度（可组合）：
   - IP维度：按IP限流
   - 用户维度：按user_id限流，不同等级不同额度
   - API维度：按路径+方法限流
   - 组合维度：如"同一用户对同一API"的限流
2. 规则配置（存PostgreSQL）：
   - 规则表：dimension, pattern, algorithm, capacity, rate, enabled
   - 用户等级映射：free=100/min, pro=1000/min, enterprise=10000/min
   - 规则优先级：精确匹配 > 通配符匹配
3. 配置热更新：
   - 规则缓存在本地内存，TTL 30秒
   - 管理API修改规则后立即生效（通过Redis Pub/Sub通知所有实例）
4. 限流日志：
   - 被限流的请求记录到日志表（异步写入）
   - 管理后台看到：哪些用户/IP被限流最多
5. 管理API：
   - CRUD限流规则
   - 查看限流统计（Top 10被限流的IP/用户）

要求规则可以在不重启服务的情况下生效。

验证清单

• 不同等级用户限流额度不同
• 修改规则后30秒内生效
• 组合维度限流正确工作
• 管理后台能看到限流统计

你学到了什么

• 配置化思维：把策略从代码抽到配置 → Module: 可配置系统设计
• Redis Pub/Sub实现配置热更新 → Module: 事件驱动
• 多维度规则匹配和优先级 → Module: 策略模式

---

V5 — 1万用户：限流集群

场景

服务扩展到多个区域，单个Redis扛不住限流请求。需要Redis集群化，同时支持灰度放量。

你要解决什么

Redis Cluster分片限流，灰度放量机制，限流规则版本管理。

给AI的Prompt

在V4基础上实现限流集群方案：

1. Redis Cluster部署：
   - 3主3从Redis Cluster
   - 限流Key按用户ID哈希分片
   - 连接池管理和故障转移
2. 灰度放量：
   - 新API上线时从10%流量开始
   - 按用户ID尾号分桶，逐步放量：10% → 30% → 50% → 100%
   - 放量规则存配置中心，支持秒级回滚
3. 限流规则版本管理：
   - 规则变更记录历史版本
   - 支持一键回滚到任意历史版本
   - 变更审批流程（可选）
4. 监控告警：
   - Prometheus metrics：限流触发次数、令牌消耗速率
   - 当限流触发率超过阈值时告警
   - Grafana dashboard配置
5. 压测方案：
   - 用Go编写压测工具，模拟不同IP和用户
   - 验证集群模式下限流精度

提供docker-compose.yml包含Redis Cluster(6节点)配置。

验证清单

• Redis Cluster 6节点正常工作
• 限流Key均匀分布在不同分片
• 灰度放量按预期比例控制流量
• 规则回滚在5秒内生效
• Prometheus能采集到限流指标

你学到了什么

• Redis Cluster分片原理 → Module: 分布式缓存
• 灰度发布和流量控制 → Module: 发布策略
• 可观测性：Metrics/Alerting → Module: 监控体系

---

V6 — 10万+用户：全局限流网关

场景

公司有几十个微服务，每个都自己实现限流，逻辑不统一。需要在API Gateway层统一限流，同时支持多机房和自适应限流。

你要解决什么

API Gateway集成统一限流，多机房限流状态同步，基于系统负载的自适应限流。

给AI的Prompt

设计并实现全局限流网关方案：

1. API Gateway限流层：
   - 基于Kong/APISIX网关插件或自研Go网关
   - 所有微服务的限流在网关层统一配置
   - 支持按租户(tenant)、服务、API三级限流
2. 多机房同步：
   - 每个机房有本地Redis Cluster
   - 跨机房限流状态通过异步同步（最终一致）
   - 本地优先：优先查本地Redis，异步同步全局计数
   - 容忍短暂超限（比如全局限制1000，实际可能短暂到1050）
3. 自适应限流：
   - 采集后端服务指标：CPU、内存、响应时间、错误率
   - 当后端负载高时自动收紧限流
   - 当后端恢复时自动放松限流
   - 算法：基于AIMD(加性增，乘性减)或TCP拥塞控制思想
4. 限流降级策略：
   - L1: 正常放行
   - L2: 限制非核心API
   - L3: 只允许核心API（登录、支付）
   - L4: 全站只读模式
5. 控制面板：
   - Web UI管理所有限流规则
   - 实时流量大盘（每秒请求数、限流比例）
   - 一键切换降级等级

这是架构设计+核心代码实现，不需要实现完整网关。
重点实现自适应限流的AIMD算法和多机房同步逻辑。

验证清单

• 网关层统一拦截超限请求
• 多机房限流计数最终一致
• 后端CPU升高时自动收紧限流
• 降级等级切换在10秒内生效
• 控制面板实时显示流量数据

你学到了什么

• API Gateway的角色和限流职责 → Module: 网关设计
• 多机房数据同步的CAP权衡 → Module: 分布式系统
• 自适应限流和AIMD算法 → Module: 自适应系统
• 降级策略分级 → Module: 高可用设计