Redis 常用数据结构操作指令与场景应用详解

临时有效数据：手机验证码、登录临时 token。

SETEX sms:138xxxx1234 300 "123456" # 5 分钟后自动过期

计数器系统（累加器）：文章阅读量、视频播放量、接口调用次数。

INCR article:read:1001 # 每次访问自增 1

单值数据缓存：缓存商品详情、用户基本信息、首页热点数据。如果数据不常改动，可以设置多个属性（json 格式）

SET role:10002 '{["name"]:"dcf",["sex"]:"male",["age"]:3}'

List

结构说明

有序、可重复的元素集合，基于双向链表实现，两端操作（头部 / 尾部）性能极高，中间插入 / 删除性能较差，适合存储有序的序列数据。

特点：
双向链表实现，列表首尾操作（删除和增加）时间复杂度 O(1)；查找中间元素时间复杂度为 O(n)；

存储结构：
列表中数据是否压缩的依据：元素长度小于 48，不压缩；元素压缩前后长度差不超过 8，不压缩；

核心操作指令

典型应用场景

1. 异步消息队列：操作与队列一样，但是在不同系统间；生成者和消费者；
2. 分页查询（旧数据）：对于无需复杂筛选的历史数据（如用户历史订单列表），可通过 LRANGE 实现简单分页（不适合高频更新、大数据量的分页场景）。

最新消息 / 动态列表：朋友圈动态、文章评论列表、系统通知列表。

RPUSH moments:1001 "动态 1" "动态 2" ltrim moments:1001 0 99 # 限制列表长度避免内存溢出 LRANGE moments:1001 0 9 # 获取最新 10 条动态

阻塞队列（blocking queue）：

LPUSH + BRPOP # 或者 RPUSH + BLPOP

队列（先进先出 FIFO）：

LPUSH + RPOP # 或者 RPUSH + LPOP

栈（先进后出 FILO）：

LPUSH + LPOP # 或者 RPUSH + RPOP

Hash

结构说明

用于存储键值对集合（类似 Java 中的 Map、Python 中的 dict），适合存储单个对象的多个属性，可单独操作对象的某个字段，无需修改整个对象。

特点：
散列表，在很多高级语言当中包含这种数据结构；c++ unordered_map 通过 key 快速索引 value；

**存储结构：**节点数量大于 512（hash-max-ziplist-entries）或所有字符串长度大于 64（hash-max-ziplist-value），则使用 dict 实现；节点数量小于等于 512 且有一个字符串长度小于 64，则使用 ziplist 实现

核心操作指令

典型应用场景

对比 string 存储 json 格式，hash 存储的对象使用于频繁更改属性的场景

hmset user name dcf age 18 sex male # 与 string 比较 set string '{["name"]:"mark",["sex"]:"male",["age"]:18}' # 修改 # hash：hset user age 19 # string:get user # 将得到的字符串调用 json 解密，取出字段，修改 age 值 # 再调用 json 加密 set user '{["name"]:"dcf",["sex"]:"male",["age"]:19}'

对象数据存储：存储用户信息、商品属性、购物车功能、配置信息存储

# 对象数据存储：存储用户信息、商品属性 HSET user:1001 id 1001 name "张三" age 25 phone "138xxxx1234" HSET user:1001 age 26 # 可单独更新，无需修改整个用户对象）。 # 购物车功能：以「用户 ID」为 Redis 键，「商品 ID」为 Hash 字段，「商品数量」为 Hash 值 HSET cart:1001 goods:1001 2 # 表示用户 1001 购物车中有 2 件商品 1001 HINCRBY cart:1001 goods:1001 1 # 实现商品数量加 1）。 # 配置信息存储：存储系统配置、应用参数 HSET config:app port 8080 timeout 30 log_level "info" # 方便单独查询和修改某个配置项）。

Set

结构说明

无序、不可重复的元素集合，基于哈希表实现，支持高效的去重和集合运算（交集、并集、差集），单个元素最大支持 512MB。

