ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

Redis 命令速查

2022-02-09 01:03:55  阅读:162  来源: 互联网

标签:127.0 6379 0.1 Redis 命令 实例 key integer 速查


1、Key(键)

DEL

DEL key [key ...]:删除给定的一个或多个key。不存在的key会被忽略。

可用版本:>=1.0.0

时间复杂度:O(N),N为被删除的key数量。

  • 删除单个字符串类型的key,时间复杂度为O(1)。
  • 删除单个列表、集合、有序集合或哈希表类型的key,时间复杂度为O(M),M为以上数据结构内的元素数量。

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

#删除单个key
127.0.0.1:6379> SET name redis
OK
127.0.0.1:6379> DEL name
(integer) 1

#删除一个不存在的key
127.0.0.1:6379> EXISTS age
(integer) 0
127.0.0.1:6379> DEL age
(integer) 0

#同时删除多个key
127.0.0.1:6379> SET name1 Python
OK
127.0.0.1:6379> SET name2 Java
OK
127.0.0.1:6379> SET name3 C++
OK
127.0.0.1:6379> DEL name1 name2 name3
(integer) 3

DUMP

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

序列化生成的值有一下几个特点:

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

序列化的值不包括任何生存的时间信息。

可用版本: >=2.6.0

时间复杂度:查找给定键的复杂度为O(1),对键进行序列化的复杂度为O(N*M),其中N是构成key的Redis对象的数量,而M则是这些对象的平均大小。

返回值:如果key不存在,返回nil。反之返回序列化之后的值。

127.0.0.1:6379> DUMP msg
"\x00\x0chello,world!\x06\x00\x13\xe5\xba\x88\xdcG\xca\xcd"
127.0.0.1:6379> DUMP hh
(nil)

EXISTS

EXISTS key:检查给定的key是否存在。

可用版本:>=1.0.0

时间复杂度:O(1)

返回值:若key存在,返回1,否则返回0。

127.0.0.1:6379> SET data zz
OK
127.0.0.1:6379> EXISTS data
(integer) 1
127.0.0.1:6379> DEL data
(integer) 1
127.0.0.1:6379> EXISTS data
(integer) 0

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的生存时间和改名前一样。

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

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

可用版本:>= 1.0.0

时间复杂度:O(1)

返回值:设置成功返回1。当key不存在或者不能为key设置生存时间时(比如在低于2.1.3版本的Redis中你尝试更新key的生存时间),返回0。

127.0.0.1:6379> SET cache_page www.baidu.com
OK
127.0.0.1:6379> EXPIRE cache_page 30
(integer) 1
127.0.0.1:6379> TTL cache_page
(integer) 24
127.0.0.1:6379> EXPIRE cache_page 3000
(integer) 1
127.0.0.1:6379> TTL cache_page
(integer) 2997

模式:导航会话

假设你有一项web服务,打算根据用户最近访问的N个页面来进行物品推荐,并且假设用户停止阅览超过60秒,那么就清空阅览记录(为了减少物品推荐的计算量,并且保持推荐物的新鲜度)。

这些最近访问的页面记录,我们称之为【导航会话】(Navigation session),可以用INCR和RPUSH命令在Redis中实现它:每当用户阅览一个网页的时候,执行以下代码:

MULTI
    RPUSH pagewviews.user:<userid> http://.....
    EXPIRE pagewviews.user:<userid> 60
EXEC

如果用户停止阅览超过60秒,那么它的会话就会被清空,当用户重新打开阅览的时候,系统又会重新记录导航会话,继续执行物品推荐。

EXPIREAT

EXPIREAT key timestamp:EXPIREAT的作用和EXPIRE类似,都用于为key设置生存时间。不同在于EXPIREAT命令接受的时间参数是UNIX时间戳(unix timestamp)。

可以版本:>=1.2.0

时间复杂度:O(1)

返回值:如果生存时间设置成功,返回1。当key不存在或没办法设置生存时间,返回0。

127.0.0.1:6379> SET url www.souhu.com
OK
127.0.0.1:6379> EXPIREAT url 1644336000
(integer) 1
127.0.0.1:6379> TTL url
(integer) 9538

KEYS

KEYS pattern:查询所以符合给定模式pattern的key.

  • KEYS *:匹配数据库中所以的key。
  • KEYS h?llo:匹配hello,hallo和hxllo等。
  • KEYS h*llo:匹配hllo和heeeello等。
  • KEY h[ae]llo:匹配hello和hallo,但不匹配hillo。

特殊符号用\隔开

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

可用版本:>= 1.0.0

时间复杂度:O(N),N为数据库中key的数量。

返回值:符合给定模式的key列表。

127.0.0.1:6379> MSET one 1 two 2 three 3 four 4	#批量设置4个key
OK
127.0.0.1:6379> KEYS *o*
1) "one"
2) "four"
3) "two"
127.0.0.1:6379> KEYS t??
1) "two"
127.0.0.1:6379> KEYS t[w]*
1) "two"
127.0.0.1:6379> KEYS *
1) "one"
2) "four"
3) "three"
4) "two"

MIGRATE

MIGRATE host port key destination-db timeout [COPY] [REPLACE]:将key原子性地从当前实例传送到目标实例的指定数据库上,一旦传送成功,key保证会出现再目标实例上,而当前实例上的key会被删除。

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

命令的内部实现是这样的:它在当前实例对给定key执行DUMP命令,将它序列化,然后传送到目标实例,目标实例在使用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

时间复杂度:key数据在两个实例之间传输的复杂度为O(N)。

这个命令在源实例上世纪执行DUMP命令和DEL命令,在目标实例执行RESTORE命令,查看以上命令的文档可以看到详细的复杂度说明。

返回值:迁移成功时返回OK,否则返回相应的错误。

示例

#先启动两个Redis实例,一个使用默认的6379端口,一个使用7777端口。
$ ./redis-server &
[1] 3557

...

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

...

#然后用客户端连上6379端口的实例,设置一个键,然后将它迁移到7777端口的实例上。
$ ./redis-cli

redis 127.0.0.1:6379> flushdb
OK

redis 127.0.0.1:6379> SET greeting "Hello from 6379 instance"
OK

redis 127.0.0.1:6379> MIGRATE 127.0.0.1 7777 greeting 0 1000
OK

redis 127.0.0.1:6379> EXISTS greeting                           # 迁移成功后 key 被删除
(integer) 0

#使用另一个客户端,查看7777端口上的实例。
$ ./redis-cli -p 7777

redis 127.0.0.1:7777> GET greeting
"Hello from 6379 instance"

持续更新。。。 。。。

标签:127.0,6379,0.1,Redis,命令,实例,key,integer,速查
来源: https://www.cnblogs.com/remixnameless/p/15873443.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有