Redis 7.2 数据结构命令全解析：用法、技巧与实战案例

Redis 作为高性能键值存储系统，数据结构是其核心竞争力。不同数据结构适配不同业务场景，高效利用可大幅提升系统性能与开发效率。本文基于思维导图，对 Redis 核心数据结构（字符串、列表、集合、有序集合、哈希、位图、HyperLogLog、地理空间、流等）的命令、用法、技巧及架构实践展开详细分析。

一、字符串（String）：最基础的全能型结构

字符串是 Redis 最基础的数据结构，可存储字符串、数字、二进制数据（如图片、序列化对象），最大容量为 512MB。

1. 基础操作命令

• SET 系列：
• SET key value [EX seconds | PX milliseconds | KEEPTTL]：设置键值对，支持过期时间（秒/毫秒）或保留原有 TTL。案例：SET user:name "Alice" EX 3600（缓存用户姓名，1 小时后过期）。
• SETNX key value：仅当键不存在时设置，常用于分布式锁（避免重复创建锁）。案例：SETNX lock:order 1（尝试获取订单锁，锁不存在则成功，存在则失败）。
• SETEX key seconds value：等价于 SET + EX，简化“设置 + 秒级过期”操作。
• PSETEX key milliseconds value：毫秒级过期，更精细控制时效性。
• GET 系列：
• GET key：简单查询值。
• GETSET key newvalue：原子性先获取旧值、再设新值，适合计数器更新。案例：GETSET page:views 100（获取当前页面访问量，再重置为 100）。
• GETDEL key：获取值后删除键，原子性操作适合“一次性数据”（如验证码）。
• 其他基础操作：
• STRLEN key：获取字符串长度，如 STRLEN user:name。
• APPEND key value：追加字符串到已有值后，键不存在则等价于 SET。

2. 数值原子操作（String 存数字时专用）

Redis 字符串支持原子增减，适合计数器场景。

• INCR/INCRBY/INCRBYFLOAT：INCR key：值自增 1，如 INCR article:100:views（文章阅读数 +1）。INCRBY key increment：指定步长自增，如 INCRBY user:points 10（用户积分 +10）。INCRBYFLOAT key increment：浮点型自增，如 INCRBYFLOAT price 0.5（价格 +0.5）。
• DECR/DECRBY：自减操作，逻辑与 INCR 系列一致。

3. 范围与位操作

• 子串操作：
• GETRANGE key start end：获取子串，如 GETRANGE user:desc 0 10（取描述前 11 个字符）。
• SETRANGE key offset value：从偏移量开始覆盖部分字符串，如 SETRANGE user:name 5 "Bob"（第 5 个字符起替换为 Bob）。
• 位操作（String 可视为“位图”的底层载体）：
• SETBIT key offset value：设置指定位的值（0/1），适合布尔型批量数据（如签到、在线状态）。案例：SETBIT user:sign:202509 1 1（9 月 2 日签到，位设为 1）。
• GETBIT key offset：获取指定位的值。
• BITCOUNT key [start end]：统计位为 1 的数量，如 BITCOUNT user:sign:202509（统计 9 月签到天数）。
• BITOP operation destkey key [key ...]：位运算（AND/OR/XOR/NOT），用于合并多个位图。

技巧与最佳实践

• 缓存热点数据：将数据库高频查询数据缓存为 String，配合过期时间实现“缓存 + 数据库”双层存储。
• 分布式锁优化：SETNX + EX 实现锁的“自动过期”，避免死锁；结合 Lua 脚本（if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end）实现“安全释放锁”（防止误删其他客户端的锁）。
• 计数器场景：INCR 系列原子性保证并发计数准确，如文章阅读量、接口请求数、点赞数等。

二、列表（List）：有序链表，适配队列/栈场景

列表是有序的字符串列表，基于双向链表（小数据量用 ziplist 优化存储）实现，支持头尾高效操作，适合消息队列、最新列表等场景。

1. 基础增删查

