大家好，我是Tony Bai。
欢迎来到我们的专栏 《API 设计之道：从设计模式到 Gin 工程化实现》的第八讲。
在上一讲中，我们给 API 穿上了"防弹衣"，通过幂等性设计防止了重复请求的数据污染。今天，我们要给 API 装上"红绿灯"和"安检门"。
在云原生架构中，**"吵闹的邻居（Noisy Neighbor）"**是一个经典难题。
想象一下，你的 SaaS 系统服务着 100 个租户。突然有一天，租户 A 写了一个 Bug 脚本，死循环调用你的 GetOrder 接口，QPS 瞬间飙升 100 倍。
-
如果没有限流：数据库 CPU 飙升至 100%，租户 B、C、D 的请求全部超时，整个系统雪崩。
-
如果有限流：租户 A 的超额请求被快速拒绝（HTTP 429），而租户 B、C、D 的服务丝毫不受影响。
限流（Rate Limiting）不仅仅是为了防攻击，更是为了保障系统的可用性（Availability）和公平性（Fairness）。
很多同学在写限流时，喜欢在内存里放个 map 计数，或者用 Go 官方的 rate.Limiter。这在单机单实例下没问题，但在 Kubernetes 多副本部署的环境下，单机限流不仅由于负载均衡不均而不准确，更无法控制全局的总并发量。
今天这一讲，我们将基于 Redis 和 GCRA（Generic Cell Rate Algorithm） 算法，在 Gin 中实现一个实用的分布式限流器。
限流的架构哲学
在开始写代码前，我们需要厘清两个容易混淆的概念：速率限制（Rate Limiting） 与 配额管理（Quota Management）。
速率限制 (Rate Limiting)
-
目的：保护基础设施（CPU、内存、DB 连接数）不被冲垮。
-
粒度 ：通常是秒级或分钟级。例如：
100 req/s。 -
行为：通过"削峰填谷"，拒绝突发流量。
配额管理 (Quota / Pricing Plan)
-
目的：商业化计费或防止资源滥用。
-
粒度 ：通常是天级或月级。例如：
免费版 1000次/天，专业版 无限制。 -
行为：耗尽即停。
本讲主要聚焦于速率限制，但也兼容配额管理的实现思路。