Redis 有序集合（Sorted Set，简称 ZSet）通过 score 字段对成员进行排序，score 是一个 64 位双精度浮点数。动态权重更新的本质就是在业务运行中持续修改这个 score，从而让成员在排行榜或优先级队列中的位置实时变化。Redis 本身没有提供复杂的权重计算能力，但通过 ZADD、ZINCRBY 以及 Lua 脚本的组合，可以构建出满足不同场景的动态权重方案。
一、从 ZINCRBY 看原子增量更新
最直接的动态权重更新指令是 ZINCRBY。它可以在原有 score 的基础上增加一个增量，而不需要客户端先读取旧值再写入。这个操作在 Redis 服务端原子完成，避免了并发读取和写入之间的竞态。例如一个用户完成一次下单，给他在排行榜中的活跃分增加 5 分：
ZINCRBY user_rank 5 user:10001
执行后，Redis 返回更新后的 score。如果成员不存在，ZINCRBY 会先创建成员并将增量作为初始 score。如果想确保只在成员已存在时更新，可以配合 ZSCORE 判断，但更推荐使用 Lua 脚本把判断和更新合并为一个原子操作。
除了增量更新，ZADD 也支持直接覆盖 score。Redis 3.0.2 之后 ZADD 增加了 XX 选项，表示只更新已存在成员，不会因为拼写错误或过期成员而意外创建新数据。例如只更新不新建：
ZADD user_rank XX 88 user:10001
这种覆盖式更新适合权重来自外部计算结果的场景，比如管理员手动调整、离线算法重新打分。增量更新和覆盖更新可以组合使用，核心原则是：如果权重变化由事件驱动，优先使用 ZINCRBY；如果权重由完整计算结果决定，则使用 ZADD XX。
二、时间衰减权重：让热度随时间平滑下降
很多排行榜不能只关注累计行为，例如新闻热榜、商品推荐榜需要让最近的行为权重更高，旧数据逐渐失效。常见做法是给 score 引入时间衰减因子，公式可以写成 score = base_score + interaction_count / (now - publish_time) 或者指数衰减 score = score * exp(-lambda * delta_t)。
如果每次查询都全量重算所有成员的时间衰减，成本会非常高。更实用的方案是使用定时任务周期性地对 ZSet 做批量衰减。比如每 10 分钟执行一次 Lua 脚本，遍历分数超过阈值的成员进行衰减；或者采用对数时间衰减，将原始事件计数间隔性地通过 ZREMRANGEBYSCORE 清理低分成员。下面是一个使用 Redis 内置命令模拟周期衰减的思路：
# 每 10 分钟对活跃分整体乘以 0.95，实现平滑降权 # 需要配合 Lua 保证原子性，以下为简化的逻辑示例 ZREVRANGE user_rank 0 999 WITHSCORES # 将读取到的每个成员 score 乘以 0.95 后 ZADD 回写
上面的方式虽然直观，但存在读取和回写之间的并发问题。建议把衰减逻辑放进 Lua 脚本中，在服务端一次性完成。Redis 的 Lua 脚本执行期间会阻塞其他命令，所以脚本处理的数据量要控制，例如每次只处理分数前 1000 名或使用 ZSCAN 分批执行。
另一个工程思路是事件驱动衰减，不在固定时间衰减，而是在每次读取或更新时按时间差计算补偿。但对于 ZSet 来说，每个成员的时间戳通常存储在 Hash 中，更新 score 时需要读取时间戳、计算差值、写回 score，这正适合用 Lua 原子化处理。
三、多维度权重融合：用 ZUNIONSTORE 合成新榜
动态权重往往来自多个维度，例如用户排行榜可能同时考虑消费金额、活跃天数、好评数。Redis 的 ZUNIONSTORE 可以将多个有序集合按照给定权重合并，生成一个新的 ZSet。命令格式如下：
ZUNIONSTORE dest_zset 3 src_zset_1 src_zset_2 src_zset_3 WEIGHTS 0.6 0.3 0.1
这样 dest_zset 中每个成员的 score 等于三个源集合中对应 score 分别乘以 0.6、0.3、0.1 后求和。合并过程在服务端完成，适合定期重建总榜。例如每隔 5 分钟将消费榜、活跃榜、好评榜融合成综合榜，然后直接读取 dest_zset。
需要注意 ZUNIONSTORE 是 O(N*K) 复杂度，N 为成员总数，K 为集合数量。如果源集合很大，合并会造成短暂的 CPU 抖动。可以通过将结果写入临时 key，再用 RENAME 原子替换，避免查询读到不完整数据。
当多个维度的更新非常频繁时，不建议每次都重建总榜。可以在每个维度更新时增量修改总榜，但这要求业务层维护权重比例，且一个维度变化会同步影响总分的多个部分。更灵活的方式是将总榜本身也作为一个 ZSet，由事件驱动增量更新，而 ZUNIONSTORE 只作为周期性校正或冷启动初始化工具。
四、Lua 脚本保证读改写原子性
动态权重最常见的错误是客户端先 ZSCORE 获取旧值，计算新值后再 ZADD 写回。在并发场景下，两个请求可能读到同一个旧值，其中一个更新会被覆盖丢失。例如两个点赞请求同时读取 score=10，各自加 1 后都写回 11，实际应该变成 12。
解决方法是把读改写逻辑放入 Lua 脚本。Redis 从 2.6 开始支持 Lua 脚本，脚本在服务端单线程执行，天然具备原子性。下面是一个安全的更新脚本，功能是给指定成员增加动态权重，其中权重值可以直接传入：
-- KEYS[1] 为 ZSet key
-- ARGV[1] 为 member
-- ARGV[2] 为增量
local cur = redis.call('ZSCORE', KEYS[1], ARGV[1])
if cur then
local next = tonumber(cur) + tonumber(ARGV[2])
redis.call('ZADD', KEYS[1], next, ARGV[1])
return next
else
redis.call('ZADD', KEYS[1], ARGV[2], ARGV[1])
return tonumber(ARGV[2])
end
这个脚本其实可以简化为直接调用 ZINCRBY，但示例展示的是更复杂的读改写模式。真实场景中，权重计算可能依赖外部时间、用户等级或 Hash 中的元数据，此时就能体现出 Lua 的价值。例如需要在增加权重前读取用户等级，不同等级乘以不同系数：
-- KEYS[1] 为 ZSet key
-- KEYS[2] 为存储用户等级的 Hash key
-- ARGV[1] 为 member
-- ARGV[2] 为基础增量
local level = redis.call('HGET', KEYS[2], ARGV[1]) or '1'
local factor = 1
if level == 'vip' then
factor = 2
elseif level == 'svip' then
factor = 5
end
local delta = tonumber(ARGV[2]) * factor
return redis.call('ZINCRBY', KEYS[1], delta, ARGV[1])
脚本通过 KEYS 传入相关键，避免硬编码。执行时可以用 EVAL 或 EVALSHA 缓存脚本 SHA 降低网络开销。
五、高并发下的性能优化与精度控制
动态权重更新频繁时，单个 ZSet 热 key 会成为瓶颈。Redis 单线程模型下，如果所有请求都操作同一个 ZSet，QPS 上限受单核处理能力限制。常见的优化是分片，例如排行榜按时间段或用户 ID 取模拆分，先更新分片集合，再定期合并。比如 rank:202501:hour:14 这样的 key 可以分散写入压力。
批量更新可以使用 Pipeline，但 ZSet 没有批量 ZADD 命令，需要通过 Pipeline 将多个 ZINCRBY 一次性发送。Pipeline 不保证原子性，但能显著降低 RTT。Go、Java 客户端通常封装了 Pipeline API。下面是 Python redis-py 的批量示例：
import redis
r = redis.Redis(host='127.0.0.1', port=6379, db=0)
pipe = r.pipeline(transaction=False)
for uid, delta in [('user:1', 3), ('user:2', 7), ('user:3', 2)]:
pipe.zincrby('user_rank', delta, uid)
result = pipe.execute()
print(result)
需要特别留意 score 的浮点精度。Redis 内部使用 IEEE 754 双精度浮点数，整数部分在正负 2 的 53 次方范围内可以精确表示。当 score 达到万亿级别时，小于 1 的增量可能会丢失。如果业务需要极高精度，可以把权重乘以一个系数后取整存储。例如货币金额以分为单位，不要直接存储 0.01 这样的浮点累加值。开发中应避免将小数、整数混合在超大 score 上，也不要频繁对 score 做除法或开方，防止精度逐渐漂移。
另一个容易忽视的点是 ZINCRBY 处理负增量后，如果 score 低于某个阈值，不会自动删除成员。需要业务定期执行 ZREMRANGEBYSCORE key -inf 0 清理无效成员，否则 ZSet 会无限膨胀，影响内存和查询性能。
六、完整示例：实时用户活跃排行榜
结合以上技术，可以构建一个实时用户活跃排行榜。假设系统需要根据用户行为（浏览、点赞、评论）动态增加活跃分，同时希望旧活跃分随时间衰减，并且要给 VIP 用户额外加权。可以设计三个 ZSet 分别存储原始活跃分、时间衰减后分数和综合展示分数；或者采用简化方案，所有逻辑通过 Lua 原子更新一个 ZSet。
简化事件处理流程如下：当用户产生行为时，先查询用户等级，再根据行为类型确定基础分，然后调用 Lua 脚本更新 score。下面是完整的 Lua 脚本，包含行为系数和等级系数：
-- KEYS[1]: 排行榜 ZSet key
-- KEYS[2]: 用户等级 Hash key
-- ARGV[1]: member
-- ARGV[2]: 行为类型，例如 view/like/comment
-- ARGV[3]: 基础增量
local action_factor_map = { view = 1, like = 2, comment = 3 }
local level_factor_map = { normal = 1, vip = 2, svip = 5 }
local action = ARGV[2]
local action_factor = action_factor_map[action] or 1
local level = redis.call('HGET', KEYS[2], ARGV[1]) or 'normal'
local level_factor = level_factor_map[level] or 1
local delta = tonumber(ARGV[3]) * action_factor * level_factor
return redis.call('ZINCRBY', KEYS[1], delta, ARGV[1])
客户端执行 EVAL 时传入 rank、user_level 两个 key 和成员、行为类型、基础分。查询排行榜使用 ZREVRANGE rank 0 99 WITHSCORES，获取分数最高的前 100 名。如果需要控制每周榜单，可以在 key 中加入周标识，例如 rank:week:20250113，到期后使用 EXPIRE 自动清理。
对于时间衰减，可以每天凌晨执行一次临时 job，使用 ZSCAN 分批读取成员和 score，将 score 乘以 0.8 后回写。也可以用更精细的 Lua 脚本结合时间戳，每次只衰减最近活跃的一批成员。无论哪种方式，都要注意避免阻塞主线程，建议离线任务使用空闲时间或从节点完成。
Redis ZSet 的动态权重更新并没有黑魔法，核心是理解 score 的原子操作模型，结合 ZINCRBY、ZADD XX、ZUNIONSTORE 和 Lua 脚本。根据业务场景选择事件驱动增量、定时衰减或多维融合，才能在保证实时性的同时控制性能与精度风险。
Redis ZSet动态权重排行榜修改时间：2026-08-26 11:43:53