• 头尾操作：
• LPUSH/RPUSH key value [value ...]：从左/右插入一个或多个元素，如 LPUSH news:feed "news1"（左侧插入新闻）。
• LPOP/RPOP key：从左/右弹出元素（删除并返回），如 LPOP news:feed（获取并删除最左新闻）。
• 范围与索引：
• LRANGE key start stop：获取指定范围元素，LRANGE news:feed 0 -1（-1 表示最后一个，即获取所有新闻）。
• LINDEX key index：获取指定索引元素，如 LINDEX news:feed 2（取第 3 个新闻）。
• LLEN key：获取列表长度，如 LLEN news:feed。

2. 阻塞操作（消息队列核心能力）

列表支持阻塞式弹出，适合消费者“等待消息”的场景（避免轮询浪费资源）。

• BLPOP key [key ...] timeout：阻塞式左弹出，多键时按顺序检查，超时返回 nil。案例：BLPOP msg:queue 0（永久阻塞，直到有消息入队）。
• BRPOP key [key ...] timeout：阻塞式右弹出，逻辑与 BLPOP 一致。
• BRPOPLPUSH source destination timeout：原子性从 source 右弹出、左推入 destination，同时阻塞等待，适合“安全的消息转移”（避免消息丢失）。

3. 高级操作

• LINSERT key BEFORE|AFTER pivot value：在指定元素前/后插入，如 LINSERT news:feed AFTER "news1" "news1.5"。
• LREM key count value：删除指定数量的元素（count>0 从左删；count<0 从右删；count=0 删所有）。
• LTRIM key start stop：保留指定范围，删除之外的元素，如 LTRIM news:feed 0 9（只保留前 10 条新闻，防止内存溢出）。
• LSET key index value：设置指定索引的值，如 LSET news:feed 2 "news3"。

案例与架构

• 简单消息队列：生产者用 LPUSH 发消息，消费者用 BRPOP 消费。适合低并发、对可靠性要求不高的场景；若需“消费确认（ACK）”，可结合 BRPOPLPUSH + 确认逻辑（处理成功后删除 destination 中的消息）。
• 最新评论列表：用 LPUSH 添加新评论，LRANGE 0 9 展示最新 10 条。
• 分页加载：通过 LRANGE 按页获取列表片段（如 LRANGE list:data 0 9 取第 1 页，LRANGE list:data 10 19 取第 2 页），避免一次性拉取大量数据。

技巧

• 队列/栈模式切换：列表作为队列（FIFO）：LPUSH + RPOP；作为栈（LIFO）：LPUSH + LPOP。
• 长度控制：利用 LTRIM 维持列表长度（如只保留最新 100 条消息），减少内存占用。

三、集合（Set）：无序唯一，适配去重与集合运算

集合是无序、唯一的字符串集合，基于哈希表实现，支持交集、并集、差集等操作，适合标签、去重、共同好友等场景。

1. 基础增删查

• SADD key member [member ...]：添加一个或多个元素，如 SADD user:tags "java" "redis"（给用户打标签）。
• SREM key member [member ...]：删除元素，如 SREM user:tags "java"。
• SMEMBERS key：获取所有元素，如 SMEMBERS user:tags。
• SISMEMBER key member：判断元素是否在集合中，返回 1（是）或 0（否），如 SISMEMBER user:tags "redis"。
• SCARD key：获取集合大小，如 SCARD user:tags。

2. 集合运算（交、并、差）

Redis 支持高效的集合运算，是其核心优势之一。

• 交集（SINTER）：
• SINTER key [key ...]：返回多个集合的交集，如 SINTER user:1:tags user:2:tags（用户 1 和用户 2 的共同标签）。
• SINTERSTORE destkey key [key ...]：交集结果存储到新键，如 SINTERSTORE user:common:tags user:1:tags user:2:tags。
• 并集（SUNION）：
• SUNION key [key ...]：合并多个集合（自动去重）。
• SUNIONSTORE destkey key [key ...]：并集结果存储。
• 差集（SDIFF）：
• SDIFF key [key ...]：返回“第一个集合有、其他集合没有”的元素，如 SDIFF user:1:tags user:2:tags（用户 1 独有标签）。
• SDIFFSTORE destkey key [key ...]：差集结果存储。

