基于 Redis 的分布式限流怎么做？

简化版

Redis 分布式限流要把读取、判断和扣减放进同一个 Lua 脚本或原子命令，并明确 Redis 故障时按业务选择 fail-open 还是 fail-close；单纯 GET 后 INCR 存在竞态。

回答“基于 Redis 的分布式限流怎么做？”时要同时说明正常流程、故障边界和验证指标，不能只报出组件名或算法名。

详细版

令牌桶通常保存剩余令牌和上次补充时间，脚本基于 Redis 服务端时间补充并扣减。key 要带租户与接口维度、设置过期时间，同时控制热点与集群 slot。

落地时抓住四点：

请求带规范化限流 key 与成本权重进入脚本。
脚本读取服务端时间并计算可补充令牌。
令牌足够则原子扣减并返回剩余量，否则返回等待时间。
客户端仅把 Redis 结果作为服务端准入决定并记录降级路径。

一个可量化的例子是：速率 100/s、桶容量 200，空闲 2 秒可积满 200 个；瞬时 250 个请求最多放行 200 个，余下 50 个被拒绝或等待，之后按 100/s 恢复。

“基于 Redis 的分布式限流怎么做？”的判断标准：方案不仅在正常路径能工作，还要能解释重复、超时、宕机或配置变化时如何收敛。

完整版教学

一、先定义问题与边界

令牌桶通常保存剩余令牌和上次补充时间，脚本基于 Redis 服务端时间补充并扣减。key 要带租户与接口维度、设置过期时间，同时控制热点与集群 slot。

本题首先要区分“业务语义”和“系统实现”。前者决定什么算同一次动作、允许多晚、能否重复；后者才决定使用数据库、消息队列、Redis、租约或本地状态。对“基于 Redis 的分布式限流怎么做？”而言，不先明确业务语义，技术方案很容易在异常路径上答错。

易错点：回答“基于 Redis 的分布式限流怎么做？”时，不能把正常路径成立当成分布式语义已经成立；必须继续检查重复、超时、节点失联和配置切换。

二、核心数据与状态

设计“基于 Redis 的分布式限流怎么做？”时，需要把关键决策状态持久化或限制在可重建范围内。状态应有稳定身份、版本和明确生命周期；任何会被重试或接管的动作，都不能仅靠进程内布尔值判断是否完成。

核心设计如下：

请求带规范化限流 key 与成本权重进入脚本。
脚本读取服务端时间并计算可补充令牌。
令牌足够则原子扣减并返回剩余量，否则返回等待时间。
客户端仅把 Redis 结果作为服务端准入决定并记录降级路径。

三、主流程如何运转

基于 Redis 的分布式限流怎么做？
  -> 输入与身份校验
  -> 读取当前规则或状态
  -> 原子地作出准入 / 所有权 / 执行决策
  -> 执行业务动作并记录结果
  -> 指标、审计与异常恢复

这条流程中，最重要的是决策与状态更新之间不能留下无法解释的窗口。对于“基于 Redis 的分布式限流怎么做？”，实现必须让重复请求、迟到结果和节点切换都落到同一套身份与版本规则上。

四、用数字验证容量与语义

速率 100/s、桶容量 200，空闲 2 秒可积满 200 个；瞬时 250 个请求最多放行 200 个，余下 50 个被拒绝或等待，之后按 100/s 恢复。

数字不是固定配置，而是说明估算方法。生产值应来自压测、历史分位数和故障演练，并为长尾、扩缩容和依赖抖动预留余量。只给阈值却不说明依据，不能证明“基于 Redis 的分布式限流怎么做？”已经可落地。

五、方案对比与取舍

方案	优点	主要代价或边界
固定窗口 INCR	简单高效	窗口边界可形成双倍突发
Lua 令牌桶	支持突发与权重	热点脚本和时间计算更复杂
本地分桶加 Redis	降低中心压力	允许有界超发且公平性下降

“基于 Redis 的分布式限流怎么做？”的选型不能脱离正确性、延迟、吞吐和运维成本。通常先选择语义最清楚、故障可恢复的方案，再针对已证实的瓶颈优化，不能为了少一次存储访问而丢掉必要状态。

六、异常路径与恢复

“基于 Redis 的分布式限流怎么做？”需要主动演练以下异常：

Redis 超时导致入口线程堆积。
主从切换丢失最近计数。
使用客户端时间造成节点偏差。
高基数 key 占满内存。

处理“基于 Redis 的分布式限流怎么做？”的异常应有上限：重试有预算，排队有长度和最老年龄，租约有过期时间，人工操作有审批和审计。结果未知时先查询、对账或等待租约收敛，不能把“没收到成功响应”直接等价为“没有执行”。

七、观测、告警与上线

“基于 Redis 的分布式限流怎么做？”至少要监控：脚本延迟、Redis 错误率、允许/拒绝量、key 数与内存、降级次数。指标必须能按规则或任务版本关联发布，并避免把用户 ID、任务 ID 等无限基数直接作为时序标签。

“基于 Redis 的分布式限流怎么做？”的上线顺序应是先只观测，再小范围执行规则，然后逐步扩大。每一阶段同时看系统资源和业务结果；回滚不仅是恢复配置，还要处理已经创建的任务、已排队请求或已产生的副作用。

八、常见误区与追问

误区：INCR 和 EXPIRE 分开执行足够原子。 进程可能在两步间宕机留下永不过期 key，判断也可能竞态。
误区：Redis 限流天然 exactly accurate。 故障切换、网络与本地降级都会带来误差。
追问：Redis 挂了怎么办？ 核心写操作可 fail-close，浏览类流量可保守本地限流后 fail-open。
追问：为何用服务端时间？ 避免不同应用节点时钟偏差操纵补充量。
追问：热点 key 怎么办？ 分层本地配额、令牌预取或按租户拆分，但要评估超发。

九、加强记忆

回答“基于 Redis 的分布式限流怎么做？”时可以按“语义、身份、原子性、边界、观测”展开：先定义业务语义和稳定身份，再说明关键决策如何原子完成；随后覆盖超时、重复、宕机与配置变化，最后用容量数字和指标证明方案能够收敛。

简化版

详细版