Redis学习记录之命令KEY(五)

ゞ浴缸里的玫瑰 2022-08-19 11:18 175阅读 0赞

**1、DEL**  
DEL key \[key …\]

删除给定的一个或多个 key 。  
不存在的 key 会被忽略。

可用版本：  
1.0.0及以上

返回值：  
被删除 key 的数量。

1)删除单个 key

redis> SET name huangz  
OK

redis> DEL name  
(integer) 1

2)删除一个不存在的 key

redis> EXISTS phone  
(integer) 0

redis> DEL phone \# 失败，没有 key 被删除  
(integer) 0

3)同时删除多个 key

redis> SET name “redis”  
OK

redis> SET type “key-value store”  
OK

redis> SET website “redis.com”  
OK

redis> DEL name type website  
(integer) 3  
**2、DUMP（个人认为：这是内部命令，一般没什么用，主要是对比RDB里的序列化结果。）**  
DUMP key

序列化给定 key ，并返回被序列化的值，使用 RESTORE 命令可以将这个值反序列化为 Redis 键。

序列化生成的值有以下几个特点：

它带有 64 位的校验和，用于检测错误， RESTORE 在进行反序列化之前会先检查校验和。  
值的编码格式和 RDB 文件保持一致。  
RDB 版本会被编码在序列化值当中，如果因为 Redis 的版本不同造成 RDB 格式不兼容，那么 Redis 会拒绝对这个值进行反序列化操作。  
序列化的值不包括任何生存时间信息。

可用版本：  
2.6.0及以上

返回值：  
如果 key 不存在，那么返回 nil 。  
否则，返回序列化之后的值。  
redis> SET greeting “hello, dumping world!”  
OK

redis> DUMP greeting  
“\\x00\\x15hello, dumping world!\\x06\\x00E\\xa0Z\\x82\\xd8r\\xc1\\xde”

redis> DUMP not-exists-key  
(nil)  
**3、EXISTS**  
EXISTS key

检查给定 key 是否存在。

可用版本：  
1.0.0及以上

返回值：  
若 key 存在，返回 1 ，否则返回 0 。  
redis> SET db “redis”  
OK

redis> EXISTS db  
(integer) 1

redis> DEL db  
(integer) 1

redis> EXISTS db  
(integer) 0  
**4、EXPIRE**  
EXPIRE key seconds

为给定 key 设置生存时间，当 key 过期时(生存时间为 0 )，它会被自动删除。

在 Redis 中，带有生存时间的 key 被称为『易失的』(volatile)。

生存时间可以通过使用 DEL 命令来删除整个 key 来移除，或者被 SET 和 GETSET 命令覆写(overwrite)，这意味着，如果一个命令只是修改(alter)一个带生存时间的 key 的值而不是用一个新的 key 值来代替(replace)它的话，那么生存时间不会被改变。

比如说，对一个 key 执行 INCR 命令，对一个列表进行 LPUSH 命令，或者对一个哈希表执行 HSET 命令，这类操作都不会修改 key 本身的生存时间。

另一方面，如果使用 RENAME 对一个 key 进行改名，那么改名后的 key 的生存时间和改名前一样。

RENAME 命令的另一种可能是，尝试将一个带生存时间的 key 改名成另一个带生存时间的 another\_key ，这时旧的 another\_key (以及它的生存时间)会被删除，然后旧的 key 会改名为 another\_key ，因此，新的 another\_key 的生存时间也和原本的 key 一样。

使用 PERSIST 命令可以在不删除 key 的情况下，移除 key 的生存时间，让 key 重新成为一个『持久的』(persistent) key 。

更新生存时间

可以对一个已经带有生存时间的 key 执行 EXPIRE 命令，新指定的生存时间会取代旧的生存时间。

过期时间的精确度

在 Redis 2.4 版本中，过期时间的延迟在 1 秒钟之内 —— 也即是，就算 key 已经过期，但它还是可能在过期之后一秒钟之内被访问到，而在新的 Redis 2.6 版本中，延迟被降低到 1 毫秒之内。

Redis 2.1.3 之前的不同之处

在 Redis 2.1.3 之前的版本中，修改一个带有生存时间的 key 会导致整个 key 被删除，这一行为是受当时复制(replication)层的限制而作出的，现在这一限制已经被修复。

可用版本：  
1.0.0及以上

返回值：  
设置成功返回 1 。  
当 key 不存在或者不能为 key 设置生存时间时(比如在低于 2.1.3 版本的 Redis 中你尝试更新 key 的生存时间)，返回 0 。  
redis> SET cache\_page “www.google.com”  
OK