**特点：**集合；用来存储唯一性字段，不要求有序；存储不需要有序，操作（交并差集的时候排序）

**存储结构：**元素都为整数且节点数量小于等于 512（set-max-intset-entries），则使用整数数组存储；元素当中有一个不是整数或者节点数量大于 512，则使用字典存储

核心操作指令

典型应用场景

随机抽奖系统：幸运大转盘、抽奖活动。

SADD lottery:2026 1001 1002 ...，SPOP lottery:2026 3 # 随机抽取 3 名中奖用户

社交关系计算：共同好友、推荐好友、共同兴趣标签。

SINTER user:friends:1001 user:friends:1002 # 获取用户 1001 和 1002 的共同好友 SUNION user:friends:1001 user:friends:1002 # 获取用户的所有好友列表。 SDIFF user:friends:1001 user:friends:1002 # 用户 1002 可能想认识的人

数据去重：用户点赞列表、文章收藏列表、签到记录去重、黑白名单系统

SADD article:like:1001 1001 1002 # 避免同一用户重复点赞 SISMEMBER article:like:1001 1002 # 判断用户是否已点赞 SADD blacklist:user 1003 # 接口请求时通过 SISMEMBER 判断用户是否在黑名单中）。

ZSet

结构说明

有序、不可重复的元素集合，每个元素关联一个浮点型分数（score），Redis 按 score 从小到大排序（可反向排序），支持按 score 范围和排名查询，兼顾了 Set 的去重特性和 List 的有序特性。

特点：
有序集合；用来实现排行榜；它是一个有序唯一；

**存储结构：**节点数量大于 128 或者有一个字符串长度大于 64，则使用跳表（skiplist）；节点数量小于等于 128（zset-max-ziplist-entries）且所有字符串长度小于等于 64（zset-max-ziplist-value），则使用 ziplist 存储；

**复杂度：**数据少的时候，节省空间；O(n) 数量多的时候，访问性能；O(1) or O(log_{2}{n})

核心操作指令

典型应用场景

时间窗口限流： 系统限定用户的某个行为在指定的时间范围内（动态）只能发生 N 次；

-- 指定用户 user_id 的某个行为 action 在特定时间内 period 只允许发生该行为做大次数 max_count
local function is_action_allowed(red, userid, action, period, max_count)
    local key = tab_concat({"hist", userid, action}, ":")
    local now = redis.time()[1]
    red:init_pipeline()
    -- 记录行为
    red:zadd(key, now, now)
    -- 移除时间窗口之前的行为记录，剩下的都是时间窗口内的记录
    red:zremrangebyscore(key, 0, now - period *100)
    -- 获取时间窗口内的行为数量
    red:zcard(key)
    -- 设置过期时间，避免冷用户持续占用内存 时间窗口的长度 +1 秒
    red:expire(key, period + 1)
    local res = red:commit_pipeline()
    return res[3] <= max_count
end
-- 维护一次时间窗口，将窗口外的记录全部清理掉，只保留窗口内的记录；
-- 缺点：记录了所有时间窗口内的数据，如果这个量很大，不适合做这样的限流；漏斗限流
-- 注意：如果用 key + expire 操作也能实现，但是实现的是熔断限流，这里是时间窗口限流的功能；

分布式定时器： 生产者将定时任务 hash 到不同的 redis 实体中，为每一个 redis 实体分配一个 dispatcher 进程，用来定时获取 redis 中超时事件并发布到不同的消费者中；

延时队列：将任务的执行时间戳作为 score，消费者定期通过 ZRANGEBYSCORE 获取当前时间之前的任务执行。

ZADD delay:queue 1735660800 task:1001 # 表示任务 1001 在 2025-01-01 00:00 执行）。

各类排行榜系统：销量榜、积分榜、热度榜、游戏天梯榜

