【Redis合集-03】Redis常用数据结构选型指南｜面试&生产场景全覆盖

# 基本 SET / GET
SET user:1:name "zhangsan"
GET user:1:name

# 批量操作（减少网络 RTT）
MSET user:1:age 25 user:1:city "beijing"
MGET user:1:name user:1:age user:1:city

# 数值操作（计数器）
INCR article:100:views
INCRBY article:100:views 10
DECR article:100:views

# 设置过期时间
SETEX token:abc123 3600 "user_session_data"

# 不存在才设置（分布式锁的基石）
SETNX lock:order:123 unique_value
# Redis 7 推荐使用 SET ... NX EX 原子命令
SET lock:order:123 unique_value NX EX 30

# 获取并设值
GETSET counter "0"    # 旧版本，现推荐 GETEX 或组合命令
GETEX key EX 60        # 获取值同时设置过期时间

2.3 应用场景补充

缓存对象

把对象序列化成 JSON 存成 string。优点：简单。缺点：频繁修改某个字段时需要整体读出来再写回去，浪费流量和 CPU。如果对象修改频繁，后面讲的 hash 更适合。

// Spring Boot 示例
redisTemplate.opsForValue().set("user:1", JSON.toJSONString(user), 30, TimeUnit.MINUTES);

分布式锁

用 string 实现简单的分布式锁。Java 代码展示一个完整版：

String lockKey = "lock:order:123";
String clientId = UUID.randomUUID().toString();
// 加锁，同时设置过期时间防止死锁
Boolean lockSuccess = redisTemplate.opsForValue()
        .setIfAbsent(lockKey, clientId, 10, TimeUnit.SECONDS);
if (Boolean.TRUE.equals(lockSuccess)) {
    try {
        // 执行业务
    } finally {
        // 释放锁：lua 脚本保证原子性，判断 value 是否为当前客户端
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        redisTemplate.execute(new DefaultRedisScript<>(script, Long.class),
                Collections.singletonList(lockKey), clientId);
    }
}

计数器与限流

文章阅读量、API 调用次数等直接用 INCR。滑动窗口限流可以基于 string + 过期时间实现：

String rateKey = "rate:api:" + userId;
Long count = redisTemplate.opsForValue().increment(rateKey);
if (count == 1) {
    redisTemplate.expire(rateKey, 1, TimeUnit.MINUTES);
}
if (count > 100) {
    throw new RuntimeException("请求过于频繁");
}

注意：这种简易限流不是滑动窗口的，更精确的需要用 zset 或 Redis-Cell 模块。

3. Hash 类型应用

Hash 适合存储对象，特别是那些字段经常单独更新的场景。内部编码有 listpack（Redis 7 中取代了 ziplist）和 hashtable。

3.1 常用命令

HSET user:1 name "lisi" age 28 city "shanghai"   # 设置哈希表 user:1 中的多个字段：name="lisi", age=28, city="shanghai"。返回新添加的字段数量（此处为3）
HGET user:1 name                                 # 获取哈希表 user:1 中字段 name 的值，返回 "lisi"
HMGET user:1 name age                            # 批量获取字段 name 和 age 的值，返回 ["lisi", "28"]
HINCRBY user:1 age 1                             # 将字段 age 的值增加 1（原子操作），返回增加后的值（29）。要求原值可解析为整数
HGETALL user:1                                   # 获取哈希表 user:1 中所有字段和值，以列表形式返回，如 ["name","lisi","age","29","city","shanghai"]
HEXISTS user:1 name                              # 检查字段 name 是否存在，存在返回 1，不存在返回 0
HDEL user:1 city                                 # 删除字段 city，返回成功删除的字段数量（1）
HLEN user:1                                      # 返回哈希表 user:1 中的字段数量（删除 city 后，还剩 name 和 age，所以返回 2）
HSCAN user:1 0 MATCH *                           # 大 hash 用 scan 避免阻塞：迭代哈希表 user:1 中的字段。游标从 0 开始，MATCH * 匹配所有字段。每次返回一批字段和值，用于安全遍历大哈希

3.2 实战：购物车

