## 01、痛点

我是老李，在电商后端打杂多年。最近赶上大促，业务侧的需求像雪片一样飞过来：用户注册后要排队发短信、发券；平台要分析用户兴趣做推荐；还要实时展示商品 Top100 榜单。一开始我们拿数据库硬扛，队列用表加轮询，标签去重靠代码判断，榜单用 SQL 排序并缓存。结果大促当天，队列延迟超过 30 秒，标签查询拖垮了从库，榜单更新不及时，老板脸色很不好看。

问题表面上是性能，本质是数据结构选错了。我们把所有的场景都当成普通键值缓存，忽略了 Redis 最经典的一组能力：List、Set、ZSet。很多人知道 Redis 有这几种数据结构，但到了建模的时候，还是只把 Redis 当作文本缓存，或者死记命令，不理解背后的数据语义。

正好 Redis 8.10 发布了，新增了 LMOVEM/BLMOVEM，可以一次移动多个 List 元素；还增加了 SUNIONCARD/SDIFFCARD，直接计算集合结果数量，不再需要把完整集合物化出来。这两个增强让经典的队列、集合统计场景更加高效。所以我觉得，现在值得重新聊聊这组“数据结构三剑客”。

## 02、是什么

Redis 的 List、Set、ZSet 分别对应三种最基础的数据关系：

- List：有序序列。元素按插入顺序排列，允许重复，支持从队列两端推入或弹出。底层早期是双向链表，后来优化为 quicklist（链表和紧凑列表的组合）。
- Set：无序唯一集合。元素不重复，支持交集、并集、差集。底层小集合用整数集合 intset，大集合用哈希表 hashtable。
- ZSet：带 Score 的有序集合。每个元素有一个双精度浮点数 Score，元素唯一，按 Score 排序。底层是跳表 skiplist 加字典 dict，跳表保证有序和区间查询，字典保证 O(1) 查找。

Redis 8.10 带来的新命令也很直白：

- LMOVEM / BLMOVEM：LMOVE 原本只移动一个元素，现在可以一次从源 List 弹出多个元素并推入目标 List。BLMOVEM 是阻塞版本，源列表为空时等待。
- SUNIONCARD / SDIFFCARD：给定多个集合，直接返回它们并集或差集的基数，也就是元素个数，不需要先生成完整的并集或差集结果。

理解这些结构时，别急着背命令。List 的核心是“顺序”，Set 的核心是“唯一性”，ZSet 的核心是“排序”。抓住这三点，建模选择就不会跑偏。

## 03、为什么

为什么理解数据结构比背命令更重要？因为业务需求最终会落到三种关系上：先来后到、不能重复、按分排序。

- 任务队列需要严格顺序，先提交的任务先处理，允许消息重复但最好幂等——这是 List 的强项。
- 用户兴趣标签要天然去重，不能出现两个“篮球”；求两人共同关注，本质是集合交集——这是 Set 的强项。
- 实时榜单需要按热度或销量排序，每次行为更新分数，快速取 Top N——这是 ZSet 的强项。

如果选错结构，代价很大。用 List 做去重，需要额外判断 contains，O(N) 代价；用 Set 做有序队列，顺序不可控；用 ZSet 做无排序集合，白白维护 Score 和跳表，内存开销高不少。

新命令的价值也在于此。假设你有 10 个兴趣标签集合，想知道覆盖用户总数，但不需要用户列表。传统做法是 SUNION 求出完整并集，再 SCARD 取大小。当集合并集有上千万元素时，这个物化过程会消耗大量内存和 CPU。SUNIONCARD 直接返回基数，省掉结果集分配。BLMOVEM 一次移动多个任务，减少了消费者频繁往返 Redis 的次数，也降低了队头阻塞的影响。这些都是在已选对结构的基础上，做的效率优化。

## 04、架构

在 Spring Boot 应用里，Redis 通常作为内存数据结构服务，与 MySQL 等持久化存储配合。架构分层大概是：

- 应用服务：Spring Boot，使用 RedisTemplate 或 StringRedisTemplate 访问 Redis。
- 数据访问：通过 opsForList()、opsForSet()、opsForZSet() 获得对应的操作接口。
- Redis 服务：单线程命令处理，内存存储，支持持久化。

三种结构在架构中的角色要清晰：

- List 负责异步解耦。比如用户注册后，请求线程只把任务 JSON 推入 List，后台消费者异步处理短信、优惠券，避免阻塞主流程。
- Set 负责关系与属性。比如用户兴趣标签、文章点赞用户、共同关注关系。
- ZSet 负责实时排序。比如商品热度榜、游戏排行榜、按时间戳的延迟任务队列。

在代码抽象上，Spring Data Redis 提供了：