ZADD goods:sales 100 goods:1001 200 goods:1002 ZREVRANGE goods:sales 0 9 WITHSCORES # 获取销量前 10 商品； ZINCRBY goods:sales 1 goods:1001 # 实现销量加 1

常用扩展数据结构

位图（Bitmap）

结构说明

并非独立数据结构，基于 String 实现，按「位」存储数据，每个位只能是 0 或 1，极大节省内存空间（1 个字节 = 8 位，可存储 8 个状态）。

核心操作指令

典型应用场景

• 批量状态判断（如判断用户是否领取过某类优惠券，1 表示已领取，0 表示未领取）。
• 活跃度统计

# 查询用户 1001 是否当月有活跃 BITOP OR user:active:202601 user:active:20260101 user:active:20260102 # 合并所有日期 GETBIT user:active:202601 1001 # 1=有活跃，0=无活跃 # 2. 查询用户 1001 是否当月满勤 BITOP AND user:full:202601 user:active:20260101 user:active:20260102 # 合并所有日期 GETBIT user:full:202601 1001 # 1=满勤，0=有缺勤

• 用户签到系统

SETBIT user:sign:1001 0 1 # 表示用户 1001 第 1 天签到 BITCOUNT user:sign:1001 # 统计当月签到天数

地理空间（Geo）

结构说明

并非独立数据结构，基于 ZSet 实现，用于存储经纬度坐标，支持距离计算、附近地点查询等地理空间操作。

核心操作指令

简略：

详尽：

补充说明： GEORADIUS 是旧版指令（Redis <6.2），GEOSEARCH 是新版替代指令（更推荐）；单位支持 m（米）、km（公里）、mi（英里）、ft（英尺）；WITHDIST 会返回距离数值，ASC 表示按距离由近到远排序（DESC 是由远到近）。

典型应用场景

配送范围判断（如判断用户是否在商家的配送范围内，通过 GEODIST 计算距离是否小于配送阈值）。

# 添加外卖商家到 key `store:location`（经度 纬度 商家 ID） GEOADD store:location 116.3956 39.9299 "商家 1" # 北京王府井附近 GEOADD store:location 116.4100 39.9100 "商家 2" # 北京东单附近 GEOADD store:location 116.4300 39.9000 "商家 3" # 北京国贸附近（距离中心>3 公里） # 假设'商家 1 的配送范围是 2 公里'，计算用户（116.40 39.90）到商家 1 的距离， # 判断是否≤2 公里： # 指令：GEODIST key 成员 1 成员 2 单位 GEODIST store:location "商家 1" 116.40 39.90 km

地理位置排序（如旅游平台按距离远近排序景点、酒店）。

# 添加旅游景点到 key `scenic:location` GEOADD scenic:location 116.3972 39.9165 "故宫" # 北京故宫 GEOADD scenic:location 116.4038 39.9240 "天安门" # 北京天安门 GEOADD scenic:location 116.4810 39.9128 "颐和园" # 北京颐和园（距离中心较远） # 以'用户位置（116.40 39.90）'为中心，查 5 公里内的景点，按距离由近到远排序 # Redis 6.2+推荐用 GEOSEARCH（更灵活）：按成员为中心查询 GEOSEARCH scenic:location FROMLONLAT 116.40 39.90 BYRADIUS 5 km WITHDIST ASC

附近的人 / 门店

# 添加外卖商家到 key `store:location`（经度 纬度 商家 ID） GEOADD store:location 116.3956 39.9299 "商家 1" # 北京王府井附近 GEOADD store:location 116.4100 39.9100 "商家 2" # 北京东单附近 GEOADD store:location 116.4300 39.9000 "商家 3" # 北京国贸附近（距离中心>3 公里） # 以'用户位置（116.40 39.90，北京建国门附近）'为中心， # 查 3 公里内的商家，显示距离 + 按距离由近到远排序： GEORADIUS store:location 116.40 39.90 3 km WITHDIST ASC

查找 Key