redis> EXPIRE cache\_page 30 \# 设置过期时间为 30 秒  
(integer) 1

redis> TTL cache\_page \# 查看剩余生存时间  
(integer) 23

redis> EXPIRE cache\_page 30000 \# 更新过期时间  
(integer) 1

redis> TTL cache\_page  
(integer) 29996

**5、EXPIREAT**  
EXPIREAT key timestamp

EXPIREAT 的作用和 EXPIRE 类似，都用于为 key 设置生存时间。

不同在于 EXPIREAT 命令接受的时间参数是 UNIX 时间戳(unix timestamp)。

可用版本：  
1.2.0及以上

返回值：  
如果生存时间设置成功，返回 1 。  
当 key 不存在或没办法设置生存时间，返回 0 。  
redis> SET cache www.google.com  
OK

redis> EXPIREAT cache 1355292000 \# 这个 key 将在 2012.12.12 过期  
(integer) 1

redis> TTL cache  
(integer) 45081860

**6、KEYS**  
KEYS pattern

查找所有符合给定模式 pattern 的 key 。

KEYS \* 匹配数据库中所有 key 。  
KEYS h?llo 匹配 hello ， hallo 和 hxllo 等。  
KEYS h\*llo 匹配 hllo 和 heeeeello 等。  
KEYS h\[ae\]llo 匹配 hello 和 hallo ，但不匹配 hillo 。  
特殊符号用 \\ 隔开

KEYS 的速度非常快，但在一个大的数据库中使用它仍然可能造成性能问题，如果你需要从一个数据集中查找特定的 key ，你最好还是用 Redis 的集合结构(set)来代替。  
可用版本：  
1.0.0及以上

返回值：  
符合给定模式的 key 列表。  
redis> MSET one 1 two 2 three 3 four 4 \# 一次设置 4 个 key  
OK

redis> KEYS *o*（此处是匹配所有含o的key：※o※）  
1) “four”  
2) “two”  
3) “one”

redis> KEYS t??  
1) “two”

redis> KEYS t\[w\]\*  
1) “two”

redis> KEYS \* \# 匹配数据库内所有 key  
1) “four”  
2) “three”  
3) “two”  
4) “one”  
**7、MIGRATE**  
MIGRATE host port key destination-db timeout \[COPY\] \[REPLACE\]

将 key 原子性地从当前实例传送到目标实例的指定数据库上，一旦传送成功， key 保证会出现在目标实例上，而当前实例上的 key 会被删除。

这个命令是一个原子操作，它在执行的时候会阻塞进行迁移的两个实例，直到以下任意结果发生：迁移成功，迁移失败，等待超时。

命令的内部实现是这样的：它在当前实例对给定 key 执行 DUMP 命令 ，将它序列化，然后传送到目标实例，目标实例再使用 RESTORE 对数据进行反序列化，并将反序列化所得的数据添加到数据库中；当前实例就像目标实例的客户端那样，只要看到 RESTORE 命令返回 OK ，它就会调用 DEL 删除自己数据库上的 key 。

timeout 参数以毫秒为格式，指定当前实例和目标实例进行沟通的最大间隔时间。这说明操作并不一定要在 timeout 毫秒内完成，只是说数据传送的时间不能超过这个 timeout 数。

MIGRATE 命令需要在给定的时间规定内完成 IO 操作。如果在传送数据时发生 IO 错误，或者达到了超时时间，那么命令会停止执行，并返回一个特殊的错误： IOERR 。

当 IOERR 出现时，有以下两种可能：

key 可能存在于两个实例  
key 可能只存在于当前实例  
唯一不可能发生的情况就是丢失 key ，因此，如果一个客户端执行 MIGRATE 命令，并且不幸遇上 IOERR 错误，那么这个客户端唯一要做的就是检查自己数据库上的 key 是否已经被正确地删除。

如果有其他错误发生，那么 MIGRATE 保证 key 只会出现在当前实例中。（当然，目标实例的给定数据库上可能有和 key 同名的键，不过这和 MIGRATE 命令没有关系）。

可选项：

COPY ：不移除源实例上的 key 。  
REPLACE ：替换目标实例上已存在的 key 。  
可用版本：  
2.6.0及以上

返回值：  
迁移成功时返回 OK ，否则返回相应的错误。  
示例  
先启动两个 Redis 实例，一个使用默认的 6379 端口，一个使用 7777 端口。

$ ./redis-server &  
\[1\] 3557

…

$ ./redis-server –port 7777 &  
\[2\] 3560

…  
然后用客户端连上 6379 端口的实例，设置一个键，然后将它迁移到 7777 端口的实例上：