# 用户1 的购物车
HSET cart:1 1001 2    # 设置哈希表 cart:1 中商品1001的数量为2（如果字段不存在则创建，存在则覆盖）。返回新添加的字段数量（此处为1）
HSET cart:1 1002 1    # 添加商品1002，数量为1。返回新添加的字段数量（此处为1）
HINCRBY cart:1 1001 1 # 将商品1001的数量增加1（原子操作），返回增加后的数量（3）。可用于购物车加一件商品
HGETALL cart:1        # 获取购物车中所有商品ID和数量，以列表形式返回，如 ["1001","3","1002","1"]

用 hash 存购物车的好处是每个商品数量可以独立操作，不用像 string 那样序列化整个对象。

3.3 底层优化

当字段数量少且每个字段值短时，hash 用 listpack 紧凑存储，节省内存；当超过 hash-max-listpack-entries 或 hash-max-listpack-value 时转为 hashtable。Redis 7 用 listpack 替代了 ziplist，级联更新问题彻底解决。

4. List 类型应用

List 是简单的字符串列表，底层用 quicklist（Redis 7 仍是 quicklist，但内部节点用 listpack 替代了 ziplist）。它可以用作栈、队列、阻塞队列等。

4.1 常用命令

LPUSH queue "task1" "task2"   # 将一个或多个值插入到列表 queue 的头部（左侧）。返回插入后列表的长度。此处插入 task1, task2，顺序为：先插入 task1，再插入 task2，因此 task2 在头部
RPUSH queue "task3"           # 将一个或多个值插入到列表 queue 的尾部（右侧）。返回插入后列表的长度。此处 task3 追加到末尾
LPOP queue                    # 移除并返回列表 queue 头部（最左侧）的元素。如果列表为空，返回 nil。此处返回 "task2"（因为上一步 LPUSH 后头部是 task2）
RPOP queue                    # 移除并返回列表 queue 尾部（最右侧）的元素。如果列表为空，返回 nil。此处返回 "task3"（因为上一步 RPUSH 添加了 task3 到尾部）
LRANGE queue 0 -1             # 返回列表 queue 中指定区间的元素。索引从 0 开始，-1 表示最后一个元素。0 -1 表示返回所有元素。结果以数组形式返回
BLPOP queue 5                 # 阻塞式左弹出（Blocking Left Pop）：依次检查多个列表（此处只有一个 queue），如果指定列表非空则立即弹出头部元素；如果所有列表都为空，则阻塞等待最多 5 秒。超时后返回 nil。适用于生产者-消费者模式

BLPOP queue 5 之所以适用于生产者-消费者模式，是因为它解决了消费者端的关键问题：如何高效地等待新任务。

传统轮询的缺陷：如果消费者不断用 LPOP 检查队列，队列为空时会产生大量无效请求（CPU 空转 + 网络开销）。

BLPOP 的阻塞机制：当队列为空时，消费者会阻塞等待，直到：

生产者通过 LPUSH / RPUSH 向队列中推入新元素 → 消费者立即弹出该元素并继续处理。

或者超过指定的超时时间（此处为 5 秒）→ 返回 nil，让消费者有机会做其他任务或重试。

优势总结：

零无效轮询：不浪费 CPU 和 Redis 资源。

即时响应：任务到达后立即被唤醒，延迟低。

避免死等：超时机制防止消费者永久阻塞。

典型场景：多个消费者进程/线程同时 BLPOP 同一个队列，Redis 保证每个任务只被一个消费者取走，实现天然的负载均衡和任务分发。

4.2 实战：消息队列（简易版）

利用 BLPOP（最左侧） 或 BRPOP （最右侧）可以实现简单的生产者-消费者模型：

# 消费者1
BRPOP task_queue 0   # 永久阻塞等待
# 生产者
LPUSH task_queue "send_email"

这种队列没有 ack 机制，消息一旦弹出就没了，可靠性不如后面的 Stream。

4.3 实战：最新评论列表

用 LPUSH 插入新评论，LTRIM 保持固定长度：