- ListOperations：leftPush/rightPop/range 等，新命令 LMOVEM/BLMOVEM 可能需要通过 execute 原生命令调用。
- SetOperations：add/members/intersect/union/difference 等，新命令 SUNIONCARD/SDIFFCARD 也可封装。
- ZSetOperations：add/incrementScore/reverseRangeWithScores 等。

架构层面还要注意：Redis 是单线程命令处理，批量命令能减少往返次数，提高吞吐；阻塞命令要设置超时，避免线程挂起；大集合操作要注意时间复杂度。建议按业务场景拆分 Redis 实例或 DB，避免一个慢操作影响全局。

## 05、实战

下面给出三个最典型的 Spring Boot 实战场景。

### 场景一：List 做任务队列

需求：用户注册后，发短信和发放优惠券异步执行。我们用 List 左手出右手进：左推入队，右弹出队；如果处理失败，再放回备份队列。

```java
// 入队
redisTemplate.opsForList().leftPush("task:queue", taskJson);
// 消费者取一条
String task = redisTemplate.opsForList().rightPop("task:queue", 5, TimeUnit.SECONDS);
// 8.10 新命令：一次移动多个任务（伪代码示意）
List<String> tasks = redisTemplate.execute((RedisCallback<List<String>>) conn ->
        conn.listCommands().blMoveMany("task:queue", "task:processing", ...));
```

传统 BLMOVE 一次搬一个，消费者要频繁调用；BLMOVEM 一次搬多个，吞吐量明显提升。不过要注意 Spring Data Redis 的版本支持，必要时用原生连接执行。

### 场景二：Set 做用户兴趣标签

需求：用户有多个兴趣标签，求两个用户的共同兴趣；求某几个标签覆盖的总用户数；文章点赞自动去重。

```java
// 添加标签
redisTemplate.opsForSet().add("user:1:tags", "篮球", "数码", "旅行");
redisTemplate.opsForSet().add("user:2:tags", "篮球", "读书", "旅行");
// 共同兴趣
Set<String> common = redisTemplate.opsForSet().intersect("user:1:tags", "user:2:tags");
// 点赞去重
redisTemplate.opsForSet().add("article:100:likes", "user:1");
Long likes = redisTemplate.opsForSet().size("article:100:likes");
// 8.10 新命令：直接统计多个标签覆盖总用户数（伪代码示意）
Long unionCard = redisTemplate.execute((RedisCallback<Long>) conn ->
        conn.setCommands().sUnionCard("user:1:tags", "user:2:tags"));
```

求“用户共同关注”本质上就是两个 Set 的交集；文章点赞去重就是 Set 的 add + size；新命令 SUNIONCARD 适合统计“至少关注了 A 或 B 的用户数”，不用拉取全部用户。

### 场景三：ZSet 做实时 Top100 商品榜

需求：商品每次被浏览或下单，热度加一，实时显示前 100 名。

```java
// 热度加一
redisTemplate.opsForZSet().incrementScore("product:rank", "product:1001", 1);
// 取 Top100
Set<ZSetOperations.TypedTuple<String>> top = redisTemplate.opsForZSet()
        .reverseRangeWithScores("product:rank", 0, 99);
// 获取某商品排名
Long rank = redisTemplate.opsForZSet().reverseRank("product:rank", "product:1001");
```

ZSet 的 Score 更新是 O(log N)，Top N 查询很快。游戏排行榜也是同样套路：Score 存积分或战力，ZREVRANGE 取前十。

三个测验场景的答案：用户共同关注用 Set 交集；文章点赞去重用 Set；游戏排行榜用 ZSet。

## 06、洞见

这组数据结构之所以经典，是因为它们对应了业务中最基础的三种关系：顺序、唯一、排序。现实业务往往是这三种的组合。例如“按时间排序的去重队列”，可能需要先 Set 去重，再用 List 或 ZSet 保证顺序；又如“用户最近浏览商品去重并按时间排序”，可以用 ZSet，Score 为时间戳，元素为商品 ID，天然去重且排序。

命令是表面，结构是本质。新命令 LMOVEM/BLMOVEM、SUNIONCARD/SDIFFCARD 只是把原本需要多次往返或物化结果的操作合并了，但前提是你已经选对了结构。如果业务本质是唯一性，你却用 List 加代码判断去重，即使有 LMOVEM 也解决不了核心问题。

一些容易踩的坑也要提醒：

- List 做队列要处理消息丢失。消费者崩溃可能导致元素丢失，所以可靠队列常用 BLMOVE 将元素移到处理中队列，处理完成再删除。
- Set 的 sinter 在大集合上可能阻塞。SUNIONCARD/SDIFFCARD 虽然不物化结果，但时间复杂度仍是 O(N*M)，要评估集合大小。
- ZSet 的 Score 是双精度，会有精度问题；底层 skiplist 内存开销比 Set 大，不要把所有排序需求都塞进去。

Spring Data Redis 对新命令的封装往往滞后。在生产中使用 Redis 8.10 新能力时，可以用 RedisTemplate.execute 调用原生命令，并封装成工具类，避免业务代码直接依赖底层连接。