3. 随机操作

• SRANDMEMBER key [count]：随机获取 count 个元素（count>0 不重复；count<0 可能重复），如 SRANDMEMBER user:tags 2（随机取 2 个标签）。
• SPOP key [count]：随机弹出 count 个元素（删除并返回），如 SPOP user:tags 1。

案例

• 用户标签系统：每个用户的标签存在 Set 中，通过 SINTER 找共同标签，SUNION 合并标签。
• 抽奖系统：候选用户存入 Set，用 SPOP 或 SRANDMEMBER 随机选中奖者。
• 在线用户统计：用户上线时 SADD online:users uid，下线时 SREM，SCARD 统计在线人数。

技巧

• 去重：将需去重的数据（如日志、请求 ID）插入 Set，自动完成去重。
• 协同过滤推荐：基于用户标签的交集/并集，实现“相似用户”“推荐标签”等功能。

四、有序集合（Sorted Set/ZSet）：带分排序，适配排行榜/延迟任务

有序集合是带分数（score）的唯一字符串集合，按分数排序，底层用跳表（Skip List）+ 哈希表实现，适合排行榜、延迟任务、带权重的元素存储等场景。

1. 基础增删查

• ZADD key [NX|XX] [CH] [INCR] score member [score member ...]：添加元素及分数，支持原子增量、存在性判断。
• 案例：ZADD rank:game 100 "user1" 90 "user2"（游戏排行榜，用户分数为积分）。
• NX：仅当 member 不存在时添加；XX：仅当存在时更新；INCR：对 score 做增量（如 ZADD rank:game INCR 10 "user2" 给 user2 分数 +10）。
• ZREM key member [member ...]：删除元素，如 ZREM rank:game "user1"。
• ZSCORE key member：获取元素的分数，如 ZSCORE rank:game "user2"。
• ZRANK/ZREVRANK key member：获取元素的升序/降序排名（从 0 开始），如 ZRANK rank:game "user2"（升序排名，分数 90），ZREVRANK 为降序。
• ZCARD key：获取集合大小，如 ZCARD rank:game。
• ZCOUNT key min max：统计分数在 [min, max] 之间的元素数量，如 ZCOUNT rank:game 80 100。

2. 范围操作（按排名/分数）

有序集合的核心价值是按序获取范围元素。

• 按排名范围：
• ZRANGE/ZREVRANGE key start stop [WITHSCORES]：按升序/降序取排名范围内的元素，WITHSCORES 表示返回分数。案例：ZRANGE rank:game 0 2 WITHSCORES（取前三名及分数）。
• 按分数范围：
• ZRANGEBYSCORE/ZREVRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]：按分数范围取元素，支持分页（LIMIT）。案例：ZRANGEBYSCORE rank:game 80 100 WITHSCORES（取分数 80-100 的用户及分数）。
• 范围删除：
• ZREMRANGEBYRANK/ZREMRANGEBYSCORE key start stop：按排名/分数范围删除元素，如 ZREMRANGEBYRANK rank:game 0 0（删除第一名）。

3. 分数原子操作

• ZINCRBY key increment member：增加元素的分数，如 ZINCRBY rank:game 10 "user2"（用户 2 分数 +10）。

案例

• 游戏排行榜：用 ZSet 存储用户 ID 和分数，ZRANGE 取 TopN，ZINCRBY 实时更新分数（如用户完成任务后加分）。
• 延迟任务队列：分数设为任务执行时间戳，消费者用 ZRANGEBYSCORE 获取“当前时间 ≤ 分数”的任务，处理后删除。
• 带权重的消息队列：不同优先级的消息用分数表示权重，消费者优先处理高分消息（如 ZRANGEBYSCORE msg:queue +inf -inf REV 降序取消息）。

技巧

