1. 项目概述为什么Redis的五种数据类型是后端开发的必修课如果你是一名后端开发者或者正在向这个方向发展那么“Redis”这个名字对你来说一定不陌生。它早已超越了“缓存中间件”的单一标签成为了现代高并发、分布式系统中不可或缺的“多面手”。但很多朋友在初次接触Redis时往往会被其看似简单的键值对模型所迷惑以为它只是个“大号Map”结果在实际项目中要么用错了数据结构导致性能瓶颈要么对着官方文档里上百个命令无从下手。今天我们就来彻底拆解Redis操作五大核心数据类型的常用命令。这不仅仅是命令的罗列更是理解Redis设计哲学和实战应用场景的钥匙。我见过太多团队把List当队列用却不知道阻塞操作用Hash存对象却搞不清HGETALL的性能陷阱用Set做去重却忽略了SINTER的计算成本。掌握这些命令意味着你能在架构设计时精准地选择最合适的数据模型写出既高效又优雅的代码。无论你是想应对面试中“Redis五种数据类型及应用场景”的经典问题还是希望在下一个项目中游刃有余地使用Redis解决实际问题这篇内容都将为你提供一份详尽的“实战地图”。2. Redis数据类型总览与设计思想在深入每个类型的命令之前我们必须先理解Redis数据类型的核心设计思想。Redis不是一个简单的键值存储它更是一个数据结构服务器。这意味着你存储在Redis里的“值”不仅仅是字符串而是带有丰富语义和操作接口的数据结构。2.1 五大核心数据类型是什么Redis的五种基本数据类型是String字符串、Hash哈希、List列表、Set集合和Sorted Set有序集合。很多人会疑惑还有Bitmaps、HyperLogLogs、Geospatial这些呢它们本质上是基于String或ZSet的特殊用法是Redis在基础类型上构建的“高级功能”其底层操作仍然依赖于这五大核心类型。这五种类型的选择体现了计算机科学中经典数据结构的精髓线性表、哈希表、集合、有序集合。Redis将它们的内存效率和时间复杂度优化到了极致并提供了原子性的操作命令。2.2 键Key的通用法则无论值是什么类型访问它们的入口都是Key。关于Key的命令是操作所有数据类型的基石必须首先掌握。SET/GET/DEL/EXISTS: 基础中的基础。SET用于设置键值对GET用于获取DEL用于删除EXISTS用于判断键是否存在。EXPIRE/TTL/PEXPIRE: 过期时间管理。这是Redis作为缓存的核心功能。EXPIRE key seconds可以为键设置以秒为单位的生存时间。TTL key可以查看键剩余的生存时间秒返回-1表示永不过期-2表示键已不存在。PEXPIRE则是以毫秒为单位。TYPE key: 返回键所存储的值的类型。当你接手一个不熟悉的Redis实例或者调试问题时这个命令非常有用。KEYS pattern: 按模式查找键。例如KEYS user:*会匹配所有以user:开头的键。但请注意这是一个危险命令在生产环境的Redis上执行KEYS *可能会引发长时间的阻塞因为Redis是单线程的。替代方案是使用SCAN命令进行游标式迭代。实操心得关于KEYS命令的禁忌在我早期运维的一个电商项目中曾有一次线上事故就是因为一位开发同学在高峰期执行了KEYS *来查找某个模糊的键。这个操作直接导致Redis主线程阻塞了将近2秒这2秒内所有的请求全部超时引发了服务雪崩。从此我们立下铁规生产环境禁止使用KEYS。所有需要遍历键的场景必须使用SCAN命令。SCAN虽然可能返回重复的键但它通过游标分批次进行不会阻塞服务。3. String字符串类型不止是文本String是Redis最基本的数据类型一个Key对应一个Value。但它不仅能存文本还能存数字、甚至二进制数据如图片序列化后的字节流。最大能存储512MB。3.1 基础存取与自增自减SET key value/GET key: 最基本的设置和获取。SETNX key value: 仅在键不存在时设置。这是实现分布式锁的最基础原语。SETNX lock:order 1如果返回1表示获取锁成功。MSET/MGET: 批量设置和获取多个键值对能有效减少网络往返次数提升性能。INCR/DECR/INCRBY/DECRBY: 原子性的增减操作。这是String类型最强大的特性之一。INCR article:100:views 将文章ID为100的阅读数加1。这个操作是原子的完全不用担心并发竞争问题。INCRBY user:1000:balance 50 给用户1000的余额增加50。应用场景 计数器文章阅读量、用户点赞数、分布式序列号生成、缓存简单对象JSON序列化后存入。3.2 进阶操作与位图BitMapString还支持一些更精细的操作比如位操作这催生了BitMap这种强大的结构。SETBIT key offset value: 对Key所存储的字符串值设置或清除指定偏移量上的位bit。value只能是0或1。GETBIT key offset: 获取指定偏移量的位值。BITCOUNT key [start end]: 计算给定字符串中被设置为1的比特位的数量。BITOP operation destkey key [key ...]: 对一个或多个保存二进制位的字符串key进行位元操作并将结果保存到destkey上。operation可以是AND与、OR或、XOR异或、NOT非。应用场景用户签到 一年365天可以用一个365位的BitMap表示。SETBIT sign:2024:user1 100 1表示用户1在第100天从0开始签到了。BITCOUNT sign:2024:user1可以统计该用户今年的总签到次数。活跃用户统计 每天用一个BitMap每个用户占一位。要统计连续7天活跃的用户只需要对7个BitMap做BITOP AND操作然后统计结果中1的个数即可。这种方式的空间效率极高。注意事项大Key问题虽然String能存512MB但绝不意味着你可以随意存储一个几十MB的JSON字符串。这种“大Key”在通过网络传输、持久化RDB/AOF时会严重消耗带宽和I/O甚至引发Redis的慢查询。对于复杂的对象应优先考虑使用Hash类型拆分。4. Hash哈希类型存储对象的最佳选择Hash是一个String类型的field字段和value值的映射表特别适合存储对象。你可以把它理解为一个微型的、仅存在于Redis中的“数据库表”Key是表名field是列名。4.1 对象存储与操作HSET key field value: 将哈希表key中的字段field的值设为value。HGET key field: 获取存储在哈希表中指定字段的值。HMSET/HMGET: 批量设置/获取多个字段。注意新版本中HMSET已被HSET的多参数形式取代。HGETALL key: 获取在哈希表中指定key的所有字段和值。这是最常用的命令但也是最容易踩坑的命令。如果这个Hash对象非常大比如有1000个字段HGETALL会一次性返回所有数据可能阻塞Redis并占用大量客户端内存。HKEYS/HVALS: 获取所有字段名或所有值。HINCRBY key field increment: 为哈希表key中的指定字段的整数值加上增量increment。非常适合存储对象的计数属性如商品库存HINCRBY product:1000 stock -1。应用场景 存储用户信息user:1000-{name: 张三, age: 30, email: ...}、商品信息、配置信息等。4.2 如何避免HGETALL的陷阱对于字段很多的Hash推荐使用HSCAN命令它类似于SCAN可以渐进式地遍历所有字段和值避免阻塞。或者在设计上就进行垂直拆分将一个大对象拆分成多个小Hash用不同的Key存储。实操心得Hash vs String(JSON)早期我们习惯将用户对象序列化成JSON字符串然后用String类型存储。后来全部改成了Hash。原因有三1.局部更新修改用户年龄用HSET user:1000 age 31即可无需读写整个JSON字符串。2.内存效率对于字段较多的对象Redis的Hash有特殊的编码优化ziplist在字段少、值小时比存储JSON字符串更省内存。3.原子计数器可以直接使用HINCRBY而用String存储JSON则需先读取、解析、修改、序列化、写入非原子且繁琐。5. List列表类型不只是数组更是队列和栈List是简单的字符串列表按照插入顺序排序。你可以在头部左边或尾部右边添加元素。一个List最多可以包含 2^32 - 1 个元素。5.1 基础队列/栈操作LPUSH/RPUSHkey element [element ...]: 将一个或多个值插入到列表头部左边/尾部右边。LPOP/RPOPkey: 移除并返回列表的第一个左边/最后一个右边元素。LRANGE key start stop: 返回列表中指定区间内的元素区间以偏移量start和stop指定。LRANGE mylist 0 -1可以获取列表所有元素。组合应用LPUSHRPOP先进先出队列FIFOLPUSHLPOP后进先出栈LIFO应用场景 消息队列简易版、最新文章列表LPUSH新文章IDLRANGE 0 9取最新10条、记录用户最近的操作。5.2 阻塞操作与可靠队列这是List类型在消息队列场景下的杀手锏。BLPOP/BRPOPkey [key ...] timeout: 移出并获取列表的第一个/最后一个元素如果列表没有元素命令将阻塞连接直到等待超时或发现可弹出元素为止。timeout为0表示无限阻塞。BLPOP task_queue 30意味着“从task_queue列表左边弹出一个任务如果队列为空我就等在这里最多等30秒期间有任务进来我立刻处理如果30秒后还是空的就返回nil。”应用场景 构建简单的生产者-消费者模型。多个工作线程消费者用BLPOP阻塞等待任务业务系统生产者用LPUSH向队列投递任务。这种方式实现了负载均衡和流量削峰。注意事项List并非万能队列使用List做消息队列有几个致命缺点1.消息丢失消费者用RPOP取出消息后如果处理失败消息无法自动重回队列。2.不支持多播一条消息只能被一个消费者取走。3.没有ACK机制。因此对于要求可靠性的业务消息队列应使用Redis 5.0后引入的Stream类型或者专业的消息中间件如RabbitMQ、Kafka。List更适合做日志、临时任务等允许丢失的场景。6. Set集合类型去重与集合运算Set是String类型的无序集合通过哈希表实现其元素不可重复。它提供了高效的成员判断、交集、并集、差集运算。6.1 基本操作与随机元素SADD key member [member ...]: 向集合添加一个或多个成员。SREM key member [member ...]: 移除集合中一个或多个成员。SMEMBERS key: 返回集合中的所有成员。和HGETALL类似对于大集合要慎用可以考虑SSCAN。SISMEMBER key member: 判断member元素是否是集合key的成员。时间复杂度O(1)非常高效。SCARD key: 获取集合的成员数。SRANDMEMBER key [count]: 随机返回集合中一个或多个元素。count为正数时返回不重复元素为负数时可能返回重复元素。应用场景 标签系统给文章打标签SADD article:100:tags tech redis database、共同好友/关注、抽奖系统将所有参与者ID放入Set用SRANDMEMBER或SPOP抽奖。6.2 强大的集合运算SINTER key [key ...]: 返回所有给定集合的交集。例如SINTER user:1000:follows user:2000:follows可以得到用户1000和用户2000的共同关注列表。SUNION: 返回所有给定集合的并集。SDIFF key [key ...]: 返回第一个集合与其他集合之间的差集。例如SDIFF user:1000:follows user:2000:follows得到用户1000关注了但用户2000没关注的人。SINTERSTORE/SUNIONSTORE/SDIFFSTORE: 将集合运算的结果存储到一个新的集合中避免重复计算。实操心得SINTER的性能风险集合运算特别是SINTER交集在操作大集合时计算复杂度是O(N*M)可能会消耗大量CPU并阻塞Redis。在一次运营活动中我们需要计算两个百万级用户集的共同中奖资格直接使用SINTER导致Redis CPU瞬间打满服务响应变慢。解决方案1. 对于需要频繁计算的交集使用SINTERSTORE将结果缓存起来。2. 考虑使用Bitmap来存储用户ID是否存在用BITOP AND进行交集运算性能有数量级的提升但前提是用户ID是连续的整数或可以映射为整数。7. Sorted Set有序集合类型带权重的排行榜Sorted Set (ZSet) 和Set一样也是String类型元素的集合且不允许重复。但每个元素都会关联一个double类型的分数score。Redis正是通过分数来为集合中的成员进行从小到大的排序。成员是唯一的但分数却可以重复。7.1 排行榜核心操作ZADD key [NX|XX] [CH] [INCR] score member [score member ...]: 向有序集合添加一个或多个成员或者更新已存在成员的分数。参数INCR可以实现原子性的分数增加是排行榜更新的核心。ZRANGE key start stop [WITHSCORES]: 通过索引区间返回有序集合指定区间内的成员。分数从低到高排序。ZRANGE leaderboard 0 9 WITHSCORES获取排行榜前10名及其分数。ZREVRANGE key start stop [WITHSCORES]: 同上但分数从高到低排序这才是排行榜的常规视图。ZRANK/ZREVRANKkey member: 返回成员在集合中的正序/逆序排名。ZREVRANK leaderboard user1000得到user1000在排行榜上的名次从0开始。ZSCORE key member: 返回成员的分数。ZINCRBY key increment member: 有序集合中对指定成员的分数加上增量increment。ZINCRBY leaderboard 50 user1000给用户1000增加50分这是实现游戏积分、热度加权最常用的命令。应用场景 游戏积分排行榜、微博热搜榜热度为分数、带权重的任务队列执行时间为分数。7.2 范围查询与分页ZSet的强大之处在于基于分数的范围查询。ZRANGEBYSCORE/ZREVRANGEBYSCOREkey min max [WITHSCORES] [LIMIT offset count]: 返回分数在指定区间内的成员。这是实现“筛选”功能的关键。ZRANGEBYSCORE products:price 100 200 WITHSCORES获取价格在100到200之间的所有商品。ZREVRANGEBYSCORE leaderboard inf -inf WITHSCORES LIMIT 0 10获取排行榜前10名inf和-inf表示正负无穷。应用场景 价格区间筛选、时间线时间戳为分数获取某个时间段内的消息。注意事项分数相同时的排序当多个成员分数相同时Redis会按照成员的字典序lexicographical order进行排序。这在设计排行榜时需要留意如果希望分数相同时按其他规则如最新达成时间排序一个常见的技巧是将时间戳作为分数的小数部分或者将“分数”和“时间戳”组合成一个新的分数如score 实际分数 * 1e10 (1e10 - timestamp)确保分数权重高时间戳在分数相同时起作用。8. 命令使用中的常见“坑”与最佳实践掌握了命令不等于能写好程序。下面是我在多年实践中总结的几个高频问题和应对策略。8.1 大Key与热Key问题大Key 指一个Key对应的Value非常大如一个包含百万字段的Hash或一个超长的List/String。危害操作耗时、网络阻塞、持久化慢、内存不均。排查使用redis-cli --bigkeys扫描对线上有影响慎用。解决拆分。Hash拆成多个小Hash大List拆成多个子List大String考虑是否能用其他结构替代。热Key 指某个Key在瞬间被高频访问流量远超其他Key。危害造成单台Redis服务器CPU压力激增可能成为性能瓶颈。排查监控QPS或使用redis-cli --hotkeys需要开启maxmemory-policy为LFU。解决1.本地缓存在应用层使用Guava Cache或Caffeine做一层本地缓存。2.Key拆分将一个热Key拆成多个子Key如hot:key拆成hot:key:1hot:key:2 访问时随机选择一个。3.使用Redis集群但热Key可能仍会落在同一个分片。8.2 管道Pipeline与事务Transaction/Multi管道Pipeline 将多个命令打包一次性发送给Redis服务器再一次性读取所有回复。这能极大减少网络往返延迟RTT带来的开销。在需要连续执行多个无关命令时如初始化数据务必使用Pipeline。注意Pipeline中的命令不具备原子性中间可能会被其他客户端命令插入。事务Multi/Exec 通过MULTI开启一个事务将多个命令入队然后用EXEC原子性地执行。它保证了这些命令被连续、不被中断地执行隔离性。重要误区Redis事务不支持回滚Rollback。如果事务中某条命令出错其他命令仍会继续执行。它更像一个“批量执行”的打包脚本。8.3 Lua脚本复杂原子操作的终极武器当你需要执行一个“获取-判断-修改”的复杂操作并确保其原子性时Pipeline和事务都力不从心。这时就需要Lua脚本。Redis使用单线程执行Lua脚本在执行期间不会处理其他命令因此脚本中的多个操作是原子性的。例如实现一个库存扣减并记录日志的操作local stock redis.call(HGET, KEYS[1], stock) if tonumber(stock) 0 then return 0 end redis.call(HINCRBY, KEYS[1], stock, -1) redis.call(LPUSH, KEYS[2], ARGV[1]) return 1通过EVAL命令执行这个脚本可以确保检查和扣减是原子的。8.4 连接管理与连接池频繁创建和销毁Redis连接是巨大的性能开销。在生产环境中必须使用连接池。常见的客户端如Jedis、Lettuce、Redisson都提供了连接池实现。需要合理配置池的大小、最大空闲时间等参数。过小的连接池会导致请求等待过大的连接池会浪费资源。9. 可视化客户端与监控调试命令行固然强大但一个好的可视化工具能极大提升开发和运维效率。Another Redis Desktop Manager / Redis Desktop Manager 这两款是跨平台的桌面客户端支持直观的键值查看、编辑、命令执行、监控图表等。对于不熟悉命令的新手或者需要快速浏览数据结构的场景非常方便。redis-cli监控命令MONITOR 实时打印服务器接收到的所有命令。仅用于调试对性能影响极大生产环境禁用。SLOWLOG GET 查看慢查询日志。这是优化Redis性能的重要依据需要定期检查。INFO 获取丰富的服务器信息和统计信息如内存使用情况、客户端连接数、持久化状态等。理解命令是基础但真正的功力体现在如何根据业务场景组合、优化这些命令并规避其中的陷阱。从简单的缓存到复杂的排行榜、消息队列、社交关系Redis的五种数据类型为你提供了构建高性能应用的乐高积木。记住没有最好的数据结构只有最合适的数据结构。下次设计功能时不妨先问问自己“用Redis的哪种结构来实现最优雅、最高效” Redis五大核心数据类型命令全解析：从基础原理到高并发实战应用
1. 项目概述为什么Redis的五种数据类型是后端开发的必修课如果你是一名后端开发者或者正在向这个方向发展那么“Redis”这个名字对你来说一定不陌生。它早已超越了“缓存中间件”的单一标签成为了现代高并发、分布式系统中不可或缺的“多面手”。但很多朋友在初次接触Redis时往往会被其看似简单的键值对模型所迷惑以为它只是个“大号Map”结果在实际项目中要么用错了数据结构导致性能瓶颈要么对着官方文档里上百个命令无从下手。今天我们就来彻底拆解Redis操作五大核心数据类型的常用命令。这不仅仅是命令的罗列更是理解Redis设计哲学和实战应用场景的钥匙。我见过太多团队把List当队列用却不知道阻塞操作用Hash存对象却搞不清HGETALL的性能陷阱用Set做去重却忽略了SINTER的计算成本。掌握这些命令意味着你能在架构设计时精准地选择最合适的数据模型写出既高效又优雅的代码。无论你是想应对面试中“Redis五种数据类型及应用场景”的经典问题还是希望在下一个项目中游刃有余地使用Redis解决实际问题这篇内容都将为你提供一份详尽的“实战地图”。2. Redis数据类型总览与设计思想在深入每个类型的命令之前我们必须先理解Redis数据类型的核心设计思想。Redis不是一个简单的键值存储它更是一个数据结构服务器。这意味着你存储在Redis里的“值”不仅仅是字符串而是带有丰富语义和操作接口的数据结构。2.1 五大核心数据类型是什么Redis的五种基本数据类型是String字符串、Hash哈希、List列表、Set集合和Sorted Set有序集合。很多人会疑惑还有Bitmaps、HyperLogLogs、Geospatial这些呢它们本质上是基于String或ZSet的特殊用法是Redis在基础类型上构建的“高级功能”其底层操作仍然依赖于这五大核心类型。这五种类型的选择体现了计算机科学中经典数据结构的精髓线性表、哈希表、集合、有序集合。Redis将它们的内存效率和时间复杂度优化到了极致并提供了原子性的操作命令。2.2 键Key的通用法则无论值是什么类型访问它们的入口都是Key。关于Key的命令是操作所有数据类型的基石必须首先掌握。SET/GET/DEL/EXISTS: 基础中的基础。SET用于设置键值对GET用于获取DEL用于删除EXISTS用于判断键是否存在。EXPIRE/TTL/PEXPIRE: 过期时间管理。这是Redis作为缓存的核心功能。EXPIRE key seconds可以为键设置以秒为单位的生存时间。TTL key可以查看键剩余的生存时间秒返回-1表示永不过期-2表示键已不存在。PEXPIRE则是以毫秒为单位。TYPE key: 返回键所存储的值的类型。当你接手一个不熟悉的Redis实例或者调试问题时这个命令非常有用。KEYS pattern: 按模式查找键。例如KEYS user:*会匹配所有以user:开头的键。但请注意这是一个危险命令在生产环境的Redis上执行KEYS *可能会引发长时间的阻塞因为Redis是单线程的。替代方案是使用SCAN命令进行游标式迭代。实操心得关于KEYS命令的禁忌在我早期运维的一个电商项目中曾有一次线上事故就是因为一位开发同学在高峰期执行了KEYS *来查找某个模糊的键。这个操作直接导致Redis主线程阻塞了将近2秒这2秒内所有的请求全部超时引发了服务雪崩。从此我们立下铁规生产环境禁止使用KEYS。所有需要遍历键的场景必须使用SCAN命令。SCAN虽然可能返回重复的键但它通过游标分批次进行不会阻塞服务。3. String字符串类型不止是文本String是Redis最基本的数据类型一个Key对应一个Value。但它不仅能存文本还能存数字、甚至二进制数据如图片序列化后的字节流。最大能存储512MB。3.1 基础存取与自增自减SET key value/GET key: 最基本的设置和获取。SETNX key value: 仅在键不存在时设置。这是实现分布式锁的最基础原语。SETNX lock:order 1如果返回1表示获取锁成功。MSET/MGET: 批量设置和获取多个键值对能有效减少网络往返次数提升性能。INCR/DECR/INCRBY/DECRBY: 原子性的增减操作。这是String类型最强大的特性之一。INCR article:100:views 将文章ID为100的阅读数加1。这个操作是原子的完全不用担心并发竞争问题。INCRBY user:1000:balance 50 给用户1000的余额增加50。应用场景 计数器文章阅读量、用户点赞数、分布式序列号生成、缓存简单对象JSON序列化后存入。3.2 进阶操作与位图BitMapString还支持一些更精细的操作比如位操作这催生了BitMap这种强大的结构。SETBIT key offset value: 对Key所存储的字符串值设置或清除指定偏移量上的位bit。value只能是0或1。GETBIT key offset: 获取指定偏移量的位值。BITCOUNT key [start end]: 计算给定字符串中被设置为1的比特位的数量。BITOP operation destkey key [key ...]: 对一个或多个保存二进制位的字符串key进行位元操作并将结果保存到destkey上。operation可以是AND与、OR或、XOR异或、NOT非。应用场景用户签到 一年365天可以用一个365位的BitMap表示。SETBIT sign:2024:user1 100 1表示用户1在第100天从0开始签到了。BITCOUNT sign:2024:user1可以统计该用户今年的总签到次数。活跃用户统计 每天用一个BitMap每个用户占一位。要统计连续7天活跃的用户只需要对7个BitMap做BITOP AND操作然后统计结果中1的个数即可。这种方式的空间效率极高。注意事项大Key问题虽然String能存512MB但绝不意味着你可以随意存储一个几十MB的JSON字符串。这种“大Key”在通过网络传输、持久化RDB/AOF时会严重消耗带宽和I/O甚至引发Redis的慢查询。对于复杂的对象应优先考虑使用Hash类型拆分。4. Hash哈希类型存储对象的最佳选择Hash是一个String类型的field字段和value值的映射表特别适合存储对象。你可以把它理解为一个微型的、仅存在于Redis中的“数据库表”Key是表名field是列名。4.1 对象存储与操作HSET key field value: 将哈希表key中的字段field的值设为value。HGET key field: 获取存储在哈希表中指定字段的值。HMSET/HMGET: 批量设置/获取多个字段。注意新版本中HMSET已被HSET的多参数形式取代。HGETALL key: 获取在哈希表中指定key的所有字段和值。这是最常用的命令但也是最容易踩坑的命令。如果这个Hash对象非常大比如有1000个字段HGETALL会一次性返回所有数据可能阻塞Redis并占用大量客户端内存。HKEYS/HVALS: 获取所有字段名或所有值。HINCRBY key field increment: 为哈希表key中的指定字段的整数值加上增量increment。非常适合存储对象的计数属性如商品库存HINCRBY product:1000 stock -1。应用场景 存储用户信息user:1000-{name: 张三, age: 30, email: ...}、商品信息、配置信息等。4.2 如何避免HGETALL的陷阱对于字段很多的Hash推荐使用HSCAN命令它类似于SCAN可以渐进式地遍历所有字段和值避免阻塞。或者在设计上就进行垂直拆分将一个大对象拆分成多个小Hash用不同的Key存储。实操心得Hash vs String(JSON)早期我们习惯将用户对象序列化成JSON字符串然后用String类型存储。后来全部改成了Hash。原因有三1.局部更新修改用户年龄用HSET user:1000 age 31即可无需读写整个JSON字符串。2.内存效率对于字段较多的对象Redis的Hash有特殊的编码优化ziplist在字段少、值小时比存储JSON字符串更省内存。3.原子计数器可以直接使用HINCRBY而用String存储JSON则需先读取、解析、修改、序列化、写入非原子且繁琐。5. List列表类型不只是数组更是队列和栈List是简单的字符串列表按照插入顺序排序。你可以在头部左边或尾部右边添加元素。一个List最多可以包含 2^32 - 1 个元素。5.1 基础队列/栈操作LPUSH/RPUSHkey element [element ...]: 将一个或多个值插入到列表头部左边/尾部右边。LPOP/RPOPkey: 移除并返回列表的第一个左边/最后一个右边元素。LRANGE key start stop: 返回列表中指定区间内的元素区间以偏移量start和stop指定。LRANGE mylist 0 -1可以获取列表所有元素。组合应用LPUSHRPOP先进先出队列FIFOLPUSHLPOP后进先出栈LIFO应用场景 消息队列简易版、最新文章列表LPUSH新文章IDLRANGE 0 9取最新10条、记录用户最近的操作。5.2 阻塞操作与可靠队列这是List类型在消息队列场景下的杀手锏。BLPOP/BRPOPkey [key ...] timeout: 移出并获取列表的第一个/最后一个元素如果列表没有元素命令将阻塞连接直到等待超时或发现可弹出元素为止。timeout为0表示无限阻塞。BLPOP task_queue 30意味着“从task_queue列表左边弹出一个任务如果队列为空我就等在这里最多等30秒期间有任务进来我立刻处理如果30秒后还是空的就返回nil。”应用场景 构建简单的生产者-消费者模型。多个工作线程消费者用BLPOP阻塞等待任务业务系统生产者用LPUSH向队列投递任务。这种方式实现了负载均衡和流量削峰。注意事项List并非万能队列使用List做消息队列有几个致命缺点1.消息丢失消费者用RPOP取出消息后如果处理失败消息无法自动重回队列。2.不支持多播一条消息只能被一个消费者取走。3.没有ACK机制。因此对于要求可靠性的业务消息队列应使用Redis 5.0后引入的Stream类型或者专业的消息中间件如RabbitMQ、Kafka。List更适合做日志、临时任务等允许丢失的场景。6. Set集合类型去重与集合运算Set是String类型的无序集合通过哈希表实现其元素不可重复。它提供了高效的成员判断、交集、并集、差集运算。6.1 基本操作与随机元素SADD key member [member ...]: 向集合添加一个或多个成员。SREM key member [member ...]: 移除集合中一个或多个成员。SMEMBERS key: 返回集合中的所有成员。和HGETALL类似对于大集合要慎用可以考虑SSCAN。SISMEMBER key member: 判断member元素是否是集合key的成员。时间复杂度O(1)非常高效。SCARD key: 获取集合的成员数。SRANDMEMBER key [count]: 随机返回集合中一个或多个元素。count为正数时返回不重复元素为负数时可能返回重复元素。应用场景 标签系统给文章打标签SADD article:100:tags tech redis database、共同好友/关注、抽奖系统将所有参与者ID放入Set用SRANDMEMBER或SPOP抽奖。6.2 强大的集合运算SINTER key [key ...]: 返回所有给定集合的交集。例如SINTER user:1000:follows user:2000:follows可以得到用户1000和用户2000的共同关注列表。SUNION: 返回所有给定集合的并集。SDIFF key [key ...]: 返回第一个集合与其他集合之间的差集。例如SDIFF user:1000:follows user:2000:follows得到用户1000关注了但用户2000没关注的人。SINTERSTORE/SUNIONSTORE/SDIFFSTORE: 将集合运算的结果存储到一个新的集合中避免重复计算。实操心得SINTER的性能风险集合运算特别是SINTER交集在操作大集合时计算复杂度是O(N*M)可能会消耗大量CPU并阻塞Redis。在一次运营活动中我们需要计算两个百万级用户集的共同中奖资格直接使用SINTER导致Redis CPU瞬间打满服务响应变慢。解决方案1. 对于需要频繁计算的交集使用SINTERSTORE将结果缓存起来。2. 考虑使用Bitmap来存储用户ID是否存在用BITOP AND进行交集运算性能有数量级的提升但前提是用户ID是连续的整数或可以映射为整数。7. Sorted Set有序集合类型带权重的排行榜Sorted Set (ZSet) 和Set一样也是String类型元素的集合且不允许重复。但每个元素都会关联一个double类型的分数score。Redis正是通过分数来为集合中的成员进行从小到大的排序。成员是唯一的但分数却可以重复。7.1 排行榜核心操作ZADD key [NX|XX] [CH] [INCR] score member [score member ...]: 向有序集合添加一个或多个成员或者更新已存在成员的分数。参数INCR可以实现原子性的分数增加是排行榜更新的核心。ZRANGE key start stop [WITHSCORES]: 通过索引区间返回有序集合指定区间内的成员。分数从低到高排序。ZRANGE leaderboard 0 9 WITHSCORES获取排行榜前10名及其分数。ZREVRANGE key start stop [WITHSCORES]: 同上但分数从高到低排序这才是排行榜的常规视图。ZRANK/ZREVRANKkey member: 返回成员在集合中的正序/逆序排名。ZREVRANK leaderboard user1000得到user1000在排行榜上的名次从0开始。ZSCORE key member: 返回成员的分数。ZINCRBY key increment member: 有序集合中对指定成员的分数加上增量increment。ZINCRBY leaderboard 50 user1000给用户1000增加50分这是实现游戏积分、热度加权最常用的命令。应用场景 游戏积分排行榜、微博热搜榜热度为分数、带权重的任务队列执行时间为分数。7.2 范围查询与分页ZSet的强大之处在于基于分数的范围查询。ZRANGEBYSCORE/ZREVRANGEBYSCOREkey min max [WITHSCORES] [LIMIT offset count]: 返回分数在指定区间内的成员。这是实现“筛选”功能的关键。ZRANGEBYSCORE products:price 100 200 WITHSCORES获取价格在100到200之间的所有商品。ZREVRANGEBYSCORE leaderboard inf -inf WITHSCORES LIMIT 0 10获取排行榜前10名inf和-inf表示正负无穷。应用场景 价格区间筛选、时间线时间戳为分数获取某个时间段内的消息。注意事项分数相同时的排序当多个成员分数相同时Redis会按照成员的字典序lexicographical order进行排序。这在设计排行榜时需要留意如果希望分数相同时按其他规则如最新达成时间排序一个常见的技巧是将时间戳作为分数的小数部分或者将“分数”和“时间戳”组合成一个新的分数如score 实际分数 * 1e10 (1e10 - timestamp)确保分数权重高时间戳在分数相同时起作用。8. 命令使用中的常见“坑”与最佳实践掌握了命令不等于能写好程序。下面是我在多年实践中总结的几个高频问题和应对策略。8.1 大Key与热Key问题大Key 指一个Key对应的Value非常大如一个包含百万字段的Hash或一个超长的List/String。危害操作耗时、网络阻塞、持久化慢、内存不均。排查使用redis-cli --bigkeys扫描对线上有影响慎用。解决拆分。Hash拆成多个小Hash大List拆成多个子List大String考虑是否能用其他结构替代。热Key 指某个Key在瞬间被高频访问流量远超其他Key。危害造成单台Redis服务器CPU压力激增可能成为性能瓶颈。排查监控QPS或使用redis-cli --hotkeys需要开启maxmemory-policy为LFU。解决1.本地缓存在应用层使用Guava Cache或Caffeine做一层本地缓存。2.Key拆分将一个热Key拆成多个子Key如hot:key拆成hot:key:1hot:key:2 访问时随机选择一个。3.使用Redis集群但热Key可能仍会落在同一个分片。8.2 管道Pipeline与事务Transaction/Multi管道Pipeline 将多个命令打包一次性发送给Redis服务器再一次性读取所有回复。这能极大减少网络往返延迟RTT带来的开销。在需要连续执行多个无关命令时如初始化数据务必使用Pipeline。注意Pipeline中的命令不具备原子性中间可能会被其他客户端命令插入。事务Multi/Exec 通过MULTI开启一个事务将多个命令入队然后用EXEC原子性地执行。它保证了这些命令被连续、不被中断地执行隔离性。重要误区Redis事务不支持回滚Rollback。如果事务中某条命令出错其他命令仍会继续执行。它更像一个“批量执行”的打包脚本。8.3 Lua脚本复杂原子操作的终极武器当你需要执行一个“获取-判断-修改”的复杂操作并确保其原子性时Pipeline和事务都力不从心。这时就需要Lua脚本。Redis使用单线程执行Lua脚本在执行期间不会处理其他命令因此脚本中的多个操作是原子性的。例如实现一个库存扣减并记录日志的操作local stock redis.call(HGET, KEYS[1], stock) if tonumber(stock) 0 then return 0 end redis.call(HINCRBY, KEYS[1], stock, -1) redis.call(LPUSH, KEYS[2], ARGV[1]) return 1通过EVAL命令执行这个脚本可以确保检查和扣减是原子的。8.4 连接管理与连接池频繁创建和销毁Redis连接是巨大的性能开销。在生产环境中必须使用连接池。常见的客户端如Jedis、Lettuce、Redisson都提供了连接池实现。需要合理配置池的大小、最大空闲时间等参数。过小的连接池会导致请求等待过大的连接池会浪费资源。9. 可视化客户端与监控调试命令行固然强大但一个好的可视化工具能极大提升开发和运维效率。Another Redis Desktop Manager / Redis Desktop Manager 这两款是跨平台的桌面客户端支持直观的键值查看、编辑、命令执行、监控图表等。对于不熟悉命令的新手或者需要快速浏览数据结构的场景非常方便。redis-cli监控命令MONITOR 实时打印服务器接收到的所有命令。仅用于调试对性能影响极大生产环境禁用。SLOWLOG GET 查看慢查询日志。这是优化Redis性能的重要依据需要定期检查。INFO 获取丰富的服务器信息和统计信息如内存使用情况、客户端连接数、持久化状态等。理解命令是基础但真正的功力体现在如何根据业务场景组合、优化这些命令并规避其中的陷阱。从简单的缓存到复杂的排行榜、消息队列、社交关系Redis的五种数据类型为你提供了构建高性能应用的乐高积木。记住没有最好的数据结构只有最合适的数据结构。下次设计功能时不妨先问问自己“用Redis的哪种结构来实现最优雅、最高效”