redis cluster限流不能直接用单key，因为所有同名key会被哈希到同一slot和主节点，导致热点瓶颈、cpu飙升及moved错误；必须用{}哈希标签将不同实例的key分散至多节点，同时lua多key操作需保证同slot以避免crossslot错误。
Redis Cluster 限流为什么不能直接用单 key？
因为 Redis Cluster 会按 key 做哈希分片，所有对同一个 rate:order:create 的请求都会落到同一个主节点上——它就成了热点 key 和单点瓶颈。哪怕集群有 6 个主节点，这个限流逻辑实际只压在 1 个节点上，QPS 上万时容易打满连接、触发慢日志甚至节点抖动。
常见错误现象：(error) MOVED 12345 10.0.1.5:6379 频繁出现、redis-cli -c 测试时响应延迟突增、监控看到某节点 CPU 持续 >90%。
- 根本原因不是 Redis 性能差，而是限流 key 没做散列，违背了 Cluster “均匀分片”的设计初衷
- 不能靠加从节点解决——读请求可分担，但
INCR、HINCRBY等写命令必须路由到主节点 - 即使用了
RRateLimiter（Redisson），如果 key 不带哈希标签{}，一样会集中打到单节点
用 {} 哈希标签把限流压力打散到多个节点
Redis Cluster 对 key 计算 slot 时，只取 {} 中的内容做 CRC16。只要把业务标识（如用户 ID、订单号前缀）放进大括号，就能让同类型但不同实例的限流 key 落在不同 slot 上。
比如原始 key 是 rate:api:login，改成：rate:api:login{uid1001}、rate:api:login{uid1002}…… 这样每个用户独立限流，且 key 分散到不同节点。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 不要用
rate:api:login{user_id}这种模板——user_id是字符串字面量，所有请求都哈希到同一 slot - 必须是运行时真实值，例如 Spring Boot 中：
"rate:api:login{" + userId + "}" - 如果要做全局限流（非 per-user），可用随机后缀：
"rate:api:global{" + (userId % 8) + "}"，把总量均分到 8 个 slot - 注意：Lua 脚本里操作多个 key 时，所有 key 必须落在同一 slot，否则报
CROSSSLOT错误
Redisson RRateLimiter 在 Cluster 下要配 RateType.OVERALL 还是 PER_CLIENT？
选错会导致限流失效或过严。关键看你要控“总流量”还是“单客户端流量”：
-
RateType.OVERALL：整个集群共用一个桶，适合接口级总 QPS 控制（如 /order/create 全局每秒最多 100 次）。但必须确保 key 带{}散列，否则还是单点 -
RateType.PER_CLIENT：每个客户端（由 client ID 区分）独立桶，适合防刷场景（如每个 IP 每分钟最多 5 次）。此时 key 可直接用"rate:ip:" + ip，无需额外散列 - Redisson 默认 client ID 是 UUID，如果你用的是 WebFlux 或 Netty 客户端，需显式设置
setAddressResolver才能稳定识别客户端 - 调用
trySetRate()时，第二个参数是总令牌数，第三个参数是“刷新周期单位数”，不是秒数——trySetRate(OVERALL, 100, 1, SECONDS)表示每 1 秒生成 100 个令牌
为什么推荐用 redis-cell 模块而不是纯 Lua 脚本？
因为 GCRA（通用单元格速率算法）比固定窗口/令牌桶更抗突发，且模块化实现避免了 Lua 脚本跨版本兼容问题和运维负担。
典型错误：自己写的 Lua 令牌桶脚本在 Redis 7.2 上因 redis.call('time') 返回格式变化而计算偏移出错；或者没处理 nil 返回导致限流开关失灵。
-
redis-cell的CL.THROTTLE命令原子返回 5 个值：[allowed, remaining, reset_in, total_consumed, retry_in]，业务层只需判断第一个值 - 部署时必须在每个 Cluster 主节点的
redis.conf里加loadmodule /path/to/libredis_cell.so，漏掉任一节点，该节点负责的 slot 就会报(error) ERR Unknown command - Cluster 下调用
CL.THROTTLE时，key 同样要带{}，例如：CL.THROTTLE rate:search{uid123} 5 1 1（每秒 5 次，桶容量 1） - 模块不支持事务 pipeline，所以高并发下别把
CL.THROTTLE和其他命令塞进同一个 pipeline
真正容易被忽略的点是：限流 key 的生命周期管理。无论用哪种方案，如果业务 key 长期不用却一直存在（比如用户 ID 作为 key 但用户注销了），Redis 内存会缓慢上涨。得配合 TTL 或定期清理 job，不能只依赖限流逻辑本身。
