Redis教程7-键(key)常用命令使用参考1
1.DEL
DEL key [key ...]
删除给定的一个或多个 key 。不存在的 key 会被忽略。
可用版本：>= 1.0.0
时间复杂度：
O(N)， N 为被删除的 key 的数量。
删除单个字符串类型的 key ，时间复杂度为O(1)。
删除单个列表、集合、有序集合或哈希表类型的 key ，时间复杂度为O(M)， M 为以上数据结构内的元素数量。
返回值：
被删除 key 的数量。
# 删除单个 key redis> SET name huangz OK redis> DEL name (integer) 1 # 删除一个不存在的 key redis> EXISTS phone (integer) 0 redis> DEL phone # 失败，没有 key 被删除 (integer) 0 # 同时删除多个 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
DUMP key
序列化给定 key ，并返回被序列化的值，使用 RESTORE 命令可以将这个值反序列化为 Redis 键。
序列化生成的值有以下几个特点：
- 它带有 64 位的校验和，用于检测错误， RESTORE 在进行反序列化之前会先检查校验和。
- 值的编码格式和 RDB 文件保持一致。
- RDB 版本会被编码在序列化值当中，如果因为 Redis 的版本不同造成 RDB 格式不兼容，那么 Redis 会拒绝对这个值进行反序列化操作。
序列化的值不包括任何生存时间信息。
可用版本：>= 2.6.0
时间复杂度：
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 // 序列化这个不存在的key (nil)
3.EXISTS
EXISTS key
检查给定 key 是否存在。
可用版本：>= 1.0.0
时间复杂度：O(1)
返回值：
若 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 ，这时旧的 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
时间复杂度：O(1)
返回值：
127.0.0.1:6379> set name redis666 // 设置name OK 127.0.0.1:6379> EXPIRE name 10 // 设置name过期时间10s (integer) 1 127.0.0.1:6379> ttl name // 查看剩余过期时间, 还有5s (integer) 5 127.0.0.1:6379> get name // 没过期, 还可以获取 "redis666" 127.0.0.1:6379> ttl name // 已经过期了 (integer) -2 127.0.0.1:6379> get name // 获取不到了 (nil) 127.0.0.1:6379> expire name 3000 // 重新修改过期时间, 但是name没了, 设置不成功 (integer) 0 127.0.0.1:6379> ttl name // 无法查到过期时间了 (integer) -2 127.0.0.1:6379> set age 30 // 设置age OK 127.0.0.1:6379> expire age 3000 // 过期时间为3000s (integer) 1 127.0.0.1:6379> ttl age // age的过期剩余时间 (integer) 2997 127.0.0.1:6379> ttl age // 还有2993s才过期 (integer) 2993 127.0.0.1:6379> expire age 5000 // 重新修改过期时间为5000s (integer) 1 127.0.0.1:6379> ttl age // (integer) 4998 127.0.0.1:6379> del age // 删除age (integer) 1 127.0.0.1:6379> get age // 已经删除, get不到age的值 (nil)
5.EXPIREAT
EXPIREAT key timestamp
EXPIREAT 的作用和 EXPIRE 类似，都用于为 key 设置生存时间。
不同在于 EXPIREAT 命令接受的时间参数是 UNIX 时间戳(unix timestamp)。
可用版本：>= 1.2.0
时间复杂度：O(1)
返回值：
127.0.0.1:6379> set name redis666 OK 127.0.0.1:6379> expireat name 1600409820 // 设置过期时间戳, 时间为2020-09-18 14:17:00 过期(此时为2020-09-18 14:16:00) (integer) 1 127.0.0.1:6379> get name // 立马获取可以获取到 "redis666" 127.0.0.1:6379> ttl name // 还有18s过期 (integer) 18 127.0.0.1:6379> ttl name // 还有5s过期 (integer) 5 127.0.0.1:6379> ttl name // 已经过期了 (integer) -2 127.0.0.1:6379> get name // 获取不到了, 被删除 (nil) 127.0.0.1:6379>
6.KEYS
KEYS pattern
查找所有符合给定模式 pattern 的 key 。
KEYS * 匹配数据库中所有 key (redis默认数据库是0)。
KEYS h?llo 匹配 hello ， hallo 和 hxllo 等。
KEYS h*llo 匹配 hllo 和 heeeeello 等。
特殊符号用 \ 隔开
KEYS 的速度非常快，但在一个大的数据库中使用它仍然可能造成性能问题，如果你需要从一个数据集中查找特定的 key ，你最好还是用 Redis 的集合结构(set)来代替。
可用版本：>= 1.0.0
时间复杂度：O(N)， N 为数据库中 key 的数量。
返回值：符合给定模式的 key 列表。
redis> MSET one 1 two 2 three 3 four 4 # 一次设置 4 个 key OK redis> KEYS *o* // 匹配包含o的key 1) "four" 2) "two" 3) "one" redis> KEYS t?? // 匹配t开头而且后面有两位的key 1) "two" redis> KEYS t[w]* // 匹配t开头, 第二位是w 后面还有一位的key 1) "two" redis> KEYS * # 匹配数据库内所有 key 1) "four" 2) "three" 3) "two" 4) "one"
7.MIGRATE
MIGRATE host port key destination-db timeout [COPY] [REPLACE] [KEYS key]
- host：目标Redis的IP地址
- port：目标Redis的端口
- key：Redis 3.0.6 后如果需要迁移多个键，此处为空字符串""
- destination-db：目标Redis的数据库索引, redis默认使用0数据库
- timeout：迁移的超时时间（单位为毫秒)
- COPY ：不移除源实例上的 key 。
- REPLACE ：替换目标实例上已存在的 key
- keys：如果要删除多个建，填写
keys, 例如 keys key1 key2 key3
将 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
时间复杂度：
$ redis-server.exe --port 7777
然后用客户端连上 7777端口的实例，在6379设置一个键，然后将它迁移到 7777 端口的实例上：
$ redis-cli.exe -p 7777 // 连接上端口为7777的redis 127.0.0.1:7777> ping PONG
如上, 已经连接上了本机另一个redis, 端口号为7777
但是很不幸, 执行的之后发现无论怎么执行, 都会报错, 如下
127.0.0.1:6379> keys * // 此时没有任何key (empty list or set) 127.0.0.1:6379> set name redis666888 // 设置key name OK 127.0.0.1:6379> keys * // 只存在一个name 1) "name" 127.0.0.1:6379> exists name // name存在 (integer) 1 127.0.0.1:6379> get name // 可以获取到name的值 "redis666888"
如上, 设置了name属性, 迁移name如下,
127.0.0.1:6379> migrate 127.0.0.1 7777 name 0 100 // 指定迁移name, 不成功 (error) ERR Target instance replied with error: ERR DUMP payload version or checksum are wrong 127.0.0.1:6379> migrate 127.0.0.1 7777 "" 0 100 keys name // 使用keys的方式迁移name, 也不成功 (error) ERR Target instance replied with error: ERR DUMP payload version or checksum are wrong
怀疑是版本问题, 所以重新启动一个同样版本的redis, 依然进入版本Redis-x64-5.0.9的目录下, 重新启动一个redis, 6379已经启动了, 重新再启动 一个redis指定端口号7777
$ redis-server.exe --port 7777
连接端口7777的redis, 因为默认使用db 0的数据库, 为了测试方便, 我们是用db 1的数据库
$ redis-cli.exe -p 7777 127.0.0.1:7777> ping PONG 127.0.0.1:7777> select 1 // 改为使用db 1的数据库 OK 127.0.0.1:7777[1]> ping PONG 127.0.0.1:7777[1]>
此时再此在6379中执行name的迁移, 为了测试[KEYS Key]的使用, 先多添加几个key, 如下
127.0.0.1:6379> set age 66 OK 127.0.0.1:6379> set tel 110 OK 127.0.0.1:6379> keys * // 此时6379中一个3个key 1) "tel" 2) "age" 3) "name" 127.0.0.1:6379> migrate 127.0.0.1 7777 name 1 100 // 时间超时为100ms, 迁移到端口为7777的db为1的redis数据库中 OK 127.0.0.1:6379> keys * // name已经没了 1) "tel" 2) "age" 127.0.0.1:6379> migrate 127.0.0.1 7777 "" 1 100 keys age tel // 使用keys key的命令, 一次迁移多个key, age和tel OK 127.0.0.1:6379> keys * // age 和 tel也没了 (empty list or set) 127.0.0.1:6379>
此时再去7777端口查看db 1中的key, 是否多了name, age 和 tel
127.0.0.1:7777[1]> keys * 1) "tel" 2) "name" 3) "age" 127.0.0.1:7777[1]> get tel "110" 127.0.0.1:7777[1]> get name "redis666888" 127.0.0.1:7777[1]> get age "66" 127.0.0.1:7777[1]>
如上, name和age, tel 分别使用两种方式从6379中迁移到了7777中, 刚才的错误果然是因为版本好的问题导致的......
