本文已收录于专栏
《Redis精通系列》
上千人点赞收藏,全套Redis学习资料,大厂必备技能!
目录
1、简介
2、过期策略
2.1 主动删除
2.2 被动删除
3、如何正确的设置key的过期时间
4、从节点存在的问题
1、简介
Redis的数据结构均可以通过EXPIRE key seconds 的方式设置key的过期时间(TTL)。我们也习惯的认为Redis的key过期时间到了,就会自动删除,显然这种想法并不正确。Redis的设计考虑到性能/内存等综合因素,设计了一套过期策略。
2、过期策略
Redis key过期删除有两种方式
主动删除
被动删除
2.1 主动删除
当key被访问的时候,先校验key是否过期,如果过期了则主动删除。
2.2 被动删除
Redis服务器定时随机的测试key的过期时间,如果过期了则被动删除。被动删除的存在必不可少,因为存在一些过期且永久不在访问的key,如果都依赖主动删除,那么它们将会永久占用内存。
Redis为了保证提供高性能服务,被动删除过期的key,采用了贪心策略/概率算法,默认每隔10秒扫描一次,具体策略如下:
从过期字典(设置了过期时间的key的集合)中随机选择20个key,检查其是否过期
删除其中已经过期的key
如果删除的过期key数量大于25%,则重复步骤1
3、如何正确的设置key的过期时间
开发在设计Redis缓存架构时,一定要注意要尽可能的避免(禁止)将大量的key设置为同一过期时间,因为结合2.2被动删除可知,Redis被动删除过期key时,会导致服务短暂的不可用;如果存在大量key同时过期,这会导致被动删除key的三个步骤循环多次,从而导致Redis服务出现卡顿情况,这种情况在大型流量项目是无法接收的。
因此为了避免这种情况出现,一定要将一些允许过期时间不需要非常精确的key,设置较为随机的过期时间,这样就可以将卡顿时间缩小。
4、从节点存在的问题
在主从模式下,Redis是AP架构,它具有高可用性,但是无法保证主从节点的强一致性。在Redis主从架构中,从节点不会直接发生数据的写入,过期key删除也不会在从节点直接发生,它只能被动地依靠主从同步来完成这一步骤。
当主节点中key到期时,会在AOF文件中增加DEL指令,在这个指令未同步到从节点这段时间内,从节点中的key仍然是未删除的。只有当指令同步过来之后,从节点才会删除这个key。通常情况下,这并不带来什么太大的问题,但是确实存在主从数据不一致的情况。