Redis集群不支持全局限流和背压，因去中心化架构无全局状态，限流需客户端绑定Hash Tag（如rl:{1001}）并用Lua原子执行，配合滑动窗口与多层协同保护。
Redis 集群本身不内置限流（Rate Limiting）和背压（Backpressure）能力，必须由客户端或中间层实现。直接依赖集群节点做流量控制，会绕过分片逻辑、破坏哈希槽路由，甚至触发 MOVED 或 ASK 重定向风暴。
为什么不能在 Redis Cluster 节点上做全局限流
Redis Cluster 是去中心化架构，各节点只知道自己负责的 16384 个槽中的一部分，没有全局请求计数器。你在 Node A 上用 INCR 统计请求量，对 Node B 的同业务 Key 完全无效；而用 Lua 脚本强行跨槽聚合，会违反 CROSSSLOT 约束，直接报错。
- 集群不共享状态：每个节点的内存、连接、命令队列都是隔离的
-
ACL或client-output-buffer-limit只能控单连接/单客户端，无法识别“同一业务用户”的请求洪峰 - 代理层（如 Twemproxy、Codis）若未开启一致性哈希或 slot-aware 路由，反而会把热点 Key 请求打散到多个节点，放大问题
客户端侧 Rate Limiting 必须绑定 Hash Tag
瞬时洪峰往往集中在某类业务实体（如商品 ID、用户 ID），限流单位必须是「语义一致的业务维度」，而不是随机 Key。这就要求限流 Key 和缓存 Key 共享同一哈希标签（Hash Tag），确保落在同一个槽、同一个节点上。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 错误写法：
SET user:1001:profile ...与INCR rl:user:1001—— 两个 Key 哈希值不同，可能跨节点 - 正确写法：
SET user:{1001}:profile ...与INCR rl:{1001}—— {} 内内容相同，CRC16 后取模结果一致，必然路由到同一节点 - 限流脚本建议用原子 Lua：
EVAL "local c = redis.call('incr', KEYS[1]); if c == 1 then redis.call('expire', KEYS[1], ARGV[1]) end; return c" 1 rl:{1001} 60 - 注意：
rl:{1001}这类限流 Key 本身也要参与内存淘汰，避免长期堆积；建议显式设EX或用PEXPIREAT
客户端背压需配合连接池与 request 控制
当上游服务（如 Spring WebFlux、Netty 客户端）向 Redis 发起异步批量请求时，若不控制并发深度，容易在本地积压大量未响应的 Future 或 Mono，最终 OOM。这不是 Redis 的问题，而是客户端没做反压传导。
- Java Lettuce：启用
EventLoopGroup线程数限制 + 设置timeout+ 在publishOn()前用onBackpressureBuffer(1024, ...)显式限缓冲区大小 - Go redigo / go-redis：用带缓冲的 channel 控制 pending command 数量，避免
client.Do()无节制提交 - Node.js ioredis：监听
drain事件，在writeQueueSize > 100时暂停新请求，比单纯await更可靠 - 关键点：背压信号必须从 Redis 响应延迟 → 客户端连接池耗尽 → 上游 HTTP worker 阻塞，形成闭环，否则只是把压力转移到别处
真正有效的协同保护长什么样
一个电商秒杀场景下，真实可行的组合是：前端埋点限流（Nginx limit_req）→ 网关层令牌桶（Dify-style TokenBucket）→ 客户端 Hash Tag 限流（Lua + {sku_id}）→ 连接池背压（Lettuce max-in-flight=64）→ Redis 节点级 client-output-buffer-limit slave 128mb。每一层都只解决自己能控的维度，没有哪一层试图「替别人扛压」。
最容易被忽略的是：Hash Tag 限流 Key 的生命周期管理。如果用户 1001 一整天都在刷接口，rl:{1001} 会一直存在且不断递增，导致后续所有限流判断失效——必须搭配滑动窗口或时间分片（如 rl:{1001}:2026052718）才能真正反映「瞬时」洪峰。