## 07、行动

如果看完文章你只记住三句话：List=顺序，Set=唯一，ZSet=排序，那已经解决了大部分建模问题。

接下来可以落地几件事：

第一，梳理现有系统中哪些数据具有顺序、唯一、排序特征。把 Redis 从“字符串缓存”升级为“数据结构服务”。

第二，评估两个新命令的适用场景。如果有循环调用 LMOVE 的地方，升级后改为 BLMOVEM 一次移动多个；如果只需要集合基数而不需要元素列表，替换为 SUNIONCARD/SDIFFCARD。

第三，在 Spring Boot 中封装统一的 Redis 工具类，屏蔽版本差异。新命令用 execute 原生调用，旧版本则降级为组合命令。

第四，升级前务必在测试环境验证 Redis 8.10 与客户端库的兼容性，并压测新命令的性能。

第五，监控 Redis 的命令延迟、内存占用、慢查询，尤其是大集合操作。必要时拆分实例，避免相互影响。

## 08、小结

Redis 最经典的能力不是缓存字符串，而是提供数据结构。List 处理顺序，Set 处理唯一性，ZSet 处理排序，这是业务建模的三张王牌。Redis 8.10 新增的 LMOVEM/BLMOVEM 和 SUNIONCARD/SDIFFCARD，分别优化了 List 的批量移动和 Set 的基数计算，让这些经典场景跑得更快。

记住：先理解业务需要顺序、唯一还是排序，再去选结构；选对结构之后，命令只是效率问题。别当只会 set/get 的缓存工程师，把 Redis 的数据结构用起来，那些看似复杂的队列、标签、榜单需求，其实就那么回事。

## 09、链接与概念说明

**官方文档**

- Redis List 命令：https://redis.io/commands/?group=list
- Redis Set 命令：https://redis.io/commands/?group=set
- Redis Sorted Set 命令：https://redis.io/commands/?group=sorted-set
- Spring Data Redis 文档：https://spring.io/projects/spring-data-redis

**概念说明**

- quicklist：List 底层结构，早期是双向链表，后来优化为链表加紧凑列表，兼顾内存与效率。
- intset/hashtable：Set 底层结构。元素全部为整数且数量较少时用 intset，节省内存；否则转为 hashtable。
- skiplist+dict：ZSet 底层结构。跳表保证按 Score 有序，字典保证 O(1) 查找元素 Score。
- Score：ZSet 中用于排序的双精度浮点数，可以重复，但元素必须唯一。
- 基数（cardinality）：集合中元素的数量。SUNIONCARD/SDIFFCARD 直接返回并集/差集的基数，不生成完整结果集。
- 阻塞命令：BLMOVEM 在源 List 为空时阻塞等待，直到有元素或超时，需要设置合理超时防止线程挂起。

我是老李，在电商后端打杂多年。最近赶上大促，业务侧的需求像雪片一样飞过来：用户注册后要排队发短信、发券；平台要分析用户兴趣做推荐；还要实时展示商品 Top100 榜单。一开始我们拿数据库硬扛，队列用表加轮询，标签去重靠代码判断，榜单用 SQL 排序并缓存。结果大促当天，队列延迟超过 30 秒，标签查询拖垮了从库，榜单更新不及时，老板脸色很不好看。

《Redis 8.10 + Spring Boot 实战》第5招 List、Set、ZSet——从队列、集合到排行榜

从顺序、唯一到排序，讲透 Redis 三种核心数据结构，并结合 8.10 新命令给出 Spring Boot 实战与建模建议。

架构师

数据库

后端

职业发展

Redis的List、Set、ZSet是业务建模的三张王牌：List处理顺序（队列）、Set处理唯一（去重/交集）、ZSet处理排序（Top榜单）。Redis8.10新增LMOVEM/BLMOVEM批量移动List元素、SUNIONCARD/SDIFFCARD直接计算集合基数，大幅优化经典场景效率。文章通过三个SpringBoot实战案例，演示如何用数据结构解决任务队列、用户标签、实时榜单等真实业务问题，并给出了结构选型与架构落地的可操作建议。

数据结构

代码解释

短信

MySQL

Redis

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis的List、Set、ZSet是业务建模的三张王牌：List处理顺序（队列）、Set处理唯一（去重/交集）、ZSet处理排序（Top榜单）。Redis8.10新增LMOVEM/BLMOVEM批量移动List元素、SUNIONCARD/SDIFFCARD直接计算集合基数，大幅优化经典场景效率。文章通过三个Spri...

《Redis 8.10 + Spring Boot 实战》第5招 List、Set、ZSet——从队列、集合到排行榜-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第5招 List、Set、ZSet——从队列、集合到排行榜

《Redis 8.10 + Spring Boot 实战》第5招 List、Set、ZSet——从队列、集合到排行榜

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