发布者限流应采用incr+expire固定窗口计数，因其简单可靠、无竞态、rt稳定；须用pipeline执行避免超限，键名需含业务上下文隔离维度，并配置client-output-buffer-limit pubsub防止缓冲区溢出。
发布者限流不是为了“匀速发消息”，而是防止突发流量把下游消费者（比如慢 SQL、HTTP 调用）或 Redis 自身（如连接池、输出缓冲区）打崩——直接用 INCR + EXPIRE 做固定窗口计数，最简单也最可靠。
为什么不能用令牌桶或滑动窗口做发布者限流
令牌桶（如 Guava 的 RateLimiter）默认允许预支，空闲 1 秒就能攒满全部配额，瞬间打出 100 条，下游 Redis 连接池可能直接被撑爆；滑动窗口（ZSET + 时间戳）在高并发发布时，ZREMRANGEBYSCORE 和 ZCARD 组合延迟波动大，还容易因系统时钟漂移导致统计错乱。发布者限频的本质是“每分钟最多 X 条”，不是“必须平滑”，固定窗口已足够表达硬约束，且命令少、RT 稳定、无状态依赖。
必须用 pipeline 执行 INCR + EXPIRE
拆成两个独立命令会引发竞态：两个发布请求同时 GET 到当前值为 9，都判断“还能发”，再各自 INCR 到 10 和 11，结果超限却没拦住。正确做法是用 pipeline 把 INCR 和 EXPIRE 打包发送，让 Redis 单线程串行执行：
pipe = r.pipeline()
pipe.incr(key)
pipe.expire(key, window_sec)
result = pipe.execute() # result[0] 是本次 incr 后的值
if result[0] > limit:
raise Exception("rate limit exceeded")
注意：result[0] 就是新计数值，别再额外 GET 一次；如果 INCR 返回 1，说明是窗口内首条，此时补一次 EXPIRE 更安全（避免首次漏设过期）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
键名设计要带上下文，避免全局冲突
键名不能只用 pub:order 这种泛化名，否则不同服务、不同 IP、不同时间窗口全挤在一个计数器里，要么误限要么漏限。推荐格式：pub:topic:order_created:20260905:10.0.1.23（含日期和客户端 IP），或按业务维度切分，比如 pub:merchant:abc123:minute。这样既能隔离干扰，又方便后续按维度查监控、调参。
别忘了 client-output-buffer-limit pubsub 配置
即使发布端做了限流，如果某个订阅者卡住不消费，消息还在往它的输出缓冲区里塞，内存照样涨。这个参数必须显式写进 redis.conf，CONFIG SET 不支持动态修改。例如单条消息平均 80KB、最多 5 个订阅者、容忍积压 3 秒，则理论积压 ≈ 80KB × 5 × 3 = 1.2MB，client-output-buffer-limit pubsub 至少设为 4mb 2mb 60（hard/soft/seconds），禁用（0 0 0）等于放弃保护。
真正容易被忽略的是：限流逻辑生效的前提，是所有发布路径都走同一套键生成规则和 pipeline 调用；只要漏掉一个分支（比如某处直连 Redis 发布、绕过限流中间件），整个防护就形同虚设。
