1. 先搞懂Redis命令的分类逻辑很多刚接触Redis的同学上来就背命令背了几天发现还是记不住一写就忘。其实这不是记忆力的问题是学习姿势不对。Redis的命令表面上看起来五花八门实际有一套非常清晰的分类逻辑先把这个逻辑理清楚你根本不需要死记硬背。1.1 Redis到底在帮你存什么Redis是一个内存型的数据存储它和传统关系型数据库最大的区别在于它存储的核心单元不是表和行而是键值对Key-Value。每一个值都对应一个唯一的键通过键来读写、删除、设置生存时间这是Redis所有操作的基础。在值这一层Redis定义了五种基本数据类型字符串String、哈希Hash、列表List、集合Set、有序集合ZSet。这五种类型是Redis的五脏六腑后面几乎所有高级功能比如分布式锁、排行榜、延迟队列、布隆过滤器都是建立在它们之上的。理解了这五种类型各自适合什么场景命令的记忆会轻松很多。1.2 命令命名里藏着规律Redis的命令不是随手乱起的它的规律非常明显基本结构是类型操作词。比如字符串类型的所有写操作都是SET、MSET、GETSET、SETNX这样以类型或操作意图为核心的组合。你只要知道当前我要操作的是哪种类型剩下的命令基本都能猜个八九不离十。这个设计逻辑很像现实里的动词名词结构把商品放进购物车对应哈希类型的HSET把消息推到队列尾部对应列表类型的RPUSH。我在实际教学里经常让同事不要按命令表背而是按业务场景去推演如果你要实现一个计数器你要用字符串里的哪个命令答案自然就是INCR。场景驱动记忆比背字典高效得多。1.3 通用命令和类型命令的分工Redis里还有一类命令是不区分数据类型的比如DEL、EXISTS、EXPIRE、TYPE、KEYS它们操作的是键本身而不是键里面的值。这类命令数量不多但每一两个都极其常用。我习惯把它分为三个梯队第一梯队DEL、EXISTS、TYPE、EXPIRE、TTL日常必用闭着眼睛要能写出来。第二梯队RENAME、RENAMENX、PERSIST解决键名调整和过期时间取消问题。第三梯队KEYS、SCAN、DBSIZE、FLUSHDB用起来有讲究用得不好会踩坑后面我会专门讲。把这层分类搞明白你就有了一个地图接下来我按类型逐个拆解常用命令每个命令都给出实际场景保证你读完就能上手。2. String字符串最基础应用面最广String是Redis里最简单的类型一个键对应一个字符串值。但它绝对不简单它是实现缓存、计数器、分布式锁、限流等功能的基石。2.1 SET与GET缓存的读写核心SET key value和GET key是Redis入门第一课几乎所有缓存场景都由这两个命令构成。简单背后有几个细节值得说一说。第一SET命令在写入时如果键已经存在会直接覆盖旧值不管旧值是什么类型。如果你拿Redis存缓存直接用SET是没问题的但如果你在某个业务里拿它存不可覆盖的数据就要小心。第二SET命令是可带参数的完整命令不一定要用单独的SETEX。SET key value EX 60等价于SETEX key 60 value两者的区别仅在于调用习惯。这里给一个我常用的缓存写入组合读请求先查Redis查不到就查数据库再回填Redis并设置过期时间。伪代码长这样value redis.get(user:profile:123) if value is None: value db.query_user(123) redis.set(user:profile:123, value, ex3600)这个模式叫Cache Aside是最经典的缓存读写策略。但要注意回填缓存时一定要设置过期时间我见过好多次因为忘了加ex参数导致缓存里的数据永远是旧的线上排查半天才发现。2.2 MSET与MGET批量操作减少网络开销如果几十个键要写你会怎么做一条一条发SET命令每条都要走一次网络请求这在本地开发时感觉不到在线上高并发场景下就是灾难。Redis提供了批量操作MSET key1 value1 key2 value2 ...和MGET key1 key2 ...一次命令搞定多个键。批量命令能显著减少RTT往返时延比如你要初始化一批商品的初始库存用一条MSET就完成不需要写循环。我在压测过一个接口时单条写入到MSET批量写入吞吐量差距在3倍以上。但批量命令也有两个注意点一是命令长度不要过大一次几百个键问题不大几千个键可能会导致网络包过大反而拖慢Redis二是MGET返回的顺序是请求键的顺序不是随机顺序你传入key1 key2 key3返回就是对应的value1 value2 value3一一对应别搞混。2.3 INCR与DECR计数器的正确姿势INCR key让键的值加1DECR让键的值减1还有INCRBY和DECRBY支持加减指定步长。它们的共同前提是键的值必须是整数形式的字符串否则会报错。为什么用INCR不用先GET再SET原因很简单原子性。Redis是单线程执行命令INCR这一个命令在执行过程中不会插进来其他命令而GETSET是两个命令中间可能会被其他客户端打断导致计数丢失。在并发场景下这个差别是致命的。我举一个实际场景接口访问次数统计。INCR api:access:20240901这个计数器的值会自增配合EXPIRE可以自动清零实现每天一统计。再用GET读取当前值到某个阈值触发告警或限流。这个逻辑极其简洁而且扛得住高并发因为Redis单线程天然解决了并发写冲突的问题。再比如电商库存扣减很多人第一反应是用数据库的UPDATE但在秒杀场景下数据库扛不住正确做法是先让Redis扛写流量用DECR扣库存判断返回值是否小于0小于0说明超卖需要回滚DECR product:stock:1001返回值如果是负数说明库存被扣超了此时要做补偿性回滚比如再INCR一次把库存加回来。这个方案我在多个高并发项目里都验证过关键在于Redis的命令原子性这是它作为计数器核心底座的根本原因。2.4 SETNX与SETEX从锁到限流的两个高频工具SETNX key valueSET if Not eXists的意思是如果键不存在才设置它天然适合做分布式锁的加锁动作。不过裸用SETNX有个坑如果客户端在拿到锁之后崩溃了没有释放锁这个锁会永远存在。所以生产环境更推荐用带过期时间的原子命令SET lock:order:1001 1 EX 30 NX这里NX表示只有不存在时才设置EX 30表示30秒后自动过期。很多老程序员还在用SETNX加锁再EXPIRE两个命令分开执行中间进程崩了锁就变成死锁。这个坑我在早期项目里踩过后来统一改成SET ... EX ... NX一条命令锁的可靠性提升了一个数量级。SETEX key seconds value则是设置值过期时间的合并命令它的价值在于原子性。如果分两步走SET key value再EXPIRE key 10中间断电或者进程异常退出缓存就是永久的可能把过期缓存带到线上好几天。我在生产环境处理过的缓存永不失效事故十次有八次是这个原因。2.5 其他String命令APPEND、STRLEN、GETSETAPPEND key value在字符串末尾追加内容适合做日志拼接、字符串增长场景。STRLEN key返回字符串长度注意中文环境下它返回的是字节数一个UTF-8中文占3个字节这个细节很多人没注意到。GETSET key value先返回旧值再写入新值适合做取旧值并更新的原子操作比如轮换令牌、更新序列号。String类型虽然结构简单却是五种类型里使用频率最高、在生产踩坑最多的类型。核心就一句话能用单命令原子完成的绝不用两步操作需要过期的过期时间一定写进命令里。3. Hash与List结构化数据的两只抓手前面说过String只能存一个字符串值当你想存一个对象——比如用户信息、商品详情——用String就得序列化成一整段JSON读取时还要反序列化修改一个字段时更是痛苦你得读出整个JSON在内存里改了字段再整个写回去。Hash和List就是为了解决这类结构化数据操作而生的。3.1 HSET与HGET以对象为单位读写字段Hash类型的结构是一个键下面挂多个字段每个字段又有独立的值。你可以理解成Redis里的一个Hash键就是一张只有两列的表字段名和字段值。常用命令命令作用示例HSET key field value设置单个字段HSET user:1001 name TomHMSET批量设置多个字段已废弃HSET支持多字段HSET user:1001 name Tom age 25HGET key field读取单个字段HGET user:1001 nameHMGET key field1 field2读取多个字段HMGET user:1001 name ageHGETALL key读取所有字段和值HGETALL user:1001HDEL key field1 field2删除字段HDEL user:1001 ageHEXISTS key field判断字段是否存在HEXISTS user:1001 nameHLEN key统计字段数量HLEN user:1001一个典型的应用是缓存用户信息。比如用户表有name, age, email三个字段用Hash存取可以做到只更新某个字段而不影响其他字段HSET user:1001 name Tom HSET user:1001 age 26 HINCRBY user:1001 age 1HINCRBY可以对Hash中的字段做数值自增非常适合做在线时长点赞数这类对象内部计数。String能做的数值操作Hash中的字段大多数也能做比如HINCRBYFLOAT支持浮点增减。用Hash存对象最大的好处是省流量和内存。比如用户对象有20个字段你用String存整个JSON改一个字段也要传整个JSON用Hash只需要传字段名和新值网络开销差一个数量级。当然Hash也有局限如果字段特别多HGETALL会拖出整个Hash大对象用HSCAN分批次读会更安全。3.2 购物车与用户画像Hash的实战思路我做过一个购物车模块最开始用String存购物车每个用户存一个JSON数组用户每次加购、改数量都要先读出整个JSON再反序列化、修改、序列化、写回。下单高峰期Redis负载很高排查之后发现大量耗时都在JSON序列化和大字符串读写上。换成Hash之后购物车变成了这样# 用户1001的购物车key为cart:1001 # 字段是商品ID值是商品数量 HSET cart:1001 2001 2 HSET cart:1001 2002 1 HINCRBY cart:1001 2001 1 # 商品2001加购1件 HGET cart:1001 2001 # 查询某商品数量 HLEN cart:1001 # 购物车共有几种商品这样的好处是加购、改数量只需要操作一个字段Redis内部把Hash编码得很紧凑内存占用也降低不少。如果字段值很小、数量也不多Redis会自动用ziplist紧凑编码存储比String存JSON还要省内存。用Hash注意一点不要在一个Hash里塞太多字段。一个键存一万个字段HGETALL一次拉全量网络和内存都会很紧张。按业务维度拆键比如购物车按用户拆画像按天拆是更稳健的做法。3.3 LPUSH与RPUSH从两端操作列表List类型是一个双向链表支持从两端压入和弹出元素。先把命令记牢LPUSH key value [value...]从头部左边压入元素RPUSH key value [value...]从尾部右边压入元素LPOP key从头部弹出并返回元素RPOP key从尾部弹出并返回元素LLEN key返回列表长度LRANGE key start end返回指定范围内的元素LINDEX key index返回指定下标元素LREM key count value删除等于value的元素count正数从头部删负数从尾部删LSET key index value指定下标设置值BLPOP key timeout阻塞式从头部弹出超时时间秒最容易混的是LPUSH和RPUSH的方向。记住一个口诀LLeft头RRight尾即可。LRANGE key 0 -1代表取全部元素-1代表倒数第一个。List非常适合做最新动态列表每次用户发一条动态LPUSH到列表头部再用LRANGE key 0 99取最新100条不需要查数据库排序LPUSH feed:user:1001 发布了新文章 LTRIM feed:user:1001 0 99LTRIM只保留前100条避免列表无限增长这个命令在列表场景中非常实用。3.4 用List实现轻量消息队列List的左压右弹或右压左弹组合可以完美实现一个FIFO消息队列。生产端RPUSH task:queue job-1 RPUSH task:queue job-2消费端LPOP task:queue但普通的LPOP有个问题队列为空时直接返回nil消费者需要轮询浪费CPU。Redis为此提供了阻塞版BLPOP和BRPOPBLPOP task:queue 00表示无限阻塞直到有新元素。这个命令让消费者可以挂起等待新消息一到立刻返回既实时又不浪费资源。我在一个项目里用List做任务分发当时的方案是多个Worker进程同时BRPOP同一个任务队列Redis的BRPOP保证每个元素只会被一个Worker拿到天然实现负载均衡。队列为空时Worker们阻塞等待完全不用写复杂的消息中间件十行代码搞定。但要注意List消息队列没有消息确认机制如果Worker拿到消息之后崩了这个任务就丢了。对可靠性要求高的场景要么做处理完再删除的可靠队列要么直接上专业的消息队列中间件。这是List队列的天花板。4. Set与ZSet集合运算和排序的利器Set和ZSet就是字面意思Set是无序集合ZSet是有序集合。它们解决的场景非常有辨识度标签、好友关系、去重、排行榜、延迟任务。4.1 SADD与SISMEMBER集合的增查Set的核心特点是元素唯一自动去重。常用命令命令作用SADD key member [member...]添加一个或多个元素已存在则忽略SREM key member [member...]删除元素SMEMBERS key返回集合所有元素SISMEMBER key member判断元素是否存在返回1/0SCARD key返回集合元素个数SPOP key [count]随机弹出元素SRANDMEMBER key [count]随机返回元素但不删除SINTER/SUNION/SDIFF交集/并集/差集运算SADD做去重标记是极好的。比如用户手机号黑名单SADD blacklist:phone 13800138000 SISMEMBER blacklist:phone 13800138000返回1就是命中判断速度是O(1)比数据库查一遍快得多。再比如用户签到每个用户一个Set签到日期做元素SADD user:sign:202509 20250901即可重复签到自动失败不需要额外校验。4.2 共同好友与标签系统集合运算的真香现场集合运算是我最推荐新手多玩的功能因为它在很多业务里能把复杂的SQL查询变成一个命令。假设两个用户的关注列表分别存在follow:user:1001和follow:user:1002计算他们的共同关注SINTER follow:user:1001 follow:user:1002一个命令返回交集两条SQL加内存里去重都省了。类似的还有我关注的人也关注了他这个二度关系推荐实际是一条SINTER命令的事只是集合key从单用户变成了我关注列表的每一个人的关注列表稍微变换一下key写法而已。标签系统同理。每篇文章打标签SADD article:tags:1001 Redis MySQL SADD article:tags:1002 Redis Python找出包含Redis但不包含MySQL的文章可以用差集SDIFF article:tags:1001 article:tags:1002如果你需要根据标签反查文章再维护反向索引SADD tag:Redis article:1001 article:1002这样就是典型的正反索引设计。Set的运算在内存里执行速度极快适合在线聚合场景比跑数据库JOINGROUP BY快得多。4.3 ZADD与ZRANGE排行榜的标配ZSet是带分数的Set每个元素关联一个分数scoreRedis按分数自动排序。这个特性让它成为排行榜功能的天然实现。核心命令ZADD leaderboard 100 playerA ZADD leaderboard 200 playerB ZADD leaderboard 150 playerC自动按分数升序排列。读取排名ZRANGE leaderboard 0 -1 # 升序取全部 ZREVRANGE leaderboard 0 -1 # 降序取全部第一名在前 ZSCORE leaderboard playerA # 查某个玩家的分数 ZCARD leaderboard # 排行榜人数 ZRANK leaderboard playerA # 升序排名 ZREVRANK leaderboard playerA # 降序排名实际项目里用户每次得分ZINCRBY leaderboard 10 playerA # 给playerA加10分一个命令完成加分排序连重新排序都不用写。排行榜TopNZREVRANGE leaderboard 0 9 # 前10名我在项目里实现过用户积分周榜核心逻辑就这几行数据库只在结算时用一次其余全部走Redis。4.4 延时任务与范围查询ZSet的进阶使用ZSet的分数还可以存时间戳这样它就能做延时任务。比如订单超时30分钟自动关闭思路是订单创建时用当前时间30分钟作为score订单ID作为member写进ZSET delay:orderZADD delay:order (unix_time 1800) order:1001然后启动一个定时任务每秒执行ZRANGEBYSCORE delay:order -inf now拿到所有score小于当前时间戳的订单就是已经超时的订单再执行关闭操作并用ZREM删除已处理的member。这个方案比轮询数据库高效得多我在订单、短时优惠券、定时通知场景都这么干过稳定可靠。ZRANGEBYSCORE还支持区间查询比如查分数在100到200之间的人对应会员等级、价格区间筛选一个命令搞定。5. 通用命令键的生命周期管理前面讲的全是围绕值的操作这一部分讲讲围绕键本身的操作。它是所有数据类型公用的容易被忽略但生产环境出问题往往就出在这几个命令上。5.1 KEYS与SCAN千万别在生产环境用KEYSKEYS pattern可以模糊匹配所有键名KEYS user:*这条命令的开发环境用得很爽但生产环境是高危操作。原因Redis是单线程执行命令KEYS会遍历整个键空间如果Redis里有几百万个键这条命令执行期间会阻塞Redis所有读写请求全部卡住严重时直接打挂线上服务。我见过一次线上事故同事排查数据时执行了KEYS order:*恰好那一刻业务正在搞活动几千个QPS瞬间掉底紧接着熔断告警一片红。那次之后我们统一规定代码里禁止出现KEYS一律用SCAN。SCAN cursor [MATCH pattern] [COUNT count]是游标式遍历每次只返回一部分数据不阻塞RedisSCAN 0 MATCH user:* COUNT 100返回结果包含两个部分新的游标值和本次扫描到的key列表。如果新游标不等于0就继续用新游标迭代SCAN 12345 MATCH user:* COUNT 100如此反复直到游标回到0遍历完成。整个过程对Redis的影响很小适合生产环境捞数据。我目前的生产环境排查脚本全部用SCAN替换KEYS一次都没再出过事。5.2 EXPIRE与TTL过期时间管理给键设过期时间是Redis缓存策略的核心。三条命令必背EXPIRE key seconds设置过期时间单位秒TTL key查询剩余存活时间返回-1表示永不过期-2表示键不存在PERSIST key取消过期时间键变为永久还有一种更精细的用法EXPIRE key timestamp可以把过期时间设成一个绝对时间戳适合统一在午夜清除当天数据这类场景。TTL经常被用来做缓存是否准确的判断我排查缓存不更新问题时第一步就是看TTL如果预期是60秒过期结果返回-1基本就能断定是当时写缓存漏了过期时间。补充一个细节过期时间依赖Redis的惰性删除定期删除机制。惰性删除是读的时候发现过期就删定期删除是每100毫秒抽查一批过期键。所以一个键到期了并不会立刻从内存消失你要有个心理预期。如果关心精确删除时间点可以在业务层做兜底读的时候判断一下值是否为空或过期标记。5.3 DEL、UNLINK与存在性判断DEL key [key...]删除键返回删除个数UNLINK key异步删除键。删除一个大key比如几MB的String、几十万个元素的List时DEL会阻塞RedisUNLINK在后台释放内存不影响主线程EXISTS key判断键是否存在存在返回1TYPE key返回键的类型有string、list、hash、set、zsetUNLINK是我强烈建议写进规范里的命令。我在清理缓存时删过一个3GB的List大key当时用的DELRedis直接卡了大概2秒线上接口超时一大片。后来统一大key删除一律UNLINK再没出现过这个问题。判断一个大key的标准简单说部署Redis的内存较大、键值占用的内存较大时都适用。5.4 键重命名和库信息RENAME key newkey可以给键改名RENAMENX key newkey则只在目标键名不存在时才改名用于防止覆盖。DBSIZE返回当前库中的键数量FLUSHDB清空当前库FLUSHALL清空所有库。这两个清空命令非常危险一旦执行数据全没生产环境绝对要慎用建议在配置文件里禁用rename-command FLUSHALL 。另外还有一个高频参数命令INFO。执行INFO可以看到Redis运行状态包括内存占用、客户端连接数、每秒处理的命令数、命中率等是排查故障的第一现场。6. 亲身踩过的坑命令用不好线上两行泪这一部分是我最想写的内容。网上教程把命令讲得很清楚但实际生产环境里命令怎么选择、在哪里踩坑很少有人系统地写。我把自己经历过的教训整理成几条每一条都是真金白银换来的。6.1 大Key是Redis性能的头号杀手大Key没有一个绝对标准但结合实际经验String超过1MB、集合元素超过1万个、总内存占用能排进单实例前几名时它就算大Key了。大Key的危害读写超时一次GET几MB的字符串网络传输耗时很长阻塞Redis删除大Key时DEL会阻塞主线程影响所有请求内存不均Redis集群模式下大Key会导致某个分片内存暴涨排查方法用redis-cli --bigkeys可以扫描出大Key分布这个命令在生产环境比较安全因为它们本质上是SCAN做统计不阻塞。找到大Key之后想办法拆分String拆成多段Hash、List、Set按业务维度拆分别让一个键承载太多数据。6.2 对过期时间的迷信很多人以为设置了EXPIRE就万事大吉其实在并发场景下缓存过期瞬间会有一大批请求同时打到数据库造成缓存击穿。我处理过的典型事故一个热门活动配置缓存过期时间设了2小时活动上线时刚好是晚间高峰缓存一过期瞬间几千个请求全打到数据库上数据库CPU立刻飙升接口全部超时。这类问题的通用解法是多级防护缓存过期时间加随机偏移避免同一时间大批量过期用分布式锁或逻辑过期兜底只有一个请求去刷新缓存其他请求等锁热点数据直接不设置过期时间由后台任务定时刷新命令层面不复杂但方案选型很重要。最简单的实践是SET key value EX 3600时把过期时间设成3600加随机数比如3600到3900之间让过期时间错开。6.3 Pipeline和连接池批量命令的正确用法前面讲过MGET、MSET能一次传多个键但如果你要做的是一堆不同命令的批量操作MGET就无能为力了。这时要用Pipeline管道机制。Pipeline不是一条Redis命令而是一种客户端行为把多条命令一次性发给RedisRedis处理完再一次性返回结果。这能极大减少RTT。比如清一批缓存pipe redis.pipeline() pipe.delete(key1) pipe.delete(key2) pipe.set(key3, value3) pipe.expire(key3, 3600) pipe.execute()我实测过普通逐个执行1000条命令需要3到5秒用Pipeline压缩到几十毫秒。但注意Pipeline一次命令数过多Redis需要同时处理大量数据内存和CPU也会瞬时走高。我一般控制在几百条以内。连接池也是一定要做的应用层每来一个请求就新建一个Redis连接连接建立本身有一定开销高并发下会导致Redis的连接数堆积。用连接池复用连接是每个生产项目的基本操作。很多Redis连接超时的问题最后都出在连接没有走连接池、每次都重新建连上。6.4 命令监控用INFO和COMMANDSTATS发现隐患INFO STATS里的total_commands_processed是启动以来执行命令的总数instantaneous_ops_per_sec是当前每秒命令数。这两个指标告诉你Redis正在承受多大压力。INFO COMMANDSTATS是排查慢命令的利器。它输出每条命令的执行次数和耗时占比例如cmdstat_get:calls1000,usec12000,usec_per_sec12.00 cmdstat_keys:calls5,usec150000,usec_per_sec30000.00看到get命令每次平均12微秒这是正常的keys命令每次平均3万微秒这就是雷。有了这个统计哪个命令拖累了Redis一目了然。排查慢命令的另一个方法是用慢日志SLOWLOG GET 10查看最近10条慢命令SLOWLOG LEN查看慢日志条数。我在压测时几乎每个项目都会顺手开慢日志线上出问题能省一半排查时间。6.5 命令速查表一份能贴墙的清单为了日常使用方便我整理了一张精简速查表按类型归档每个命令配一个最典型的场景。这张表是我自己工作的外挂也分享给你。类型命令典型场景StringSET key value EX seconds缓存写入带过期时间StringGET key缓存读取StringINCR key/DECR key计数器、库存扣减StringSET key value NX EX seconds分布式锁StringMSET/MGET批量读写HashHSET key field value对象字段读写HashHGETALL key读取整个对象HashHINCRBY key field n对象内部数值自增ListLPUSH/RPUSH入队ListLPOP/RPOP出队ListBLPOP key timeout阻塞式消费ListLRANGE key 0 N分页取列表SetSADD key member去重标记SetSISMEMBER key member快速判断是否存在SetSINTER/SUNION/SDIFF交集/并集/差集运算ZSetZADD key score member排行榜写入ZSetZINCRBY key n member排行榜加分ZSetZREVRANGE key 0 N排行榜TopNZSetZRANGEBYSCORE key min max延时任务、区间查询通用EXPIRE key seconds设置过期时间通用TTL key查剩余时间通用DEL/UNLINK删除键/异步删除通用SCAN cursor MATCH pattern安全遍历键空间通用TYPE key查键类型这份表不需要背把表里的每个命令结合场景用一遍自然就记住了。最后说几句实际的我先声明Redis命令本身不难难的是在真实业务里选对命令。学命令最好的方式不是看文档而是给自己布置几个小任务用SETEXPIRE做一个带过期的缓存用INCR完成一个计数器用LPUSHBRPOP搭一个消息队列用ZADDZREVRANGE写一个排行榜。这四个任务做下来五种基础类型你就能熟练大半。我个人在实际排查线上问题时的体会是大部分Redis性能问题都不是命令写错了而是没有考虑这条命令在数据量很大时会发生什么。每次写Redis命令前都问自己一句如果这个键里有一百万个元素这条命令还安全吗想清楚了再执行也不迟。Redis的命令集不算大但每一条用在合适的场景里都能让业务跑得又快又稳。