API 网关限流规则从单机限流升级为集群限流后，Redis 成为热点瓶颈，如何在不显著增加成本的前提下优化集群限流方案？

如果 API 网关的限流从单机升级到集群后，所有请求都去 Redis 做计数或取令牌，Redis 很容易变成热点，尤其是某些大客户、热门接口或者全局限流 key，QPS 会集中打到少数几个 Redis key 上。

我一般不会直接继续堆 Redis 资源，而是把集群限流改成“本地限流 + Redis 全局协调”的两级方案。

核心思路是： 大部分请求在网关本地完成限流判断，Redis 只负责全局额度的分配和校准 。

比较常见的做法是令牌预分配，也可以理解成 token lease：

Redis 里维护某个限流规则的全局令牌桶，比如某个 API 每秒最多 10 万次。 每个网关节点不是每个请求都访问 Redis，而是定期从 Redis 批量申请一小段令牌额度，比如一次申请 500 或 1000 个。 节点拿到额度后，在本地内存里用令牌桶或滑动窗口做快速判断。 本地额度用完了，再去 Redis 申请下一批。 如果 Redis 判断全局额度不足，就不给这个节点分配，节点本地开始限流。

这样 Redis 的访问次数就从“每个请求一次”变成“每批令牌一次”，压力会