当前位置：首页 > 问答 > 正文

Redis表命令怎么灵活用起来，实战中那些你可能没注意的细节和技巧分享

说到Redis，很多人觉得它就是简单的set、get，顶多再用个expire设置过期时间，但在实战里，想把Redis这把“瑞士军刀”用得顺手，光知道这几个基础命令可不够，里面有不少细节和技巧，用好了能让你事半功倍,用不好可能就是埋坑。

SET命令不只是SET，它是个“多面手”

你以为SET key value就完了？其实它有一堆非常有用的可选参数,这些才是精髓。

NX和XX：分布式锁的基石
- SET key value NX：只有这个key不存在时，才设置它，这个就是实现简单分布式锁最核心的命令，多个服务同时要处理一个任务，你可以用SET lock:task_123 owner_id NX来抢锁，只有一个服务能设置成功，抢到锁，来源：Redis官方文档中关于SET命令的选项说明。
- SET key value XX：正好相反，只有key已经存在时，才更新它的值，这个可以用在比如“只能更新，不能创建”的场景。
EX/PX：过期时间应该和设置值“绑定”在一起
- 很多人习惯先SET，再EXPIRE，这不是原子操作！如果在SET之后、EXPIRE之前你的应用崩溃了，那么这个key就永远不会过期，成了“僵尸key”,会造成内存泄漏。
- 正确的做法是直接用SET key value EX seconds（或PX milliseconds），这是一个原子操作，保证值和过期时间被同时设置，来源：同样是Redis官方文档,强调了原子性的重要性。
GETSET的妙用：获取并更新
- 虽然GETSET命令有点老，但在一些场景下很巧妙，做一个简单的计数器，你想知道上一次的数值是多少，同时把它更新为新值，用GETSET counter new_value就能一次性搞定，避免了先GET再SET的两次网络开销和非原子性问题。

键过期（Expiration）里的“坑”与“宝”

过期是Redis管理内存的神器,但它的行为方式你得门儿清。

过期精度不是实时的：Redis的过期删除有两种策略：被动（当访问一个key时发现它过期了，才删除）和主动（定期随机抽查一些key删除），这意味着，一个key即使到了过期时间，也可能不会立刻被清除，而是等到下次被访问或轮到主动检查时才会被删掉，你的应用逻辑不能完全依赖“时间一到必然消失”这个假设。
DEL命令不会触发过期事件：如果你手动用DEL删除了一个本来已经设置了过期时间的key，Redis会直接删除它，而不会再去触发什么过期逻辑，这点在监听键空间通知（Keyspace Notifications）时要特别注意。
持久化时的过期处理：RDB持久化时，过期的key不会被保存到RDB文件，当从RDB文件恢复时，如果主服务器模式运行，它会认为这些key是有效的，但会再次检查过期时间并删除已过期的，AOF持久化时，当一个key过期被删除后，AOF文件会追加一条DEL命令，来源：Redis持久化文档中关于过期键的处理部分。

批量操作是性能提升的“快车道”

网络往返次数（Round-Trips）是影响Redis性能的关键因素之一。

MSET/MGET：一次性设置或获取多个key的值，能极大减少网络通信次数，比如要获取用户首页需要的10个信息，用一次MGET比用10次GET快得多。
Pipeline（管道）：当你的操作不仅仅是简单的MGET/MSET，而是包含各种不同类型的命令序列时，Pipeline就派上用场了，它能把多个命令打包，一次发送给Redis服务器，服务器按顺序处理完后再一次性返回所有结果，这避免了“发一个命令，等一个回复”的串行等待，在高延迟网络下效果尤其明显，需要注意的是，Pipeline中的命令并不是原子性的，它们只是被批量执行了，来源：Redis官方文档中关于Pipelining的章节。
小心KEYS命令：KEYS pattern这个命令会扫描整个数据库的所有键，在生产环境下，如果数据库很大，这个命令会阻塞Redis服务器，导致所有其他请求卡住，是绝对禁止使用的，它的替代品是SCAN命令。SCAN通过游标方式增量式迭代，不会长时间阻塞服务器，虽然可能会有少量重复,但对于生产环境是安全的。

数据类型的选择，比你想的更重要

选对了数据结构，能让你写代码更轻松,性能也更好。

不要什么都用String：比如要存储一个用户的多个信息（姓名、年龄、城市），很多人会想到用user:123:name, user:123:age这样的多个String键，这很浪费键资源，管理也不方便，应该使用Hash（哈希）：HMSET user:123 name "张三" age 30 city "北京"，这样只有一个键，而且可以单独操作某个字段（HGET），也可以一次性获取所有（HGETALL）。
List vs Set vs ZSet（有序集合）：
- List适合消息队列（LPUSH/RPOP）、最新列表（LTRIM）。
- Set适合存储不重复的集合，比如好友列表、标签,支持交集并集等操作。
- ZSet是带分数的Set，适合排行榜、延迟队列等，比如ZADD leaderboard 100 "playerA"，然后可以用ZREVRANGE来取topN，来源：Redis数据类型的介绍文档,强调了每种类型的适用场景。

几个零散但实用的小技巧

INCR/DECR是原子的：做计数器时，放心用INCR，不用担心并发问题。INCRBY可以按指定步长增加。
TYPE和OBJECT命令用于调试：当你不太确定一个key的类型或者想看看它的内部编码时（比如这个String是embstr还是raw编码），可以用TYPE key和OBJECT ENCODING key来探查,对于排查问题很有帮助。
给Key设计一个好的命名空间：用冒号分隔是一种常见的约定，比如业务:对象:id:字段，order:1001:status，user:session:abc123，这样清晰易懂，也便于用SCAN模式匹配。