LPUSH comment:article:100 "comment1"   # 将评论 "comment1" 插入到文章100的评论列表头部（左侧）。此时列表：["comment1"]
LPUSH comment:article:100 "comment2"   # 再将 "comment2" 插入头部，新评论在前。列表变为：["comment2", "comment1"]
LTRIM comment:article:100 0 9          # 修剪列表，只保留索引0到9的元素（即最多10条）。由于当前只有2条，全部保留。常用于控制评论列表最多显示最新10条（最新的在头部）
LRANGE comment:article:100 0 -1        # 返回列表所有元素（索引0到-1）。结果为 ["comment2", "comment1"]，即最新评论在最前面

5. Set 类型应用

Set 是无序的字符串集合，支持交并差集。

5.1 内部编码

Set 有两种底层实现：

intset：当集合元素全是整数且数量较少时使用，有序存储，节省内存。
dict：当出现非整数元素或元素数量超过 set-max-intset-entries 时，转为哈希表，value 都为 NULL。

Redis 7 还优化了 intset 的转换条件。

5.2 常用命令

SADD users:follow:1 "user2" "user3"           # 将 user2 和 user3 添加到集合 users:follow:1 中（用户1的关注集合）。返回成功添加的元素数量（2）
SREM users:follow:1 "user2"                  # 从集合中移除 user2。返回成功移除的元素数量（1）
SMEMBERS users:follow:1                      # 返回集合中的所有成员，结果为 ["user3"]（无序）
SISMEMBER users:follow:1 "user2"             # 检查 user2 是否在集合中，存在返回1，不存在返回0（此处返回0）
SCARD users:follow:1                         # 返回集合中的元素个数，此处为1（只有 user3）

# 集合运算
SADD set1 a b c                               # 向集合 set1 中添加元素 a, b, c，返回添加数量（3）
SADD set2 b c d                               # 向集合 set2 中添加元素 b, c, d，返回添加数量（3）
SINTER set1 set2                              # 返回两个集合的交集：["b", "c"]
SUNION set1 set2                              # 返回两个集合的并集：["a","b","c","d"]（顺序可能不同）
SDIFF set1 set2                               # 返回差集（set1 中有但 set2 中没有的元素）：["a"]
SINTERSTORE dest set1 set2                    # 计算 set1 和 set2 的交集，并将结果存储到新集合 dest 中（如果 dest 已存在则覆盖）。返回交集元素个数（2）。此命令原子完成，且避免网络传输大量数据

5.3 实战场景补充

共同关注 / 推荐好友

# 用户1和用户2的关注列表
SADD follow:1 userA userB userC
SADD follow:2 userB userC userD

# 共同关注
SINTER follow:1 follow:2   # userB userC

# 推荐给用户1：用户2关注了但用户1没关注的
SDIFF follow:2 follow:1    # userD

抽奖系统

# 将所有参与抽奖的用户放入set
SADD lottery "user1" "user2" "user3" "user4"

# 随机抽取1名用户（不删除）
SRANDMEMBER lottery 1

# 随机抽取1名并移除（保证不重复中奖）
SPOP lottery 1

标签系统

用 Set 给文章打标签，例如：

SADD article:1:tags "redis" "database"
SADD article:2:tags "redis" "cache"
# 返回同时拥有两个标签的文章 → "article1"
SINTER article:1:tags article:2:tags

6. Zset（Sorted Set）类型应用

Zset 是带分数的有序集合，内部使用 skiplist + dict 实现，兼顾范围查找和按成员查分的效率。Redis 7 在小数据量时先用 listpack 紧凑存储。

6.1 常用命令

ZADD rank 100 user1 90 user2 80 user3          # 向有序集合 rank 中添加三个成员，分数分别为 100(user1)、90(user2)、80(user3)。返回成功添加的数量（3）
ZINCRBY rank 5 user2                           # 给 user2 的分数增加 5 分（原子操作），返回增加后的分数（95）。若成员不存在则自动添加并设置分数为 5
ZRANGE rank 0 -1 WITHSCORES                    # 按分数升序返回所有成员及其分数（索引 0 到 -1）。结果为 ["user3","80","user2","95","user1","100"]
ZREVRANGE rank 0 -1 WITHSCORES                 # 按分数降序返回所有成员及其分数。结果为 ["user1","100","user2","95","user3","80"]
ZSCORE rank user1                              # 返回 user1 的分数，结果为 "100"
ZRANK rank user1                               # 返回 user1 在升序排名中的索引（分数最低的排名为 0）。user1 分数最高，排名为 2（因为 user3 索引0，user2索引1，user1索引2）
ZREVRANK rank user1                            # 返回 user1 在降序排名中的索引（分数最高的排名为 0）。user1 分数最高，所以返回 0
ZCOUNT rank 80 100                             # 返回分数在闭区间 [80, 100] 内的成员数量。所有三个成员分数均在区间内，返回 3
ZREMRANGEBYRANK rank 0 2                       # 移除升序排名索引从 0 到 2 的成员（即分数最低的前3个成员）。此处所有成员（索引0、1、2）均被删除，rank 变为空集合

