记一个redis的常遇见见问题
2014-09-23 17:14
197 查看
当使用redis的set命令去覆盖带过期时间的key时,该key值原来的过期时间将被覆盖(即变为永久的),
也就是set命令不是是简单的覆盖已存在key的值,还会覆盖过期时间,如incr等单纯改变值的操作不同,必须区分开。
===============================转载资料
为给定 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时间复杂度:O(1)返回值:
设置成功返回 1 。
当 key 不存在或者不能为
key 设置生存时间时(比如在低于 2.1.3 版本的 Redis 中你尝试更新
key 的生存时间),返回
0 。
也就是set命令不是是简单的覆盖已存在key的值,还会覆盖过期时间,如incr等单纯改变值的操作不同,必须区分开。
===============================转载资料
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时间复杂度:O(1)返回值:
设置成功返回 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
相关文章推荐
- 遇见的又一个新问题,关于显示文章条目的时候,显示宽度的处理
- 在最近做一个高级查询时遇见的问题,javascript在动态的form里使用会出现问题
- VC http通信Get遇见的一个小问题
- 基于redis(key分段,避免一个key过大) 和db实现的 布隆过滤器(解决hash碰撞问题)
- 基于redis(key分段,避免一个key过大) 和db实现的 布隆过滤器(解决hash碰撞问题)
- [NS]运行行两年了,碰到一个没遇见的问题!
- 今天碰到的一个关于redis的问题
- 晒CSDN博客编辑时遇见的一个小问题!求大神解释!
- 接入 OppoSDK时遇见的一个问题
- 【标题党】记一个关于Redis-4.0.1版本下zslGetElementByRank函数的诡异问题
- 遇见一个不大不小的问题——计算机硬件问题
- redis的一个set问题的思考
- redis安装的一个问题
- 如何让滚动条消失,且页面可以正常滚动(解决写选项卡时可能遇见的一个问题)
- NOSQL练习 – 用 MONGODB 和 REDIS 解决一个现实问题
- 在最近做一个高级查询时遇见的问题(javascript日历控件)
- 自定义Adapter(一般继承自BaseAdapter)时遇见的一个小问题
- nginx+tomcat反向代理下使用tomcat-redis-session-manager进行session共享中值得注意的一个问题
- 基于redis(key分段,避免一个key过大) 和db实现的 布隆过滤器(解决hash碰撞问题)
- Redis 一个很诡异的问题(部署)