• 时间戳作为分数：结合 ZRANGEBYSCORE 实现“定时任务”，比数据库轮询更高效（Redis 单线程事件循环处理，延迟低）。
• 实时排名更新：利用 ZINCRBY 实现分数实时变化（如直播礼物打赏后，主播排名即时更新）。

五、哈希（Hash）：对象存储，适配部分更新

哈希是键值对的集合（field-value），适合存储“对象类数据”（如用户信息、商品详情），每个 Hash 可存储 (2^{32}-1) 个字段，底层用 ziplist（小数据）或哈希表（大数据）优化。

1. 基础增删查

• HSET/HSETNX key field value [field value ...]：设置字段值，HSETNX 仅当字段不存在时设置。
• 案例：HSET user:1 name "Alice" age 20（存储用户 1 的姓名和年龄）。
• HGET/HMGET key field [field ...]：获取字段值，HMGET 批量获取。
• 案例：HGET user:1 name（取姓名）；HMGET user:1 name age（取姓名和年龄）。
• HGETALL key：获取所有字段和值，如 HGETALL user:1（返回用户所有信息）。
• HDEL key field [field ...]：删除字段，如 HDEL user:1 age（删除年龄字段）。
• HEXISTS key field：判断字段是否存在，返回 1 或 0。
• HLEN key：获取字段数量，如 HLEN user:1。
• HKEYS/HVALS key：获取所有字段名/值，如 HKEYS user:1（返回 name、age 等字段）。

2. 数值原子操作

• HINCRBY/HINCRBYFLOAT key field increment：字段值自增，如 HINCRBY user:1 points 10（用户积分 +10）；HINCRBYFLOAT user:1 balance 0.5（余额 +0.5）。

案例

• 用户信息存储：将用户属性（姓名、年龄、积分等）存入 Hash，避免用单个 String 存储大对象（节省内存，且支持部分更新）。
• 商品详情缓存：商品 ID 为键，字段为 price、stock、name 等，如 HSET product:100 price 99.9 stock 100 name "iPhone"。
• 购物车：用户购物车存为 Hash，商品 ID 为 field，数量为 value，如 HINCRBY cart:user1 100 1（商品 100 数量 +1）。

技巧

• 部分更新：用 HSET 仅更新对象的某个字段，而非重新设置整个 String，减少网络传输和内存开销（如用户仅修改姓名时，只需 HSET user:1 name "Bob"）。
• 内存优化：当 Hash 的字段和值都较小时，Redis 会用 ziplist 存储（更紧凑），适合存储对象类数据。

六、位图（Bitmap）：按位存储，极致节省内存

位图是 String 的位操作抽象，将 String 的每一位视为“标志位”，适合存储布尔型数据（如签到、在线状态、权限位），1 字节 = 8 位，极大节省内存。

核心命令

• SETBIT key offset value：设置指定位（0/1），如 SETBIT user:sign:202509 0 1（9 月 1 日签到）。
• GETBIT key offset：获取指定位的值，如 GETBIT user:sign:202509 0（查询 9 月 1 日是否签到）。
• BITCOUNT key [start end]：统计位为 1 的数量，如 BITCOUNT user:sign:202509（统计 9 月签到天数）。
• BITOP operation destkey key [key ...]：位运算（AND/OR/XOR/NOT），如 BITOP AND dest user:sign:202508 user:sign:202509（获取两个月都签到的日期）。
• BITFIELD key [GET type offset] [SET type offset value] [INCRBY type offset increment]：复杂位操作，支持批量获取、设置、增减位段。案例：BITFIELD user:flags GET u4 0（获取从第 0 位开始的 4 位无符号整数）；BITFIELD user:flags INCRBY u4 0 1（给这 4 位加 1）。

案例

• 用户签到系统：每天对应位图的一位（1 = 签到，0 = 未签），BITCOUNT 统计月签到次数，BITOP 统计“连续签到”（如与前一天的位图做 AND 运算）。
• 在线用户实时统计：每个用户 ID 对应一位，在线设为 1，离线设为 0，BITCOUNT 统计当前在线人数。
• 权限系统：用位表示不同权限（如第 0 位 = 读，第 1 位 = 写），通过 BITFIELD 判断和修改权限。

