刚把项目里那个“每日热销榜”重新用 ZSet 做了一遍吞吐量直接翻了几倍代码还比之前用数据库算“干净”了不知多少。这玩意儿在 Redis 里叫“有序集合”英文名是 ZSet英文全称是 Sorted Set。做后端这几年我越来越觉得只要牵扯到“排名”“排序”“按权重取数据”ZSet 基本上是绕不开的最优选型。这篇就把我实际用 ZSet 攒下的经验、踩过的坑一次性梳理出来当作这个“Redis 命令及数据类型”系列的第十篇。1. ZSet 的核心思路与选型分析为什么偏偏是它我先说结论ZSet 最打动我的地方是它把“集合去重”和“可排序”这两个能力焊死在一个数据结构里。普通的 Set 只能告诉你“这个元素存在”List 能保证顺序但元素会重复Hash 能存一堆 field-value 但没法直接按某个字段排序——只有 ZSet 天然把“唯一的 member”和“可比较的 score”绑定在一起。1.1 从需求本质看 ZSet 的立足点抛开官方文档那些术语ZSet 实际上解决的是这类问题你有一堆对象它们各自带一个数值你要按这个数值随时拿到“最大的几个”“最小的几个”或者“分数在某区间的全部对象”。典型场景就是排行榜比如游戏服里的战力排名、电商里的销量榜、资讯App里的热点排序。我早期做过一个积分商城用户有积分、积分会变动运营要看到“总积分前 100 名用户”。一开始我用 MySQL每次刷榜单直接ORDER BY score DESC LIMIT 100用户量小的时候没事等用户破百万这个查询动不动就把一个从库拖垮而且索引维护成本也高。后来换成 ZSet同样的需求变成ZREVRANGE key 0 99 WITHSCORES毫秒级返回代码量还少了。1.2 与 List、Set、Hash 的对比选型的时候我在想什么很多人一上来就问“ZSet 和 List 有什么区别”其实它们的关系更像是“用途不同不是替代关系”。List 适合做消息队列、时间线这类按插入顺序读取的数据但它不适合“按成员去重”和“按某个指标动态排序”。Set 能去重但去重之后你想按热度再排行就等于自己再做一层排序逻辑费时费力。Hash 适合“一条记录对应多个字段”但你想比较不同记录的某个字段值还得单独维护一份索引。我把它们放进一个小对比表这样直观一些数据类型去重能力排序能力典型场景List不支持按插入顺序队列、时间线Set支持不支持标签、去重集合Hash支持field不支持对象存储ZSet支持member按 score 排序排行榜、延迟队列这个对比不是要分高下而是提醒自己ZSet 的强项就是“带权重的去重有序集合”一旦需求里同时出现“唯一性”和“排序”两个词就该优先考虑它。1.3 底层跳跃表为什么它能快速排序和范围查询虽然日常使用不需要深究底层但了解一点能让排查问题时心里有数。ZSet 的核心结构是跳跃表加哈希表哈希表负责按 member 快速定位元素跳跃表负责按 score 排序和范围查询。跳跃表听起来玄乎你可以把它理解成“多层的高速公路”底层是完整的有序链表上层几层是稀疏的“捷径”查找的时候从高层开始跳比如要找分数 95 的元素直接顺着最上层跳过一片低分区间再降级到下一层精确定位。这种设计让 ZSet 的插入、删除、按排名查询平均复杂度都维持在 O(log n) 级别这也是它能顶住高并发读写的根本原因。2. ZSet 常用命令深度拆解从入门到“会用”命令这块我不打算按文档平铺而是按“写、读、改、删”的维度来拆这样你在实际项目里能直接对号入座。每个命令我会说清楚用途、时间复杂度、以及我实际使用时最在意的那些细节。2.1 写入命令ZADD 的四个微妙之处核心命令就是ZADD key score member给指定 key 添加一个 memberscore 写在前面。我第一次用的时候总觉得顺序反了后来就记住了“分数在前成员在后”。ZADD rank:202407 100 user:10086 ZADD rank:202407 80 user:10001一次加多个成员也很方便ZADD rank:202407 90 user:10002 85 user:10003 70 user:10004但这里有个坑如果 member 已经存在单纯的ZADD会更新它的 score覆盖旧值。有次我在做榜单同步原先分数是 500新数据传来只有 300直接覆盖把历史最高分给弄丢了。后来我改成要么先判断要么直接使用ZINCRBY做累加避免误覆盖。另一个细节是 NX 和 XX 选项ZADD key NX 100 member表示只有 member 不存在时才添加ZADD key XX 100 member则只有 member 存在时更新分数。这两个选项在防止误初始化时很有用比如新用户第一次进榜我不希望直接覆盖掉已有数据就可以用 NX。再一个就是 XX 和 NX 的组合问题如果你需要“存在才更新不存在报错”可以通过 Lua 脚本来实现原子判断单纯靠命令选项组合不支持这种模式。我在项目里就写过一个小脚本因为 Redis 命令本身不保证多个步骤的原子性而 Lua 脚本可以让整个判断和执行变成一个原子操作。2.2 读取命令ZRANGE / ZREVRANGE 别再搞混方向ZSet 默认按 score 从小到大排序所以ZRANGE key start stop拿到的是分数最低的那一段。想做排行榜前几名就要用ZREVRANGE反向范围。ZREVRANGE rank:202407 0 9 WITHSCORES上面这段命令返回的是分数最高的 10 个 member 及对应分数。很多人容易把ZRANGE和ZREVRANGE搞反我常用的记忆方法是带REV的就是反着来也就是“从大到小”也就是排行榜默认关心的高分区间。WITHSCORES参数很关键。不加它只返回 member加了它每行后面跟着分数。做排行榜展示的时候这个参数能省掉一次查询。在 Redis 6.2.0 之后ZRANGE还能配合BYSCORE和REV使用比如ZRANGE key 90 100 BYSCORE可以直接按分数区间取不再局限于排名位置。这个在数据过滤时特别好用比如只看“分数在 90 到 100 之间的用户”。我踩过一次比较无语的坑在 Redis 6.0 的客户端里写ZRANGE key 90 100 BYSCORE直接报错查了一下才发现这个语法是 6.2 才引入的。升级 Redis 之前最好先确认版本别让线上环境成为新语法的试验场。2.3 单 key 的聚合查询ZSCORE、ZRANK、ZREVRANK这几个命令属于“精确查人”类比较常用。ZSCORE key member返回某个成员的当前分数。注意如果 member 不存在或者 key 不存在返回nil判断时要做好空值处理。ZRANK key member返回某个成员在集合里的排名从 0 开始按分数升序。ZREVRANK则是降温序排名也就是“第几名”前排第 0 名。我见过有人直接把ZRANK当排行榜名次用结果拿到的是“倒数第几名”因为在升序集合里分数最低的排名是 0。还有一点ZRANK返回的是排名不是分数如果你要从排名反查分数还得再调一次ZSCORE或者使用WITHSCORES的范围查询。实际开发里我更喜欢一次ZRANGE加WITHSCORES把所有前端要的数据拉回来减少网络往返。2.4 更新与删除ZINCRBY 累加更符合业务直觉ZINCRBY key increment member是给某个成员加分比如玩游戏赢了 10 分ZINCRBY rank:202407 10 user:10086这个命令天然支持“累加”在排行榜、评分系统里非常常用。我强调一下它不是简单的10而是原子操作并发下不会出现计算偏差。早期我用“先读后写”的常规逻辑高并发下经常丢分数后来换ZINCRBY之后同一时间多个请求同时加分最后的分数依然是对的。ZREM key member1 member2是删除元素直接按 member 删不用管 score。ZCARD key返回集合元素个数。ZCOUNT key min max返回分数区间内的元素个数注意 min 和 max 是闭区间也就是包含边界的。我在做业务统计时经常用ZCOUNT来查“分数超过 80 的用户有多少”这个比ZSCORE之后再慢慢判断高效得多。区间删除方面ZREMRANGEBYRANK key start stop是按排名位置删ZREMRANGEBYSCORE key min max是按分数区间删。我常用后者做定时清理比如清理“三天前积分过期”的数据把 score 当作过期时间戳然后定时删除分数小于某个时间点的记录。2.5 集合运算ZUNIONSTORE 和 ZINTERSTORE这两个命令容易写错因为参数顺序比较绕。ZUNIONSTORE destination key1 key2是把多个 ZSet 做并集结果写入 destination。ZINTERSTORE是做交集。在做“好友共同爱好”或者“多个榜单合并”时ZINTERSTORE很有用。我做过一个内容推荐模块把用户点过赞的内容 id 放在各自的 ZSet 里分数是点赞权重然后用ZINTERSTORE求两个用户的交集找出共同喜欢的电影列表。WEIGHTS参数可以给每个集合设权重也就是乘法系数比如一个集合权重 1另一个权重 2最终分数按权重合成。AGGREGATE参数决定合并且后分数的计算方式默认是 SUM也可以改成 MIN 或 MAX。这个设计适合“取多个榜单里的最高分”这类需求。3. 实操过程与核心环节实现用 ZSet 搭建高并发排行榜光讲命令太干我挑一个完整的实战案例从需求到落地全走一遍。这个案例是我最近在某个电商项目里做的“销量排行榜”原因很简单运营每天要看“销量前 20 的商品”还要能按小时同步。3.1 需求分析与数据模型设计业务上每个商品有销量销量会随着订单增加而变化后台要实时展示 Top 商品的排名同时也要支持查某个商品的当前名次。数据量不算大商品数量也就几十万个量级但对查询延迟要求很高不能容忍每次都要查数据库。我的方案是用一个全局的 ZSetkey 命名为product:sales:rankingmember 是商品 idscore 是实时销量合计。每次有订单成交就对对应商品执行ZINCRBY增加销量数值。查询 Top 榜用ZREVRANGE product:sales:ranking 0 19 WITHSCORES查单个商品名次用ZREVRANK product:sales:ranking product_id。为什么不用 Redis 的其他结构因为销量要累加、要排序、要查排名这三个要求同时出现的时候ZSet 几乎就是为这个需求量身定做的。Hash 能存销量但排序得自己来List 能排序但没法按商品 id 去重。3.2 核心命令实操流程一个调用的完整链商品 10086 卖掉了一件商品标价 99 元销量按商品件数算所以销量 1。命令ZINCRBY product:sales:ranking 1 10086假如这个商品原本就有 50 件销量执行完之后 score 变成 51。这个递增是原子的就算同一秒有 100 个订单进来并发执行ZINCRBY最终分数也不会少。前端页面加载榜单时一次性拉取前 20 名和分数ZREVRANGE product:sales:ranking 0 19 WITHSCORES返回的格式是 “10086 51 10001 49 ...”每条记录后面跟着对应分数。客户端解析时要注意Redis 返回的相邻两个元素构成一个 member-score 对别解析错了。查某个商品排名的时候用ZREVRANK product:sales:ranking 10086。如果返回 0说明排在第一名返回 nil说明这个商品还没有进入榜单。排名加 1 才是业务上常说的“第几名”因为底层排名是从 0 开始的。这个小细节在和前端对接时特别容易栽跟头前端往往直接拿排名展示最后显示“第 0 名”闹过不少笑话。商品下架时要把这个商品从榜单里去掉调用ZREM product:sales:ranking 10086否则下架商品还在榜单上误导用户。如果保留历史数据的需求就不删除只让它不再输出这取决于业务口径。3.3 扩展用 ZSet 实现简易延时队列排行榜是 ZSet 最常见的使用场景但另一个被低估的玩法是“延时队列”。核心思路把每个任务作为 member把任务的执行时间戳作为 score。然后用一个后台守护进程循环扫描ZRANGEBYSCORE task:queue -inf 现在的时间戳这样就能拿到所有已经到了执行时间的任务处理完用ZREM删除。如果想要支持“任务重复执行”可以用ZINCRBY把 score 更新到下个周期相当于给任务重新排队了。我实际做过一个订单超时自动取消的模块用户下单 30 分钟未支付就自动关闭。我把订单 id 放进 ZSetscore 是“下单时间 1800 秒”然后每隔 5 秒扫一次ZRANGEBYSCORE task:order 0 当前时间戳取出的单子去关闭。这个方案比单纯轮询数据库更轻量也不会漏单只要 Redis 不宕机基本能保证准点。当然对于要求超高可靠性的场景还是要配合持久化或者消息队列兜底。3.4 容量控制与过期策略ZSet 不断往上涨的时候老数据的清理也要想清楚。排行榜类数据随着商品累积越来越多老商品可能一直排在底部没必要永远占用内存。我习惯定时执行ZREMRANGEBYRANK把排名靠后的尾部数据删掉只保留前 N 个。比如只需要 Top 1000直接ZREMRANGEBYRANK product:sales:ranking 0 -1001意思是删除从 0 到倒数第 1001 名之间所有元素保留最后 1000 个。ZREMRANGEBYRANK的几个参数我提醒一下start和stop都是下标负数从尾部计数-1是最后一个元素。所以想保留后 1000 个就是要删除 0 到-1001也就是倒数第 1001 个开始所有更早的元素。这个逻辑容易绕写错了可能把整个榜单删光我建议在测试环境先验证再上线。另外ZSet 本身和 Redis 其他 key 一样受EXPIRE控制。如果整个排行榜只需要保留 7 天直接设EXPIRE product:sales:ranking 604800就行。但要注意每次ZINCRBY操作不会重置过期时间也就是说如果你设置的是固定过期那到了时间整个 key 都会被清掉而不是“每次有更新就续期”。如果希望“活跃就续命”需要在每次写操作之外单独再执行EXPIRE。4. 常见问题与排查技巧实录那些文档里不写的坑命令用熟了真正让人头疼的是现实中遇到的问题。我整理几个我实际碰到过的情况每个都附上排查思路和解决方式希望能帮你少走些弯路。4.1 分数精度别让浮点数毁掉公平排行ZSet 的 score 底层是双精度浮点数理论上可以存整数、小数但浮点数有个固有毛病精度有限。举个例子分数是 0.1连加三次看起来是 0.3实际存储可能是 0.30000000000000004。我在做评分系统时遇到过这种情况两个用户理论分数一样排名却因为浮点尾数产生微小差异。我的处理原则是能不用小数就不用小数。业务上如果需要“积分带小数位”我会把分数放大成整数比如保留两位小数就乘以 100所有加减都在整数上做展示的时候客户端再还原。这样既避免精度问题又让ZINCRBY演算更可靠。另一个视角是score 本来就是个“可比较的数”不一定非得是业务得分。你完全可以把 score 设计成一个复合数值比如“排名主优先级 * 10000 提交时间戳的尾数”。我做过一个活动榜单先按完成任务数排名任务数相同再按完成时间先后来排直接用一个 key 把这两个维度压进同一个 score规则就变得特别简单。4.2 内存占用别把整个无限榜单塞进去ZSet 的复杂度在数据量特别大的时候依然表现不错但内存不会说谎。每个 member 在 Redis 里都占额外空间跳跃表的层级结构更是不小。我见过有人往一个 ZSet 里塞了几百万个商品虽然读写还行但内存直接被吃掉一大块。控制内存的两个办法定期清理尾部分数很低的数据比如保留 Top 10000另一个是把 ZSet 用在“分层场景”里不要试图用一个 key 装下全部维度。我做过一个分品类榜单先把每个品类做成小 ZSet再汇总一个大 ZSet 做总榜这样既能细分查询又不会让单个 key 无限膨胀。排查内存问题时Redis-cli --bigkeys可以扫出哪些 key 最大。我用这个工具查过一次发现有个程序员把 ZSet 当 Set 用score 全是固定值白白浪费了排序结构后来改成 Set 之后内存立减。4.3 批量更新与性能优化管道能救你业务里经常遇到“批量给一批用户加分”比如运营活动给 1000 个用户每人加 5 分。新手最容易犯的错误是写个 for 循环一条一条执行ZINCRBY这样 1000 条命令要来回 1000 次网络往返性能很难看。正确姿势是用 Pipeline。Redis 客户端一般都有管道功能比如 Python 的 Redis 包里有pipeline可以把多条命令一次性发给 Redis 服务器减少 RTT。我经常这么写p redis_client.pipeline() for user_id in user_ids: p.zincrby(rank:activity, 5, user_id) p.execute()这里有个细节Pipeline 不等于事务。Pipeline 只是批量发送不保证原子性中间任何一条命令失败不会回滚前面的。如果要求“要么全部加分要么都不加”就要用 Lua 脚本或者MULTI/EXEC事务。我建议大多数场景用 Pipeline 足够除非业务上真有原子性要求。4.4 key 冲突与命名规范不要混用同名不同结构ZSet、Set、List 在 Redis 里是共用 key 命名空间的。也就是说一个 key 如果你先当 Set 用后面又用 ZSet 的命令去操作不但报错还会带来数据混乱。我遇到过最头疼的事故某同事把排行榜 key 先建成了普通 Set后面对它执行ZREVRANGE直接返回错误原因就是结构冲突。我的习惯是给 ZSet 的 key 加上统一后缀或前缀比如zset:product:sales或者product:sales:zset至少从命名上让人一眼看出来这是有序集合。另外建议在项目的 Redis 规范文档里把“哪些 key 用什么结构”写清楚防止不同模块互相覆盖。4.5 分布式环境下的一致性考量ZSet 的单命令操作如ZINCRBY是原子的这一点很重要但多个命令组合在一起时不保证原子。如果你想实现“判断 member 存在才加分”这种复杂组合直接用单条命令做不到。我采用的方法是 Lua 脚本把整个判断和更新逻辑写进脚本里Redis 保证脚本在单线程下执行从而满足原子性。延迟队列场景里也可能遇到重复消费。两个消费者同时扫到同一批任务都去执行就重复了。解决办法可以用ZREM的返回值做判断只有真正删除了某个 member 的消费者才拥有处理权因为ZREM返回 1 代表删掉了返回 0 说明已经被别人抢走了。这个技巧比加锁简单得多。4.6 ZSet 数据持久化与灾备别让榜单一夜清零Redis 默认的持久化配置不一定万无一失。我见过一个项目只开了 RDB 快照结果 Redis 进程突然崩溃最后几分钟内的 ZSet 数据全丢了排行榜从一片热闹变成空白。后来我把配置改成同时开启 AOF每次写命令都会追加日志数据丢的概率大大降低。如果你对数据可靠性要求比较高可以使用appendonly yes并合理设置appendfsync策略。appendfsync everysec是性能和可靠性的折中每秒刷一次盘就算宕机最多丢 1 秒数据。要是完全不能丢可以设置always但性能会下降不少。在写 ZSet 那种频繁ZINCRBY的场景用everysec我实测下来基本够用。5. 更进一步ZSet 的更多玩法与我的体会排行榜和延迟队列是 ZSet 最出名的两个用法但把它用熟了你会发现更多顺手的小技巧。5.1 用 ZSet 做去重滑动窗口限流、防刷场景里滑动窗口是经典算法。ZSet 可以很优雅地实现它member 是请求唯一标识score 是请求时间戳。某个用户发起请求时先把当前时间戳插入 ZSet然后统计最近一分钟内有多少条记录如果超过阈值就拒绝。窗口过期后用ZREMRANGEBYSCORE把旧时间戳删掉。ZADD rate:user:10086 当前时间戳 request_id ZCOUNT rate:user:10086 现在-60秒 现在这个方案实现起来特别短而且天然支持多维度限流比如每个用户单独一个 key。不过我提醒一下默认情况下一个用户一秒钟能产生大量请求ZSet 里会积攒很多 member一定记得配合ZREMRANGEBYSCORE定时清理避免内存爆炸。5.2 基于 ZSet 的时间线合并假如你有两个不同来源的 feed 流各自带时间戳想合并成一个全局时间线ZUNIONSTORE一下就出来了。把两个 key 的 score 都设置成时间戳然后ZUNIONSTORE merged 2 feed1 feed2最终结果按时间排列直接用ZREVRANGE就能拿到最新内容。这个技巧在做聚合时间线、聚合通知时很实用。5.3 我个人在项目里的最终体会用 ZSet 做核心数据结构最大的好处是少写了很多“逻辑胶水”。以前用数据库找前 N 名得写 SQL、加索引、考虑缓存用 Set 做去重还得额外维护一个排序容器。有了 ZSet代码里几个方法就搞定而且天然支持并发安全。坑也不是没有。最容易被低估的是“成员混乱”有人往里面塞了团队 id有人塞了商品 id结果 key 冲突最后数据乱七八糟。规范就是一切从命名到结构都要有规约。另一个是“误用”有同事为了省内存把一个 ZSet 的 score 全部设成 0几乎没有利用到排序能力这种情况下不如直接换 Set省下跳跃表那部分开销。如果你刚接触 ZSet我的建议是先不要背命令表直接开一个 redis-cli 做实验把 ZADD、ZREVRANGE、ZINCRBY、ZREM 四个命令熟悉起来配合业务场景去写比如试着给好友列表做一个“亲密度排行”整个过程走一遍你就懂这个数据类型的独特之处了。最后分享一个小经验我测试环境里长期放着一个zset:demo专门用来做命令验证。每次不确定某个参数行为就先去那几个 key 上试一遍验证完再回写业务代码。这种“不信直觉只信实测”的习惯帮我避开了很多文档描述含糊的细节坑。