直接用incr+expire做漏桶会出错，因无法原子执行“检查水位→放行判断→更新水位→续期时间”整套逻辑，并发时多个请求可能同时读到低水位而超限放行；必须用lua脚本封装惰性漏水计算并由客户端传入高精度时间戳。
为什么直接用 INCR + EXPIRE 做漏桶会出错
漏桶的核心是“匀速漏水”+“突发流量缓冲”，但 Redis 单命令无法原子性地完成“检查当前水位→决定是否放行→更新水位→设置/续期过期时间”这一整套逻辑。如果拆成多个命令（比如先 GET 再 INCR 再 EXPIRE），并发时会出现竞态：两个请求同时读到水位为 0，都允许通过，实际就超限了。
必须用 Lua 脚本把整个判断和更新逻辑包在一个原子操作里，且脚本内不能依赖客户端时间（比如 redis.call('TIME') 返回的是服务器时间，但漏桶需要按固定速率“漏水”，得靠时间戳差值算漏了多少）。
EVAL 脚本里怎么模拟“漏水”过程
关键不是真等时间过去，而是每次请求来时，用当前时间减去上一次记录的时间，算出该漏掉多少单位（向下取整），再从当前水位里减掉——这叫“惰性漏水”。水位不能低于 0，也不能超过桶容量。
- 脚本接收 5 个参数：
KEYS[1]（桶的 key）、ARGV[1]（桶容量）、ARGV[2]（漏水速率，单位：次/秒）、ARGV[3]（当前请求时间戳，毫秒）、ARGV[4]（本次请求尝试消耗的令牌数，通常为 1） - 用
redis.call('HMGET', KEYS[1], 'water', 'last_time')一次性读出当前水位和上次更新时间 - 若
last_time为空，说明桶是新的，直接设水位为math.min(ARGV[4], ARGV[1])，并存入当前时间 - 否则计算已过去秒数：
(tonumber(ARGV[3]) - tonumber(last_time)) / 1000，再算应漏水量：math.floor(elapsed * tonumber(ARGV[2])) - 新水位 =
math.max(0, math.min(tonumber(water) - leak, ARGV[1]))，然后判断new_water >= ARGV[4]决定是否放行
示例调用：
redis-cli --eval ./leaky_bucket.lua my:bucket , 10 0.5 1717023456789 1
为什么 ARGV[3] 必须由客户端传入时间戳
不能在 Lua 里调用 redis.call('TIME')，因为它的返回是秒级精度且不包含毫秒，误差太大；更不能用 os.time()（Redis 的 Lua 环境禁用该函数）。客户端必须用高精度时间（如 Date.now() 或 System.currentTimeMillis()）生成毫秒时间戳，并传进来——这是保证漏水计算准确的唯一方式。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
另一个陷阱：如果客户端时间偏差大（比如快了 10 秒），会导致算出的 leak 过大，水位被清空，误拒合法请求。生产环境务必校准客户端与 Redis 服务器时间（NTP 同步）。
桶的存储结构选 HSET 还是 SET + EXPIRE
用 HSET 存 {water: "5", last_time: "1717023456789"} 更合理。虽然单个 SET + 过期也能存水位，但无法原子读写两个字段——你没法只更新 last_time 而不重置 water，也没法在判断时同时拿到两者。
注意点：
- 不要给桶 key 设置固定过期时间（比如
EXPIRE my:bucket 3600），因为漏桶要长期存在，只是内部状态随时间变化 - 如果长时间没请求，水位自然漏完变成 0，但 key 本身保留，下次来请求时继续基于
last_time计算即可 - 避免用
DEL清桶——这会丢失last_time，导致下一次请求误判为“新桶”，瞬间放行满容量
真正难处理的是“突发后持续低频”的场景：比如桶容量 10、速率 1/s，突然来 10 个请求打满，之后每秒只来 1 个。这时水位会在第 10 秒才开始缓慢恢复——这个行为是否符合业务预期，得看你的服务容忍度，而不是脚本能改出来的。