6.2 实战：排行榜

# 游戏积分榜
ZADD game_score 500 playerA 480 playerB 450 playerC
# Top 3
ZREVRANGE game_score 0 2 WITHSCORES
# 查询玩家排名
ZREVRANK game_score playerA

6.3 实战：延迟队列

利用 score 作为时间戳，消费者不断获取分数 ≤ 当前时间的元素并处理。

# 生产者添加延迟任务
ZADD delay_queue 1680000000 "order_timeout_123"
# 消费者定期拉取到期的任务
ZRANGEBYSCORE delay_queue 0 1680000000 LIMIT 0 10
# 处理完删除
ZREM delay_queue "order_timeout_123"

7. Bitmap 数据类型详解

Bitmap 不是一种新的数据类型，本质是 string，但提供位操作命令。适合只有两种状态的布尔型海量数据统计。

7.1 常用命令

SETBIT user:login:20220101 100 1   # 将 key 为 "user:login:20220101" 的位图（bitmap）的第 100 位设置为 1，表示 uid=100 的用户在 2022年1月1日 登录了。返回该位原来的值（之前是 0，则返回 0）
GETBIT user:login:20220101 100    # 获取该位图中第 100 位的值，返回 1（表示已登录）。若用户未登录，返回 0
BITCOUNT user:login:20220101      # 统计该位图中所有值为 1 的位的个数，即当天登录的总用户数（假设每个 uid 对应一个偏移量）。返回整数值
BITOP AND result key1 key2        # 对 key1 和 key2 对应的位图执行按位与（AND）操作，结果存入 result 键。BITOP 还支持 OR、XOR、NOT 操作。返回结果位图的字节长度
BITPOS key 1                      # 返回 key 对应位图中第一个值为 1 的位的偏移量（从 0 开始计数）。若所有位都是 0，则返回 -1。可用于快速查找最早登录的用户等场景

7.2 实战：用户签到

# uid=1000 的用户在2022年第一天签到
SETBIT sign:1000:2022 0 1
# 第365天签到
SETBIT sign:1000:2022 364 1
# 统计该用户2022年签到总天数
BITCOUNT sign:1000:2022

7.3 实战：布隆过滤器

虽然布隆过滤器在 Redis 4.0 之后有了模块（RedisBloom），但我们可以用 bitmap 自己实现一个简单的布隆过滤器，原理是通过多个哈希函数把元素映射到位图的几个位置并置 1，查询时如果所有位置都为 1 则可能存在。

8. HyperLogLog 数据类型详解

HyperLogLog 是一种基数统计算法，占用空间固定（12 KB），误差率 0.81%。适合 UV 统计这种不需要精确值的场景。

8.1 常用命令

PFADD uv:page1 user1 user2 user3      # 将元素 user1, user2, user3 添加到 HyperLogLog 结构 uv:page1 中。HyperLogLog 是一种概率数据结构，用于高效统计基数（唯一元素数量），内存占用固定（约12KB）。返回 1 表示底层估计值发生变化（通常是第一次添加新元素），返回 0 表示添加的元素可能已经存在过（不影响基数估计）
PFCOUNT uv:page1                      # 返回 uv:page1 的近似基数（唯一用户数）。由于使用概率算法，结果存在误差，默认标准误差为 0.81%（配置可调）。此处返回 3（因为有 3 个不同用户）。注意：PFCOUNT 可同时统计多个 HLL，如 PFCOUNT uv:page1 uv:page2
PFMERGE dest uv:page1 uv:page2        # 合并多个 HyperLogLog 结构（uv:page1 和 uv:page2）到一个新的 HLL（dest）中。dest 会被创建或覆盖，合并后的基数估计等于多个集合的并集基数。常用于汇总多个维度的 UV 数据，比如合并不同日期的 HLL 得到月活 UV