Redis 中用于查找 / 列出 key 的核心命令主要是 KEYS 和 SCAN，其中 SCAN 是更推荐在生产环境使用的方式。下面我会详细介绍这些命令的用法、区别和最佳实践。

KEYS 命令（简单但不推荐生产使用）

KEYS 是最基础的查找 key 的命令，支持通配符匹配，但会阻塞 Redis 主线程，在数据量大时可能导致服务卡顿，因此仅建议在开发 / 调试环境使用。

语法：

KEYS pattern 

通配符规则：

• *：匹配任意数量的任意字符（包括 0 个）
• ?：匹配单个任意字符
• []：匹配括号内的单个字符（如 [abc] 匹配 a、b 或 c）
• \：转义特殊字符

示例：

# 列出所有 key KEYS * # 列出以 "user:" 开头的所有 key KEYS user:* # 列出以 "order" 结尾的所有 key KEYS *order # 列出第二个字符是 "a" 的 key（如 "ka1", "ba2"） KEYS ?a* # 列出以 "prod" 开头且第三个字符是 1 或 2 的 key（如 "prod1", "prod2"） KEYS prod[12]* 

SCAN 命令（生产环境推荐）

SCAN 是迭代式查找 key 的命令，非阻塞（分批返回结果），适合在生产环境遍历大量 key，避免阻塞 Redis。

语法：

SCAN cursor [MATCH pattern] [COUNT count] [TYPE type] 

参数说明：

• cursor：游标，初始值为 0，每次返回结果会包含下一个游标，直到返回 0 表示遍历完成
• MATCH pattern：可选，通配符匹配规则（同 KEYS）
• COUNT count：可选，指定每次迭代返回的 key 数量（非精确值，默认 10）
• TYPE type：可选，按数据类型过滤（如 string、hash、list、set、zset）

示例：

# 初始迭代（游标 0），匹配所有 key，每次返回约 20 个 SCAN 0 MATCH * COUNT 20 # 迭代以 "user:" 开头的 key，按类型过滤为 hash SCAN 0 MATCH user:* TYPE hash # 假设第一次返回游标 50，继续迭代 SCAN 50 MATCH user:* TYPE hash 

返回结果示例：

1) "50" # 下一个游标 2) 1) "user:1001" 2) "user:1002" 3) "user:1003" 

辅助命令

TYPE：查看指定 key 的数据类型（配合查找结果使用）

TYPE user:1001 

EXISTS：检查指定 key 是否存在（可批量检查）

EXISTS key1 key2 # 返回存在的 key 数量 

DBSIZE：快速获取当前数据库的 key 总数（无需遍历，性能极高）

DBSIZE 

使用建议

• 开发 / 调试环境：可临时使用 KEYS，操作简单。
• 生产环境：必须使用 SCAN，避免阻塞主线程；如果需要统计 key 总数，优先用 DBSIZE 而非 KEYS *。
• 通配符优化：尽量缩小匹配范围（如 user:* 而非 *），减少迭代次数。
• 集群环境：KEYS/SCAN 仅作用于当前连接的节点，如需遍历整个集群，需逐个节点执行。

总结

• Redis 查找 key 的核心命令是 KEYS（简单但阻塞）和 SCAN（非阻塞，生产推荐），均支持通配符匹配。
• SCAN 通过游标分批迭代，搭配 MATCH/TYPE/COUNT 参数可精准过滤 key，避免服务卡顿。
• 辅助命令 DBSIZE/EXISTS/TYPE 可配合查找操作，提升效率和准确性。

细节补充

key 的设计

单一功能一个 key：取有意义的就行相同功能多个 key：以" : "作为分割
（tips：为什么使用冒号，业内常用，界面客户端的工具也常用:来表示子目录）

怎么删除 key

del key：删除该键值对当 value 为空的时候，会自动移除该 key

怎么创建 key

添加的时候，如果不存在 key，那么 redis 会自动创建

业务中常用组合数据结构

hash 的 value 存放 list/set/zset 的 keyhash + listhash + sethash + zet