聊到 Redis，很多人第一反应是“快”，第二反应可能是“我只会 set 和 get”。说实话，我见过不少同学用了一年 Redis，翻来覆去还是那几个命令，一旦遇到缓存穿透、分布式锁、批量处理这些场景，就不知道该怎么用命令组合去解决，只能去搜现成代码。这篇博文不打算做命令文档的搬运工，而是把 Redis 的命令体系拆开揉碎，从设计逻辑、底层数据结构、典型业务场景、踩坑经验几个维度来讲清楚每个命令到底该怎么用、为什么这么用、哪些参数是必须注意的。
无论你是刚接触 Redis 的新手，还是写了好几年业务的开发，或者正在准备面试想突击一下命令细节，这篇文章都值得仔细看一遍。我会尽量用实际场景来说话，而不是干巴巴地列语法。比如同样的一个 INCR，为什么在秒杀场景里用它就是对的，在计数不准的场景里就得换方案，这些光看官方文档是体会不到的。
1. 命令体系整体拆解：先搞懂 Redis 的“语言逻辑”
1.1 为什么命令详解比背 API 更重要
很多人学 Redis 命令是零散地记，今天用到一个查一个，明天又忘了。这是因为没有理解 Redis 命令背后的设计逻辑。Redis 本质上是一个基于内存的键值数据库，它的命令体系围绕两个核心维度展开：数据怎么存（数据类型）和数据怎么管（生命周期、内存、持久化）。
命令不是孤立的 API，它们是对底层数据结构的一种操作封装。比如 HSET 操作的是哈希表，LPUSH 操作的是双向链表，ZADD 操作的是跳表加哈希表的组合。你如果只看命令名称，很难理解为什么 ZSET 可以同时支持“按分数查询”和“按成员查询”，但一旦知道底层是“跳表 + 字典”的组合结构，一切就顺理成章了。这也是为什么我建议所有做后端的人，学命令的同时一定要补一下 Redis 的底层数据结构课。
另外，命令的使用方式直接决定了 Redis 的性能表现。同样是对一个 key 做写入，SET 和 APPEND 的底层操作路径完全不同；同样是删除一个大 key，DEL 会阻塞主线程，UNLINK 却可以异步回收内存。这些差异只看文档是记不住的，必须在理解底层逻辑之后才能形成肌肉记忆。
1.2 命令分类的四个维度：别再把所有命令混为一谈
站在使用者的角度，我习惯把 Redis 命令分成四类，这个分类思路对学习和排查问题都很有帮助：
第一类是数据类型操作命令，包括 String、Hash、List、Set、ZSet 这五种数据类型的增删改查。这是日常开发中用得最多的一类，也是这篇文章重点拆解的部分。
第二类是通用键命令，比如 DEL、EXPIRE、TTL、EXISTS、TYPE、RENAME，它们不区分数据类型，作用于 key 本身。这类命令容易被忽略，但恰恰是调优和排查问题的关键。
第三类是事务与脚本命令，包括 MULTI、EXEC、DISCARD、WATCH 以及 Lua 脚本相关命令。这类命令解决的是“多条命令组合操作的原子性”问题，是分布式场景下非常关键的工具。
第四类是运维管理命令，比如 INFO、CONFIG GET/SET、SLOWLOG、CLIENT LIST、MONITOR、DBSIZE、FLUSHDB 等。这类命令通常由运维或资深开发使用，用来观察 Redis 的运行状态、定位慢请求。
分类的好处在于，当你脑子里的命令是“分桶”的，遇到问题时就能快速定位该用哪个桶里的工具。比如缓存不生效，先查通用键命令里的 TTL 和 EXISTS，确认 key 还在不在；线上 CPU 飙升，先查运维命令里的 INFO commandstats 和 SLOWLOG，看是哪些命令在拖垮实例。而不是漫无目的地乱试。
2. 核心命令深度剖析：从场景与底层看真实用法
2.1 String 命令：不只是 SET 和 GET，细节里藏着大坑
String 是 Redis 最基础的数据类型，底层是 SDS（简单动态字符串），支持字符串、整数、浮点数三种表现形式。日常用的最多的是 SET 和 GET，但真正常用且容易出错的，是那批带参数的扩展命令。
先说 SET 的完整语法，这一点必须记牢：
SET key value [NX | XX] [GET] [EX seconds | PX milliseconds | EXAT unix-time-seconds | PXAT unix-time-milliseconds | KEEPTTL]这里的 NX 表示只有当 key 不存在时才设置，XX 表示只有 key 存在时才设置。这两个选项是后面讲分布式锁的基础，也是很多人在命令行里手误用错的地方。我见过有人用SET key value NX EX 60实现分布式锁，这里 NX 和 EX 是可以同时出现的，Redis 2.6.12 以后支持这种组合写法，这是官方推荐的原子性加锁方式。
GETSET 这个命令现在很多人已经不用了，但它在某些场景里依然好用，比如要“取旧值并设置新值”时，GETSET 可以一步完成，省去一次网络往返。Redis 6.2 还新增了 GETDEL（先取值再删除）和 GETEX（取值并同时设置过期时间），这两个命令在处理一次性令牌、验证码场景时非常顺手。
再说到 INCR、INCRBY、DECR、DECRBY，这些命令是原子性的自增自减操作。很多人觉得它们只是“帮你在内存里做了个 +1”，其实关键在于原子性。在并发场景下，如果先 GET 再 SET，中间一定会有窗口期导致丢更新，但 INCR 是在 Redis 服务端内部完成的，单条命令天然串行，不存在竞态问题。这也是秒杀库存扣减可以直接用 INCR 减库存的原因。
但注意，热词里有“redis incr不准”，这通常不是 INCR 本身的问题，而是使用姿势错了。常见错误包括：没有设置过期时间导致 key 永久增长；在集群模式下 key 分布不均匀导致单节点热点；或者干脆是用 Lua 脚本里 GET 加 SET 的方式误以为原子但实际没加锁。INCR 的结果本身不会“不准”，要排查的是业务逻辑中是否有多处写入源没有统一走 INCR。
MSET 和 MGET 是批量版 SET 和 GET，一次命令操作多个 key，能显著减少网络往返。比如批量查用户的多个信息字段，用 MGET 一次搞定比循环 GET 快得多。这里的坑是，批量命令虽然能减少 RTT，但在 Redis Cluster 集群模式下，如果 key 不在同一个 slot，MGET 就无法跨节点执行，通常只能分段批量或者用 Hash Tag 把相关 key 放到同一个 slot。
2.2 Hash 命令：字段级操作在业务建模中的妙用
Hash 类型底层有两种编码：数据量少时用 ziplist（紧凑列表），数据量大时转为 hashtable。HSET、HGET、HDEL、HGETALL 是最基本的操作，但在实际业务中，我强烈建议掌握 HINCRBY 和 HSCAN。
HINCRBY 可以对 Hash 中的某个字段做原子自增。这在统计场景中很常用，比如要记录一个商品维度的多个计数（浏览量、收藏量、加购量），用 HSET 加 HINCRBY 组合就能在一个 key 里维护多个计数器，避免每个计数器单独占用一个 key。相比 String 的 INCR，HINCRBY 的粒度更细，但代价是每次操作都多了一个字段维度，底层对 ziplist 的读写略复杂。数据量小的时候无所谓，一旦字段数量破了阈值，性能会有一定波动。
HGETALL 看起来方便，一次取出所有字段和值。但它很容易被误用，特别是哈希里字段很多的时候。HGETALL 是 O(N) 操作，field 一多，命令耗时线性上升，在 QPS 高的场景下容易拖垮 Redis。官方也因此提供了 HSCAN 这类游标式遍历命令。HSCAN 的用法和后面要说的 SCAN 一样，通过游标分批返回，不阻塞主线程。
Hash 还有一个经常被忽略的优点：字段级过期控制是做不到的，这是设计上需要注意的。如果你需要某个字段在指定时间后自动失效，只能整体过期整个 Hash key，或者用另一种方案——把字段设计成独立的 String key，灵活但牺牲了聚合性。没有一种方案是完美的，关键在于你的业务更看重聚合管理还是更看重粒度控制。
2.3 List 命令：队列场景的底层支撑与阻塞版本
List 底层是双向链表（quicklist 结构），兼具栈和队列的特性。基础命令是 LPUSH、RPUSH、LPOP、RPOP、LRANGE、LINDEX、LLEN、LREM 等。其中 LPUSH 加 RPOP 组合就是一个标准的 FIFO 消息队列，RPUSH 加 LPOP 也是一个队列，只是方向反了。
这里要特别说的是阻塞版本的 LPOP：BLPOP 和 BRPOP。这两个命令是消息队列实现中不可或缺的利器。它们的作用是：如果列表里没有元素，客户端会阻塞等待，直到有元素进来或者超时。可以指定多个 key 按顺序检查，还可以设置超时时间，0 表示永久阻塞。
那为什么不用 LPOP 轮询？因为轮询会频繁发起空查询，白白消耗网络和 CPU，延迟还高。BLPOP 把“等待”这件事下沉到了 Redis 端，不占用业务线程，实现更优雅。用BLPOP queue 5这样的命令，如果 5 秒内没有消息，返回 nil，客户端可以做其他处理。这种方式比 sleep 加 LPOP 效率高一个数量级。
项目中我还经常用 LRANGE 做分页读取，比如查看一个任务队列的前 10 条记录。注意 LRANGE 的区间是闭区间，LRANGE list 0 9取的是第一条到第十条。很多新手会写成LRANGE list 0 10，结果多取了一条。LREM key count value 的参数 count 有正数、负数、0 三种含义，正数表示从头部开始删除最多 count 个匹配项，负数表示从尾部开始删除，0 表示删除所有匹配项。这个细节面试中也经常被拿来当考点。
2.4 Set 命令：集合运算在标签、好友、推荐系统中的实战
Set 底层是整数集合（intset）或哈希表（hashtable），特性是无序、元素唯一。基础命令 SADD、SREM、SISMEMBER、SMEMBERS、SCARD 比较简单，真正有强大价值的是集合运算命令：SINTER（交集）、SUNION（并集）、SDIFF（差集）。
举个典型的业务场景：一个 APP 要给用户推送个性化内容，需要找到“用户 A 的好友集合”和“喜欢篮球的用户的集合”的交集，用 SINTERSTORE 把结果缓存到一个临时 key，再配合 EXPIRE 设置过期时间，比在业务代码里做双重循环高效得多。又比如标签系统，给一篇文章打标签集合，给一个用户兴趣打标签集合，SINTER 就能直接找到匹配的内容。
SMEMBERS 和 HGETALL 类似，是 O(N) 命令，集合大了以后要改用 SSCAN 游标遍历，避免阻塞。SISMEMBER 则是 O(1) 操作，适合高并发场景下的存在性判断。
SPOP 和 SRANDMEMBER 这两个命令容易被混淆。SPOP 是从集合中随机弹出一个或多个元素，返回后就从集合中移除，适合做抽奖、随机淘汰。SRANDMEMBER 是随机返回一个或多个元素，但不会移除，适合做随机推荐但保留候选池的场景。两者虽然只有一字之差，语义完全不同，用错会导致业务逻辑严重偏离预期。
2.5 ZSet 命令：排行榜与延迟队列的利器
ZSet（有序集合）是 Redis 里最“高级”的数据类型，底层用跳表（skiplist）加哈希表实现，成员唯一，但每个成员关联一个 double 类型的分数，按分数排序存储。ZADD、ZSCORE、ZINCRBY、ZRANGE、ZREVRANGE、ZRANGEBYSCORE、ZRANK、ZREM 是高频命令。
排行榜是最经典的场景。比如实时更新用户积分榜，用 ZADD 或 ZINCRBY 维护一个 zset 类型的 key，分数就是积分总值。查询 Top N 直接用ZREVRANGE key 0 N-1 WITHSCORES（按分数从高到低取）。如果要看某个用户的排名，用 ZREVRANK。这些操作都是 O(log N) 级别，性能完全不是问题。
还有一个很多老手爱用的冷门场景：延迟队列。利用 ZSet 的分数存到期时间戳，写入任务时 ZADD key 时间戳 member，后台轮询ZRANGEBYSCORE key 0 当前时间戳 LIMIT 0 1，把到了执行时间的任务取出来处理，处理完成后 ZREM 或者用 ZINCRBY 把时间戳往后推。这个方案简单有效，而且天然支持按时间排序，比用 List 的队列方案灵活得多。
ZRANGE 的语法带 WITHSCORES 参数时才会返回分数，不带则只返回成员。Redis 6.2 还新增了 ZRANGE 的 REV 参数和 BYSCORE 参数，可以用来替代 ZREVRANGE 和 ZRANGEBYSCORE，语法更统一。这些新的变化有时候官方文档更新的也不及时，需要我们自己去翻 changelog。
2.6 通用命令与过期机制：EXPIRE、TTL、DEL 的时效性管理
我把通用键命令单独拿出来讲，因为它们太容易被忽略，却又太重要了。EXPIRE 设置过期时间，TTL 查看剩余存活时间，PERSIST 取消过期，DEL 删除 key，EXISTS 判断是否存在，TYPE 查看类型，RENAME 重命名。这套命令组合起来，就是 Redis 的“生命周期管理”。
先说 EXPIRE 的一个经典坑：SET 一个已存在的 key，默认会清除原来的过期时间。因为 SET 会创建新值，之前的 TTL 会被重置。如果要保留原来的过期时间，必须显式带 KEEPTTL 参数（Redis 6.0 以上支持）。这个坑我踩过不止一次，线上缓存突然“过期时间丢了”，十有八九是更新 value 的时候用了不带 KEEPTTL 的 SET。
TTL 的返回值需要特别注意：-1表示 key 存在但没有设置过期时间，-2表示 key 不存在。很多人在业务代码里判断 TTL 返回值时，只处理了负数，没有区分 -1 和 -2，导致逻辑判断错误。比如想“如果 key 快过期了就续期”，不能简单判断ttl < 10，因为 ttl 为 -1 时也小于 10，但 -1 表示没有过期时间，不需要续期。
DEL 是大家最常用但最容易对线上造成事故的命令。DEL 一个非常大的 key（比如一个百万成员的 zset），在 Redis 主线程里执行时，会耗费大量时间清理内存对象，直接阻塞其他命令的执行。Redis 4.0 之后提供了 UNLINK 命令，功能和 DEL 一样，但是异步删除，主线程只负责把 key 从键空间摘除，真正的内存回收交给后台线程慢慢做。所以，删除大 key 时请务必用 UNLINK。
3. 实操过程记录：从零搭建一套可复用的 Redis 命令工作流
3.1 安装、连接工具与可视化客户端的命令配合
很多人装 Redis 的时候，就卡在第一步。这里分享一个最省事的 macOS 安装方式：直接brew install redis，装完以后redis-server启动服务，redis-cli -h 127.0.0.1 -p 6379进入命令行。Windows 上官方不提供原生支持，比较顺手的方式是装 WSL 后在 Linux 子系统里操作，或者用 Docker 起一个容器：docker run -d --name redis -p 6379:6379 redis。无论哪种方式，最终都要有一个能敲命令的 redis-cli 终端。
可视化客户端方面，我先后用过 Redis Desktop Manager 和 Another Redis Desktop Manager。前者早期免费后来收费，后者是目前用得比较顺的开源替代品，支持多平台、SSH 隧道、JSON 格式化显示，非常适合日常查数据。但请记住，可视化工具是查数据的，不是压测的，更不是执行的。真正常用的命令操作、批量修改，我依然推荐在 redis-cli 里完成，因为可控性最强，每一步做了什么清清楚楚。
连接上 redis-cli 之后，第一件事建议执行INFO SERVER看版本，执行INFO STATS看连接状况和命令执行情况。这两个命令是排查线上问题的基础入口。
3.2 典型业务场景的命令组合实战
下面我用三个高频率业务场景，把上面拆解过的命令串起来，给出一套可以直接“抄作业”的命令组合。
场景一：带过期时间且需要原子更新的用户会话信息
用户登录后需要写入会话数据，设置 30 分钟过期，每次活跃时刷新过期时间，但不想每次刷新都重写整个会话。命令组合如下：
# 写入会话，30分钟过期 SET session:user:1001 "{...}" EX 1800 # 用户活跃时，只续期但不修改值 EXPIRE session:user:1001 1800 # 如果要同时更新内容和续期，必须注意保留过期时间 SET session:user:1001 "{...new...}" KEEPTTL第三个命令用KEEPTTL保留了原来的过期时间，这是 Redis 6.0+ 才有的参数，旧版本没有替代方案，只能先拿到 TTL 再重新 SET，中间会有窗口期，这也是很多历史代码里隐藏的 bug。
场景二：排行榜实现
游戏积分排行榜，玩家每次完成一局游戏，积分变动可能加分也可能扣分，都要实时反映在榜上。命令组合：
# 玩家1001增加50分 ZINCRBY leaderboard:game:001 50 user:1001 # 玩家1002增加30分,玩家1003增加80分 ZADD leaderboard:game:001 30 user:1002 80 user:1003 # 查看前三名及分数 ZREVRANGE leaderboard:game:001 0 2 WITHSCORES # 查看玩家1001的当前排名（从0开始，所以第一名0） ZREVRANK leaderboard:game:001 user:1001这里有一点要注意：玩家只玩过一局、没有积分时，他根本不存在于 zset 里，ZREVRANK会返回 nil。业务代码里要做空值处理，别把 nil 当 0 直接塞进 int 类型。
场景三：简单的消息队列
生产者把任务推入 list，消费者用阻塞命令取任务，取到后处理，处理完还能用 LREM 做确认。命令组合：
# 生产者推送一条订单超时检查任务 RPUSH task:order:check "order:10001" # 消费者阻塞等待任务，最多等5秒 BLPOP task:order:check 5 # 取出的是一个数组，[0]是key名，[1]是value # 处理完后清理残留（通常在代码中已完成，不需要这一步）3.3 命令速查表：贴在办公桌上的一页纸
这里送给读者一张速查表，按数据类型分类，覆盖最常用的命令及其关键参数。我自己一直用这张表，新员工入职也会发一份。
| 类型 | 命令 | 关键说明 |
|---|---|---|
| String | SET key value NX EX seconds | NX + EX 原子加锁最常用 |
| String | MSET k1 v1 k2 v2 | 批量写，减少 RTT |
| String | INCR / INCRBY key num | 原子自增，适合计数器、限流 |
| String | GETDEL / GETEX | 6.2+ 取旧值同时删/设过期 |
| Hash | HSET key field value | 字段级写入 |
| Hash | HINCRBY key field num | 字段级原子自增 |
| Hash | HSCAN key cursor | 大哈希游标遍历，忌用 HGETALL |
| List | LPUSH / RPUSH / LPOP / RPOP | 栈与队列基础 |
| List | BLPOP / BRPOP key timeout | 阻塞弹出，队列首选 |
| List | LRANGE key start stop | 闭区间分页读取 |
| Set | SADD / SREM / SISMEMBER | 标签与存在性判断 |
| Set | SINTER / SUNION / SDIFF | 交并差运算 |
| Set | SPOP / SRANDMEMBER | 弹出 vs 随机取，不会混用 |
| ZSet | ZADD key score member | 写排行榜 |
| ZSet | ZREVRANGE key start stop WITHSCORES | 高分到低分取 Top N |
| ZSet | ZINCRBY key num member | 积分变更 |
| 通用 | EXPIRE / TTL / PERSIST | 生命周期三件套 |
| 通用 | DEL / UNLINK | DEL 阻塞，UNLINK 异步 |
| 管理 | INFO commandstats | 看各命令调用次数和耗时 |
| 管理 | SLOWLOG GET 10 | 慢日志，排查性能瓶颈 |
4. 常见问题与排查技巧实录
4.1 分布式锁：命令细节决定成败
热词里有“redis分布式锁”，这确实是从命令详解到工程实践最经典的跳板。如果你打算在项目里用 Redis 做分布式锁，必须先搞清楚几个核心命令的语义。
加锁的正确姿势是SET lock_key unique_value NX EX 30。NX 保证只有一个客户端能成功设置，EX 30 保证即使处理意外崩溃，锁也会在 30 秒后自动释放，避免死锁。unique_value 是每个客户端的唯一标识（比如 UUID），这在释放锁时至关重要。
释放锁的推荐姿势是用 Lua 脚本保证原子性：先 GET 判断 unique_value 是否是自己持有的锁，如果是再 DEL。为什么不能直接 DEL？因为如果锁已经过期被别人抢到，你直接 DEL 会把别人的锁释放掉。可以先 GET 再 DEL，但两步操作有竞态窗口，所以在 Redis 里必须用 Lua 脚本把这个判断和删除封装成原子操作。
还有一个实际问题：锁的过期时间设短了，业务还没执行完锁就自动释放了；设长了，一旦持有锁的进程崩溃，其他进程要等很久才能拿到锁。业界常用的方案是“自动续期”，比如用 Redisson 的 watchdog，在锁快过期时自动续期。手动实现也不难，就是后台起一个定时线程，每隔 10 秒执行一次EXPIRE lock_key 30，前提是 GET 判断锁还属于自己。这个场景就把 EXPIRE 命令用得淋漓尽致了。
4.2 缓存治理中的命令陷阱：穿透、击穿、雪崩
缓存治理这个话题很大，但落到命令层面，核心就三个：怎么让不值得缓存的数据快速绕过、怎么让热点 key 不过期、怎么防止失效瞬间压垮数据库。
缓存穿透的典型表现是查询一个不存在的 key，每次都会落到数据库。命令行层面的对策有两个：一是对空值也做缓存，SET key 空值 EX 60，把不存在的数据也短暂缓存起来；二是用布隆过滤器，但这个涉及额外的数据结构，这里不展开。空值缓存要注意设置合理过期时间，别缓存太久导致数据一直无法更新。
缓存击穿是某个热点 key 过期瞬间，大量并发查询同时穿透到数据库。命令层面的手段是“互斥重建”：用SET lock:key unique_value NX EX 10抢锁，抢到锁的请求重新加载数据写缓存，抢不到的请求先返回旧值或稍等重试。这时候分布式锁的命令又重新用上了。
缓存雪崩是大量 key 在同一时刻过期，请求整体压向数据库。命令层面的预防手段很简单：SET 时不设固定过期时间，而是加一个随机偏移量，EXPIRE key 3600 + random(0,300)，让过期时间错峰。另一个常用手法是用 KEEPTTL 机制在业务低峰期主动刷新 key。这些细节看似简单，但能做到位的团队真的不多。
4.3 O(N) 命令与阻塞命令：别让一条命令毁了整个实例
Redis 是单线程执行命令的，所以任何 O(N) 命令都可能成为阻塞源头。我以前遇到过线上 redis-slowlog 里全是 SMEMBERS 和 HGETALL，再一看这个 key 有几百万个元素，业务侧还每秒调几次，CPU 直接飙满。
建议强制执行的规范有这几条：生产环境严禁使用 KEYS 命令，排查 key 用 SCAN；严禁对超大集合执行 SMEMBERS 或 HGETALL，改用 SSCAN 和 HSCAN；大批量删除 key 时不要循环 DEL，用 UNLINK 异步删除；严禁在业务高峰期执行 FLUSHDB 或 FLUSHALL，必须执行时用后台异步方式或者凌晨执行。
热词里有一个“history命令详解”“linux screen命令详解”，虽然它们是 Linux 命令，但这里可以类比一下：Redis 的 MONITOR 命令就像 Linux 的 history，能把所有命令实时打印出来，但同样很危险。MONITOR 开启期间 Redis 的吞吐量会大幅下降，生产环境千万别开着 MONITOR 去排查问题，那等于给自己制造故障。想检查实时命令，用CLIENT LIST看连接数，用INFO commandstats看命令分布，比 MONITOR 安全得多。
4.4 序列化、可视化管理与日志配合
Redis 存中文或者对象的时候，很多人会遇到“可视化管理工具里看到一堆转义字符”的问题。这不一定是 Redis 的错，通常是序列化方式的问题。如果用的是 Java 的 JdkSerializationRedisSerializer，看到的是\xAC\xED这种二进制乱码；用 Jackson 序列化则是一串 JSON 字符串，在可视化工具里能直接看懂。建议优先用 JSON 序列化配合 StringRedisTemplate，方便排查问题，排查速度本身就是生产力。
热词里有“systemd 脚本命令 详解包含app的日志输出到终端”，这个跟 Redis 命令关系不大，但如果你想在服务器上跑 Redis 服务并想实时看到日志输出，可以把 Redis 配置文件的 logfile 设成空字符串，让日志输出到标准输出，再交给 systemd 的 journald 管理。这样journalctl -u redis -f就能实时查看 Redis 运行日志，比进容器看文件方便很多。
另外，配置文件中slowlog-log-slower-than 10000（单位微秒）可以设置慢日志阈值，slowlog-max-len 128控制保存条数。线上排查命令性能问题时，SLOWLOG GET 10出来的每条记录都包含执行时间、命令参数、客户端地址，是定位问题最直接的证据。
4.5 集群模式下命令使用的四个注意点
Redis Cluster 环境下，命令的使用有很多隐性约束，不提前了解会在上线后踩坑。
第一，多 key 操作（MGET、MSET、DEL 多个 key、事务）要求 key 必须在同一个 slot，否则命令报错。解决办法是用 Hash Tag，比如{user:1001}.name和{user:1001}.age，花括号内的部分参与哈希计算，保证两个 key 落在同一个 slot。
第二，SCAN 在集群模式下可以在每个节点执行，但结果需要客户端自行合并，不存在全集群的全局游标。
第三，事务中的命令如果在执行时发现 key 不在当前节点，会直接报错，而不是重定向，所以事务和 Lua 脚本在多 key 场景下要格外小心，尽量把相关 key 聚合到同一个 slot。
第四，集群模式下分布式锁的语义需要重新考虑。如果在 Master 上获取了锁，Master 还没同步到 Slave 就宕机了，锁会丢失。这就要引入 RedLock 这样跨多个独立节点的方案，或者接受小概率的锁丢失，把业务做好幂等兜底。这些权衡思路，不是背命令能得来的，而是要理解 Redis 集群架构的复制模型和命令分发逻辑之后才能做出合理决策。
总结我的个人体会
最后说点掏心窝的话。Redis 命令看起来简单，但真正拉开开发水平差距的，往往就是这些细节。比如 EEXPIRE 与 SET 的过期时间覆盖问题、DEL 与 UNLINK 的阻塞差异、BLPOP 和轮询的效率鸿沟，每一处都是血泪教训换来的。我写过很多年代码，Redis 命令从没背过完整的文档，而是把每个命令放到具体的业务场景里反复砸摸它为什么这么设计，久而久之就有了肌肉记忆。
如果你现在正准备面试，不要只背命令的语法，试着问自己三个问题：这个命令的底层数据结构是什么？这个命令在单线程模型下会不会阻塞？这个命令在集群模式下有什么限制？能把这三个问题答清楚，Redis 命令这块基本就稳了。
如果你已经在排查线上问题，建议从 INFO commandstats、SLOWLOG 和 TTL 这三把钥匙入手，大多数命令层面的问题都能顺着线索摸到根因。记住，命令本身没有好坏，用对场景才是王道。
