zunionstore在大数据量下极易引发redis主线程卡顿甚至服务抖动，因其是同步内存聚合操作，无异步、超时和中断机制；需加载全部成员、哈希分组、加权聚合并写入目标key，千万级成员可阻塞数百毫秒至数秒。
ZUNIONSTORE 在大数据量下不是“能用”，而是“极易引发主线程卡顿甚至服务抖动”——它本质是同步内存聚合操作，没有异步、不支持超时、无法中断。
为什么 ZUNIONSTORE 会阻塞 Redis 主线程
Redis 所有命令都在单线程中顺序执行。ZUNIONSTORE 需要：把所有输入 ZSet 的全部 member-score 对加载进内存 → 按 member 做哈希分组 → 对每个 member 的 score 应用 WEIGHTS 和 AGGREGATE（默认 SUM）→ 写入目标 key。当任一输入 ZSet 成员数超千万，这个过程可能持续数百毫秒到数秒。
常见错误现象：ZUNIONSTORE 出现在 slowlog get 中；latency latest 显示 command 类型延迟突增；监控里 CPU 使用率尖峰与该命令调用时间强相关。
- 它不支持
TIMEOUT参数，加了也无效 - 即使目标 key 是空的，若配置了
zset-max-ziplist-entries > 0，合并中途可能触发编码升级（ziplist → skiplist），进一步延长阻塞时间 - 若目标 key 已存在且为 ziplist 编码，而结果远超阈值，Redis 可能因内存重分配失败直接报错
OOM command not allowed when used memory > 'maxmemory'
WEIGHTS 和 AGGREGATE 必须显式配对使用
很多人以为设了 WEIGHTS 就自动加权，其实不然：WEIGHTS 只是乘法前置步骤，最终怎么合并还得看 AGGREGATE。默认是 SUM，但如果你想要“取最高权重项的分数”，就得写 AGGREGATE MAX。
典型误用场景：用阅读数、点赞数、收藏数三个 ZSet 做推荐分，想让“点赞权重更高”。只加 WEIGHTS 1 3 2，却没写 AGGREGATE SUM（虽默认，但建议显式写上），结果上线后发现分数异常小——其实是某 ZSet 里部分 member 缺失，SUM 后变成 0 + 其他值，而非预期的“有就参与、无就忽略”。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
ZUNIONSTORE rec_rank 3 read_zset like_zset fav_zset WEIGHTS 1 3 2 AGGREGATE SUM：正确，显式声明语义 - 不写
AGGREGATE也能跑，但可读性差，协作时易被覆盖或误解 - 若业务逻辑是“任一维度达标即入围”，应改用
AGGREGATE MAX，而非依赖默认 SUM
生产环境必须做分批 + 预清理
直接对几十个 ZSet 执行 ZUNIONSTORE global_rank 24 zset_jan zset_feb ... zset_dec 是高危操作。真实可行的做法是两层拆分：
- 先按用户 ID 分片（如
user:{uid}%16）构建中间层 ZSet，每片只 union 2–4 个源 ZSet，控制单次计算量在 10 万 member 内 - 再用一次顶层
ZUNIONSTORE合并这 16 个中间 ZSet，此时输入 key 数少、成员总量可控 - 每次执行前，用
DEL target_key清空目标 key，避免残留 ziplist 编码干扰 - 确认线上
zset-max-ziplist-entries设为0，强制跳表编码，消除升级风险
检查是否生效：OBJECT ENCODING target_key 返回 skiplist 才算落地成功。
替代方案比硬扛更值得考虑
当 ZUNIONSTORE 单次耗时稳定超过 50ms，或日均调用量超百次，就该评估替代路径。ZUNIONSTORE 的优势是原子、单命令、结果直接可查；劣势是不可控、不可退、难观测。
更稳的思路是：用 ZRANGEBYSCORE 分页拉取各源 ZSet 数据，在应用层归并排序（比如 Go 的 heap 包或 Python 的 merge）。虽然多了网络和计算开销，但可限流、可降级、可打点、可熔断。
真正容易被忽略的一点：ZUNIONSTORE 的“结果确定性”是假象——它不保证跨命令的事务一致性。比如你在 union 过程中，某个源 ZSet 被并发 ZINCRBY 更新了，那这次 union 看到的就是一个中间态快照。这点在排行榜实时性要求极高时，比性能问题更致命。
