赞
踩
命令 | 说明 | 备注 |
---|---|---|
persist key | 持久化 key,取消超时时间 | 移除 key 的超时时间 |
ttl key | 査看 key 的超时时间 | 以秒计算,-1 代表没有超时时间,如果不存在 key 或者 key 已经超时则为 -2 |
expire key seconds | 设置超时时间戳 | 以秒为单位 |
expireat key timestamp | 设置超时时间点 | 用 uninx 时间戳确定 |
pptl key milliseconds | 查看key的超时时间戳 | 用亳秒计算 |
pexpire key | 设置键值超时的时间 | 以亳秒为单位 |
Pexpireat key stamptimes | 设置超时时间点 | 以亳秒为单位的 uninx 时间戳 |
一般而言,和 Java 虚拟机一样,当内存不足时 Redis 会触发自动垃圾回收的机制,而程序员可以通过 System.gc() 去建议 Java 虚拟机回收内存垃圾,它将“可能”(注意,System.gc() 并不一定会触发 JVM 去执行回收,它仅仅是建议 JVM 做回收)触发一次 Java 虚拟机的回收机制,但是如果这样做可能导致 Java 虚拟机在回收大量的内存空间的同时,引发性能低下的情况。
对于 Redis 而言,del 命令可以删除一些键值对,所以 Redis 比 Java 虚拟机更灵活,允许删除一部分的键值对。与此同时,当内存运行空间满了之后,它还会按照回收机制去自动回收一些键值对,这和 Java 虚拟机又有相似之处,但是当垃圾进行回收的时候,又有可能执行回收而引发系统停顿,因此选择适当的回收机制和时间将有利于系统性能的提高,这是我们需要去学习的。
这里有一个问题需要讨论:如果 key 超时了,Redis 会回收 key 的存储空间吗?
答案是不会。:Redis 的 key 超时不会被其自动回收,它只会标识哪些键值对超时了。
这样做的一个好处在于,如果一个很大的键值对超时,比如一个列表或者哈希结构,存在数以百万个元素,要对其回收需要很长的时间。如果采用超时回收,则可能产生停顿。坏处也很明显,这些超时的键值对会浪费比较多的空间。
Redis 提供两种方式回收这些超时键值对,它们是定时回收和惰性回收。
定时回收可以完全回收那些超时的键值对,但是缺点也很明显,如果这些键值对比较多,则 Redis 需要运行较长的时间,从而导致停顿。所以系统设计者一般会选择在没有业务发生的时刻触发 Redis 的定时回收,以便清理超时的键值对。
对于惰性回收而言,它的优势是可以指定回收超时的键值对,它的缺点是要执行一个莫名其妙的 get 操作,或者在某些时候,我们也难以判断哪些键值对已经超时。
无论是定时回收还是惰性回收,都要依据自身的特点去定制策略,如果一个键值对,存储的是数以千万的数据,使用 expire 命令使其到达一个时间超时,然后用 get 命令访问触发其回收,显然会付出停顿代价,这是现实中需要考虑的。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。