8.2 实战：页面 UV 统计

不用为每个用户维护 set，直接用 HLL 节省内存。

# 记录用户访问
PFADD uv:homepage userId1 userId2 ...
# 获取访问量近似值
PFCOUNT uv:homepage

用 Set 存储用户 ID 和 HLL 的内存差异：当 UV 达到亿级时，Set 消耗 GB 级别内存，HLL 仍然 12KB。

9. Geo 数据类型详解

Geo 内部基于 zset 实现，将经纬度编码成一个 score，用来计算地理位置距离、范围查询等。

9.1 常用命令

GEOADD cities 116.40 39.90 "beijing"           # 将北京（经度116.40，纬度39.90）添加到地理集合 cities 中。返回成功添加的元素数量（1）
GEOADD cities 121.47 31.23 "shanghai"          # 添加上海（经度121.47，纬度31.23）。返回成功添加的数量（1）
GEODIST cities beijing shanghai km             # 计算北京到上海的距离，单位 km。返回距离值（约1067.8 km，球面距离）。单位还可选 m（米）、mi（英里）、ft（英尺）
GEORADIUS cities 116 39 500 km WITHCOORD       # 从指定坐标（经度116，纬度39）为中心，半径500公里内查找城市，并返回坐标（WITHCOORD）。可加 WITHHASH、WITHDIST 等选项。结果可能包含北京（距离在500km内），上海超出范围
GEORADIUSBYMEMBER cities beijing 1000 km       # 以城市集合中的北京为中心，半径1000公里内查找其他城市。返回符合的城市名称（例如上海可能在此范围内，实际约1067km > 1000km，所以不返回上海；若半径设为1100km，则返回上海）
GEOHASH cities beijing                         # 返回北京的地理位置 Geohash 字符串（如 "wx4g0s8p3t"）。Geohash 是一种将二维经纬度编码为字符串的算法，可用于快速邻近查找

9.2 实战：附近的人

# 存储用户位置
GEOADD user_location 116.38 39.92 user1
# 查找5km范围内的用户
GEORADIUS user_location 116.38 39.92 5 km

可以配合移动端实时更新位置。

10. Stream 数据类型详解

Stream 是 Redis 5.0 引入的持久化消息队列，Redis 7 中功能更完善。它弥补了 List 做队列没有消费者组、没有 ACK 的缺陷。

10.1 核心概念

消息：键值对组成的条目。
消息 ID：时间戳-序号形式，如 1680000000000-0。
消费者组：组内消费者分摊消息，支持 ACK 和重试

10.2 常用命令

# 添加消息
XADD mystream * field1 value1 field2 value2   # 向 Stream (消息队列) mystream 中添加一条消息，* 表示由 Redis 自动生成消息 ID（格式：<毫秒时间戳>-<序列号>），后续字段为 field1=value1, field2=value2。返回生成的消息 ID，如 "1680000000000-0"

# 读取消息（从某个ID开始）
XREAD COUNT 2 STREAMS mystream 0              # 从 Stream mystream 中读取最多 2 条消息，从消息 ID 大于 0 的位置开始（0 表示从最早的消息开始）。返回消息列表（包含消息 ID 和字段）。常用用法：XREAD BLOCK 0 STREAMS mystream $ 阻塞等待新消息

# 创建消费者组
XGROUP CREATE mystream mygroup 0              # 在 Stream mystream 上创建消费者组 mygroup，起始偏移量为 0（表示从 Stream 的开头开始消费，也可用 $ 表示只消费新消息）。返回 OK。若组已存在可加 MKSTREAM 选项自动创建 Stream

# 消费者组读取（读取未确认的新消息）
XREADGROUP GROUP mygroup consumer1 COUNT 1 STREAMS mystream >   # 消费者 consumer1 从消费者组 mygroup 中读取 1 条尚未被任何消费者确认的消息。> 表示只读取从未投递给其他消费者的新消息（即待处理队列中的未分发消息）。返回消息及消息 ID，同时该消息会进入消费者的 Pending 状态，直到被 XACK 确认