技巧

• 时间维度位图：按天/月生成位图键（如 user:sign:202509），方便按时间范围统计。
• 位段计数器：结合 BITFIELD 的 INCRBY 实现“连续签到天数”等计数器（如用 4 位存储连续天数，自动递增）。

七、HyperLogLog：概率型基数统计，极致空间效率

HyperLogLog 是概率型数据结构，用于近似统计基数（不重复元素数量），仅需约 12KB 内存，但有 0.81% 左右的误差，适合 UV 统计、独立访客等场景。

核心命令

• PFADD key element [element ...]：添加元素到 HyperLogLog，如 PFADD uv:20250919 "user1" "user2"（记录当天访问用户）。
• PFCOUNT key [key ...]：统计基数，如 PFCOUNT uv:20250919（当天 UV）；多键时近似合并统计基数。
• PFMERGE destkey sourcekey [sourcekey ...]：合并多个 HyperLogLog 到新键，如 PFMERGE uv:202509 uv:20250917 uv:20250918 uv:20250919（合并 9 月 17-19 日的 UV）。

案例

• 网站 UV 统计：每天一个 HyperLogLog 键记录访问用户，PFCOUNT 得当天 UV，PFMERGE 得周/月 UV。
• 商品浏览独立用户数：每个商品页一个 HyperLogLog，统计“有多少不同用户浏览过”。

技巧

• 误差容忍场景：当需统计百万级以上基数，且允许约 1% 误差时，优先用 HyperLogLog（比 Set 节省大量内存：Set 存 100 万用户需约几十 MB，HyperLogLog 仅需 12KB）。
• 避免精确计数场景：HyperLogLog 不适合订单数、库存数等必须精确的场景，适合 UV、独立 IP、独立设备等“基数统计”场景。

八、地理空间（Geospatial）：LBS 服务，适配位置相关场景

地理空间数据结构用于存储地理位置信息，支持距离计算、范围查询等，基于 GeoHash 实现，适合 LBS（Location Based Service）场景（如附近商家、物流轨迹）。

核心命令

• GEOADD key longitude latitude member [longitude latitude member ...]：添加地理位置，如 GEOADD shops 116.397428 39.90923 "shop1" 116.417428 39.91923 "shop2"（添加两家店铺经纬度）。
• GEOPOS key member [member ...]：获取地理位置的经纬度，如 GEOPOS shops shop1。
• GEODIST key member1 member2 [m|km|ft|mi]：计算两个位置的距离，单位可选（米、千米等），如 GEODIST shops shop1 shop2 km（计算两家店的千米距离）。
• GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]：根据经纬度和半径查询范围内的位置，如 GEORADIUS shops 116.407428 39.91923 10 km WITH DIST（查询 10 公里内的店铺及距离）。
• GEORADIUSBYMEMBER key member radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]：根据已有成员的位置和半径查询，如 GEORADIUSBYMEMBER shops shop1 5 km（查询 shop1 周围 5 公里的店铺）。
• GEOHASH key member [member ...]：获取位置的 GeoHash 字符串（用于底层分析或与其他 GeoHash 系统交互）。

案例

• 附近的商家：用户打开 APP 后，获取其位置，用 GEORADIUS 查询附近商家并按距离排序。
• 物流轨迹：存储快递员的位置，查询“某个区域内的快递员”以分配订单。
• 地理围栏：判断用户是否进入预设地理范围（如商场、园区）。

技巧

• 底层是 ZSet：Redis 地理空间的底层是 ZSet（分数为 GeoHash 编码后的值），因此可对 Geo 键用 ZSet 命令（如 ZRANGE），但不建议直接操作（避免破坏结构）。
• 范围查询的 COUNT 参数：限制返回数量（如 COUNT 10），提升大数据量下的查询性能。

九、流（Stream）：可靠消息队列，适配分布式场景

Stream 是 Redis 5.0+ 引入的持久化消息队列，支持多生产者、多消费者、消息持久化、ACK 确认等，适合“可靠消息队列”场景（如订单回调、事件流处理）。

