Redis用ZREVRANGE查TopN热销商品方法

Redis的ZREVRANGE命令是获取TopN热销商品的正确选择，但其默认仅返回商品ID（member），而非销量分数（score），必须显式添加WITHSCORES参数才能一并获取，且结果为交替排列的扁平列表；索引范围是闭区间，取前N名需用0到N-1，而非0到N；它按全局排名精准取数，优于按分数范围查询的ZREVRANGEBYSCORE，尤其在存在相同销量时更稳定；而客户端解析时务必使用官方推荐的withscores=True解包方式（如redis-py），避免手动切片导致商品与销量错配——这三处细节看似微小，却是线上报表对不上的高频根源。

用 ZREVRANGE 拿 TopN，但返回的是 score 还是 value？

直接说结论：ZREVRANGE 默认返回的是 member（也就是商品 ID 或名称），不是 score。很多人误以为它像 SQL 的 ORDER BY score DESC LIMIT N 那样“带分值一起出来”，其实不加参数只返 member。

常见错误现象：查出来一堆商品 ID，但不知道各自销量多少，还得额外 ZSCORE 一个个查 —— 性能掉得厉害。

• 要连 score 一起拿，必须显式加上 WITHSCORES 参数
• ZREVRANGE goods:hot 0 9 WITHSCORES 才是正确姿势
• 返回结果是交替的：["item_102", "248", "item_33", "211", ...]，注意解析时成对取值

ZREVRANGE 的索引是从 0 开始，但边界容易算错

Redis 的 range 索引是闭区间，ZREVRANGE key start stop 中的 start 和 stop 都包含在内。Top10 就是 0 9，不是 0 10 —— 后者会拿 11 个。

使用场景里最容易出问题的是动态分页或补位逻辑：比如想查“销量第 11 到 20 名”，写成 10 20 就多拿一个；想查“前 N 名”但 N 是变量，没做 N-1 转换也会越界。

• TopN 固定写法：ZREVRANGE key 0 [N-1]
• 如果 N 可能为 0，Redis 不报错但返回空数组，业务层得兜底判断
• 超范围（比如 stop 大于实际元素数）不会报错，自动截断 —— 这点比 SQL 安全，但也容易掩盖数据异常

为什么不用 ZREVRANGEBYSCORE？它和 ZREVRANGE 本质不同

ZREVRANGE 是按**排名位置**取，ZREVRANGEBYSCORE 是按**分数范围**取。热销榜是典型“我要前 N 名”，不是“我要销量在 200~500 之间的商品”。

混淆这两者会导致严重偏差：当多个商品 score 相同时，ZSet 内部排序不稳定（相同 score 的 member 按字典序排），ZREVRANGEBYSCORE 可能漏掉或重复某些名次；而 ZREVRANGE 基于全局排名，结果确定。

• 只要业务语义是“销量最高前 N”，就该无条件选 ZREVRANGE
• ZREVRANGEBYSCORE 更适合“查昨日销量 ≥ 100 的所有商品”这类场景
• score 设计建议：避免整数销量直接当 score，可乘以 1000 + 时间戳后缀防并列，但 TopN 查询本身不依赖这个优化

Python / Java 客户端拿到 WITHSCORES 结果后怎么安全解析？

Redis 协议返回的是扁平列表，客户端库（如 redis-py、Jedis）通常自动转成 list 或 tuple，但结构仍是 [member1, score1, member2, score2, ...]。直接遍历下标奇偶容易出错，尤其当 member 本身含数字或空格时。

性能影响不大，但解析逻辑写错会导致 score 错配到错误商品上，线上可能把销量最低的当成 Top1。

• redis-py 示例：res = r.zrevrange("goods:hot", 0, 9, withscores=True) → 返回 [("item_a", 120.0), ("item_b", 115.0)]，自带解包，推荐用这个
• Jedis 需手动配对：List