# 确认消息
XACK mystream mygroup 1680000000000-0         # 确认消费者组 mygroup 已成功处理消息 ID 为 1680000000000-0 的消息。从 Pending 列表中移除该消息。返回成功确认的数量（1 或 0）

# 查看挂起的消息（未ACK）
XPENDING mystream mygroup                     # 查看消费者组 mygroup 中所有已投递但尚未确认的消息（即 Pending 条目）的统计信息。返回总条数、最小和最大 ID，以及各消费者的消费条目概览（消费者名及其挂起消息数）。用于监控消息处理进度

10.3 实战：可靠的消息队列

# 生产者
XADD order_stream * order_id 123 action "create"   # 向 Stream（消息队列）order_stream 中添加一条订单消息，* 表示自动生成消息 ID（格式：<毫秒时间戳>-<序列号>），消息包含两个字段：order_id=123，action="create"。返回生成的消息 ID，如 "1680000000000-0"

# 消费者组处理
XGROUP CREATE order_stream order_group 0           # 在 Stream order_stream 上创建消费者组 order_group，起始消费偏移量为 0（表示从 Stream 的最早消息开始读取）。如果 Stream 不存在，可加 MKSTREAM 选项自动创建。返回 OK

XREADGROUP GROUP order_group order_consumer1 COUNT 1 BLOCK 5000 STREAMS order_stream >   # 消费者 order_consumer1 从消费者组 order_group 中读取消息。COUNT 1 表示最多读取 1 条消息；BLOCK 5000 表示如果没有新消息，则阻塞等待最多 5000 毫秒（5 秒）；> 表示只读取从未被任何消费者读取过的**新消息**（即消费组中尚未分发的消息）。返回消息内容（包含消息 ID 和字段），同时该消息会进入该消费者的 Pending 列表（待确认状态）

# 处理成功后 ACK
XACK order_stream order_group messageId            # 消费者确认已成功处理指定消息（messageId 需替换为实际的消息 ID，如 "1680000000000-0"）。确认后，消息会从消费者组的 Pending 列表中移除，避免重复消费。返回成功确认的消息数量（1 或 0）

与 List 做队列的区别：

List 弹出后消息就没了，消费者崩溃会丢消息。
Stream 有 ACK 机制和待处理消息列表，保证消息被正确处理。

11. Spring Boot 快速连接 Redis

整合 Spring Boot 和 Redis 7，我将整理出核心配置和常见坑点。

11.1 引入依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- 连接池（推荐） -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-pool2</artifactId>
</dependency>

11.2 配置文件

spring:
  redis:
    host: 127.0.0.1
    port: 6379
    password: yourpassword
    database: 0
    lettuce:            # 默认 lettuce 客户端
      pool:
        max-active: 10
        max-idle: 5
        min-idle: 2

11.3 配置 RedisTemplate 序列化

如果不配置，默认使用 Jdk 序列化，可读性差且占用大。建议改为 JSON 序列化：

@Configuration
public class RedisConfig {
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        
        // Jackson 序列化
        Jackson2JsonRedisSerializer<Object> jacksonSerializer = 
            new Jackson2JsonRedisSerializer<>(Object.class);
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, 
            ObjectMapper.DefaultTyping.NON_FINAL);
        jacksonSerializer.setObjectMapper(om);
        
        // String 序列化
        StringRedisSerializer stringSerializer = new StringRedisSerializer();
        
        template.setKeySerializer(stringSerializer);
        template.setHashKeySerializer(stringSerializer);
        template.setValueSerializer(jacksonSerializer);
        template.setHashValueSerializer(jacksonSerializer);
        template.afterPropertiesSet();
        return template;
    }
}

11.4 使用示例

@RestController
public class RedisController {
    @Autowired
    private RedisTemplate<String, Object> redisTemplate;
    
    @GetMapping("/set")
    public String setValue() {
        redisTemplate.opsForValue().set("test_key", "hello redis7");
        return "ok";
    }
    
    @GetMapping("/zset")
    public void zsetTest() {
        redisTemplate.opsForZSet().add("rank", "user1", 100);
        Set<Object> top = redisTemplate.opsForZSet().reverseRange("rank", 0, 2);
        System.out.println(top);
    }
}