Redis 经常使用命令详解

key 经常使用的命令

跟 key 相关的命令一共有 24 种,这里只介绍经常使用的。想查看所有命令请参考官网redis

删除 key

语法
DEL key1 [key2 ...]code

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

说明
不存在的 key 会被忽略。(删除 key 后,对应的 value 也会被删除)同步

查看 key 是否存在

语法
EXISTS key1 [key2 ...]io

返回值ast

  • 指定单个key时,返回1或0
  • 指定多个key时,返回现有key的总数
  • 多个 key 相同时,会重复计数。例如 EXISTS somekey 返回1,EXISTS somekey somekey 返回2

说明
从Redis 3.0.3开始,能够指定多个keyclass

给 key 设置生存时间

Redis 中,带有生存时间的 key 被称为 volatile (易丢失)。语法

key 过时时(生存时间为 0 ),它会被自动删除。command

语法
EXPIRE key1 秒方法

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

说明
有些命令会对 key 的生存时间产生影响

  • DEL 命令会删除 keykey 不存在了,生存时间也会被移除
  • PERSIST 命令能够在不删除 key 的状况下,移除 key 的生存时间,让 key 从新成为一个持久的key 。
  • SETGETSET 命令 能够覆写 key生存时间

若是一个命令只是修改 key 的值而不是用一个新的 key 值来代替它的话,那么生存时间不会被改变。

例如,如下操做都不会修改 key 自己的生存时间。

  • 对一个 key 执行 INCR 命令
  • 对一个列表进行 LPUSH 命令
  • 或者对一个哈希表执行 HSET 命令

若是使用 RENAME 命令对一个 key 进行更名,那么更名后的 key 的生存时间和更名前同样。这句话也适用于如下特殊状况。

假若有个两个带生存时间的 key。

  • 第一个key:名称为 name1 生存时间为 10秒
  • 第二个key :名称为 name2 生存时间为 5秒

如今使用 RENAME 命令将 name1 更名为 name2。因为 Redis 不容许存在重名的 key,所以 name2 会先被删除,而后再将 name1 更名为 name2,值得注意是,更名后的name1生存时间仍是10秒!!!

过时精度

在Redis 2.4中,过时精确存在 0~1秒的时间偏差。

从Redis 2.6开始,过时精确偏差缩小为0~1毫秒。

Redis 2.1.3 以前

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

Redis 如何过时 key

Redis密钥使用两种方式过时 key

  • 被动式
  • 主动式

被动式
当客户端访问 key 时,若是 key 设置了过时时间,会检查过时时间,若是发现超时,会作超时处理(删掉key)。

固然,只依赖被动式还不够,由于有过时的 key 可能永远不会被访问,所以Redis会按期主动清理。

主动式
Redis 默认每秒执行10次如下操做

  1. 从一组相关联的带生存时间的 key中,随机抽取20个key做为样本。
  2. 删除样本中全部已过时的key。
  3. 若是样本中超过25%的key已过时,从步骤1从新开始。

过时与持久化

Key 的过时时间使用 Unix 时间戳存储(从 Redis 2.6 开始以毫秒为单位)。
当你使用 EXPIRE命令给某个 key 设置存活时间为 60 秒,redis 会把当前时间加 60 秒做为该 key 的过时时间。这意味着即便 Redis 实例关机,key 的时间也是一直在流逝。

要想处理好 key 的过时的工做,你的计算机时间必须稳定准确!若是你将 RDB 文件在两台时间不一样步的电脑间同步,可能会发生一些有趣的事情,好比全部的 key 在装载时就会过时

即便正在运行的 redis 实例也会检查计算机的时钟,例如若是你设置了一个 key 的存活时间是1000秒,在这瞬间你设置你的计算机时间为将来的1000秒,这时 key 会当即失效,而不是等1000秒以后。

在复制 AOF 文件时如何处理过时

为了得到正确的行为而不牺牲一致性,当一个 key 过时,删除该 keyDEL 命令将随着 AOF 文件,发送给全部的 slaves。在 master 实例中,这种方法是集中的,而且不存在一致性错误的机会。

slaves 链接到 master 时,不会独自过时 key,会等到 master 传输 DEL 命令,在这期间,过时数据依然在 slave 里面。

相关文章
相关标签/搜索