核心命令

• 生产消息：
• XADD key ID field value [field value ...]：添加消息到 Stream，ID 格式为 时间戳-序列号（* 表示自动生成），如 XADD msg:queue * type "order" content "new order"（添加订单消息）。
• 消费消息（简单模式）：
• XLEN key：获取 Stream 长度，如 XLEN msg:queue。
• XRANGE key start end [COUNT count]：按 ID 范围获取消息，- 表示最小 ID，+ 表示最大 ID，如 XRANGE msg:queue - + COUNT 10（获取最新 10 条消息）。
• XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...]：读取消息，支持阻塞和批量，如 XREAD BLOCK 0 STREAMS msg:queue $（从最新消息后阻塞，等待新消息；$ 表示最后一个 ID）。
• 消费组（可靠模式，核心）：
• XGROUP CREATE key groupname ID [MKSTREAM]：创建消费组，ID 为消费起始位置（0 表示从 Stream 开头，$ 表示从最新消息），MKSTREAM 表示 Stream 不存在时自动创建。案例：XGROUP CREATE msg:queue group1 0（从 Stream 开头消费）。
• XREADGROUP GROUP groupname consumername [COUNT count] [BLOCK milliseconds] [NOACK] STREAMS key [key ...] ID [ID ...]：消费组内读取消息，> 表示“获取未被消费的消息”（新消费者专用）。案例：XREADGROUP GROUP group1 consumer1 BLOCK 0 STREAMS msg:queue >（永久阻塞，等待 group1 未消费的消息）。
• XACK key groupname ID [ID ...]：确认消息已处理，如 XACK msg:queue group1 1695123456-0（确认 ID 为 1695123456-0 的消息已处理）。
• XPENDING key groupname [start end] [count] [consumer]：查询**待处理（未 ACK）**的消息，如 XPENDING msg:queue group1（查看 group1 的未确认消息）。
• XCLAIM key groupname consumername min-idle-time ID [ID ...] [IDLE idle-time] [TIME time] [RETRYCOUNT count] [FORCE] [JUSTID]：转移消息所有权，用于故障转移（如消费者宕机，其他消费者接管未 ACK 的消息）。

案例与架构

• 可靠消息队列：生产者 XADD 消息到 Stream，消费组 XREADGROUP 消费，处理后 XACK 确认。若消费者宕机，XPENDING 可发现未确认消息，用 XCLAIM 转移给其他消费者，保证“至少一次消费”。
• 事件流处理：将系统事件（如用户注册、订单支付）写入 Stream，多个消费者分别处理（如统计服务、通知服务、审计服务同时消费）。
• 分布式日志：各节点将日志写入 Stream，集中消费处理（如聚合、分析）。

技巧

• 消费组的 > ID：新消费者用 > 从“最新未消费消息”开始，避免重复消费历史消息。
• ACK 与故障转移：必须显式 XACK 确认消息，结合 XPENDING 和 XCLAIM 实现“可靠消费”（防止消息丢失或重复消费）。
• 消息清理：Stream 会持久化消息，需定期用 XTRIM 或 DEL 清理旧消息（如 XTRIM msg:queue MAXLEN 1000 保留最新 1000 条），避免内存溢出。

十、总结：数据结构选择与架构实践

Redis 各数据结构的特性、场景与技巧可归纳为：

架构实践：Redis 数据结构与分布式系统

1. 分布式锁：用 String 的 SETNX 或 Redis Cluster 下的 RedLock（多节点加锁，降低单节点故障风险）。
2. 集群数据分片：Redis Cluster 将键哈希到不同节点，需确保命令“集群兼容”（如 HGET 兼容，KEYS 不兼容）。
3. 主从复制与读写分离：数据结构的写命令（如 SET、LPUSH）发往主节点，读命令（如 GET、LRANGE）发往从节点，提升读性能。

通过深入理解每个数据结构的特性、命令用法及适用场景，可充分发挥 Redis 的高性能优势，构建高效、稳定的分布式系统。