ZADD不加CH参数默认不更新已存在member的分数，仅插入新member；同分时member按字典序排序导致分页错位；score必须为double类型，否则ZREVRANGE返回空。
ZADD 不加 CH 参数会导致分数不更新
很多人在高并发写入时发现排行榜分数“卡住不动”，根本原因不是并发冲突，而是 ZADD 默认行为：仅当 member 不存在时才插入，已存在就静默忽略。这在多线程/多进程反复调用时，等效于“只认第一次写入”。
正确做法是显式带上 CH 参数：
-
ZADD leaderboard CH 1520 "player_42"—— 强制更新，返回值为 1 表示真发生了变更 - 避免误用
NX（仅插入）或XX（仅更新），它们是互斥条件，不能组合使用，也不解决“覆盖旧分”需求 - 如果业务逻辑要求“分数只能升不能降”，需在应用层判断，
ZADD ... CH本身不提供条件更新能力
同分 member 排序不稳定引发分页错位
当多个玩家分数相同（比如都为 1000），ZREVRANGE 返回顺序不保证 FIFO，前端分页可能漏掉或重复显示同一人——这不是线程安全问题，而是 ZSet 底层排序规则限制：同分时按 member 字典序排，而字典序和入队时间无关。
解决方案是让 score 具备唯一性：
- 拼接时间戳反向值：
score = priority * 10000000000 + (10000000000 - time_s)，确保同优先级下更早入队 → 更大 score → 更先被ZPOPMAX或ZREVRANGE拿到 - 若需毫秒精度，改用
redis.call("time")的微秒部分t[2]，系数调整为1000000 - 不要用原始时间戳正向拼接，否则
ZPOPMAX会优先弹出最新任务，违背 FIFO
Pipeline 中混用 ZADD 和 ZREVRANGE 易读不到新数据
看似原子的 pipeline 实际执行是“批量发、批量收”，但 Redis 服务端仍按命令顺序逐条执行。若在同一个 pipeline 里先 ZADD 再 ZREVRANGE，理论上能读到；但若 pipeline 被拆包、重试或客户端连接复用混乱，就可能因网络延迟或中间件缓存导致读取视图滞后。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
更稳妥的做法：
- 写后立即读的场景，拆成两个独立请求，或用 Lua 脚本封装原子读写（如
EVAL "...zadd...zrevrange..." 1 leaderboard） - 上线前务必用
ZCARD校验：写入总数是否等于ZREVRANGE返回数量，若前者明显更大，说明有写入丢失或 key 名写错（如误写为leaderboard:2024） - 对强实时场景（如决赛倒计时排名），可加
WAIT 1 1000，但会引入毫秒级延迟，且只在开启复制的集群中生效
Score 类型错误导致 ZREVRANGE 返回空
调用 ZREVRANGE leaderboard 0 9 却拿不到数据，90% 情况不是命令错，而是 score 被传成了字符串或非法浮点数。Redis 强制要求 score 是 double 类型，但很多 SDK（如旧版 redis-py）对 "1520" 或 Decimal('1520.0') 会静默转成 0 或丢弃。
排查步骤：
- 用
ZSCORE leaderboard "player_42"手动查单个值，确认返回的是数字而非(nil)或字符串 - 写入前强制转原生类型：Python 中用
float(1520)，Go 中用float64(1520)，严禁传字符串 - 避免 JS 浮点计算结果直传，如
0.1 + 0.2 = 0.30000000000000004，应四舍五入或转整数存储（如乘以 100 存分为单位）
真正需要警惕的不是“多个线程同时操作 Redis”，而是“多个线程共用一个未同步的连接对象”或“误以为 pipeline 能跨请求保证一致性”。Redis 单线程模型本身不暴露竞态，但应用层的连接管理、参数校验、score 编码方式，才是高并发下 ZSet 行为失控的主因。
