zunionstore 合并多个 zset 时相同 member 的 score 默认相加；海量数据下会严重阻塞 redis 主线程；需注意目标 key 编码、member id 统一及分批合并等实践要点。
ZUNIONSTORE 合并多个 ZSet 时，相同 member 的 score 怎么算？
默认是相加，不是覆盖或取最大。这是最容易误解的一点——很多同学以为 ZUNIONSTORE 像 SQL UNION 那样去重合并，其实它本质是「按 member 聚合 score」的操作。
比如：ZADD scores_a 100 user:1 200 user:2 和 ZADD scores_b 50 user:1 80 user:3，执行 ZUNIONSTORE scores_all 2 scores_a scores_b 后：
-
user:1→100 + 50 = 150 -
user:2→200（只在 scores_a 中存在） -
user:3→80（只在 scores_b 中存在）
如果想改成取最大值，得显式指定 AGGREGATE MAX；取最小值用 MIN。不写就默认 SUM。
海量用户下，ZUNIONSTORE 会阻塞 Redis 吗？
会，而且很严重。它是个同步、全量、内存计算操作：Redis 会把所有输入 ZSet 的所有 member-score 对加载进内存，逐个聚合，再写入目标 key。当单个 ZSet 有千万级成员时，一次 ZUNIONSTORE 可能卡住主线程几百毫秒甚至秒级。
实际使用中要注意：
- 避免在高峰期直接跑跨天/跨月的全量积分合并，比如
ZUNIONSTORE rank_202406 12 rank_jan ... rank_may - 用
TIMEOUT参数没用——ZUNIONSTORE不支持超时中断 - 监控
latency latest和slowlog get，这类命令极易出现在慢日志里 - 生产环境建议拆成小批量合并，例如先按用户分片（如 hash tag
user:{uid}%100），再分别 union，最后做一次顶层 union
合并后排名不准？检查 member 的数据类型和编码
Redis ZSet 内部用两种结构存储：ziplist（小集合，紧凑）和 skiplist + dict（大集合，快查）。当 ZUNIONSTORE 输出目标 key 原本是空的，它会按默认策略选编码；但如果目标 key 已存在且是 ziplist 编码，而合并结果远超阈值（如 zset-max-ziplist-entries > 128），Redis 会在写入中途升级编码——这个过程不可中断，且可能触发内存重分配，导致结果错乱或命令失败。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
稳妥做法：
- 提前用
DEL target_key清空目标 key，避免编码残留干扰 - 确认配置项
zset-max-ziplist-entries和zset-max-ziplist-value是否合理（线上建议设为0关闭 ziplist，强制用 skiplist） - 用
OBJECT ENCODING target_key检查结果编码是否为skiplist
替代方案：为什么不用 ZRANGEBYSCORE + 应用层归并？
对实时性要求不高、且需要精确控制内存/耗时的场景，应用层流式归并更可控。比如用 ZRANGEBYSCORE src_key -inf +inf WITHSCORES LIMIT 0 1000 分批拉取，边拉边 merge 到本地有序结构（如 Go 的 heap 或 Python 的 sortedcontainers），再写回新 ZSet。
优势明显：
- 不阻塞 Redis 主线程
- 可随时中断、断点续传
- 能跳过无效 member（如已注销用户）
- 便于加入业务逻辑（如权重系数、时效衰减）
代价是多一次网络往返和应用层 CPU 开销。但比起一次卡住 Redis 导致整个服务抖动，这笔账通常划得来。
真正棘手的是 member ID 的一致性——比如不同来源的 ZSet 用的是 uid、openid、device_id 三种格式，合并前必须统一映射，否则 ZUNIONSTORE 会当成不同用户处理。这个映射逻辑没法交给 Redis 做，只能前置清洗。
