Redis数据过期时间及删除策略

Redis数据过期时间及删除策略

Redis数据设置过期时间

EXPIRE <KEY> <seconds> : 设置KEY有效期为seconds秒， 单位精度 ：秒
PEXPIRE <KEY> <seconds> : 设置KEY有效期为seconds毫秒， 单位精度：毫秒
EXPIREAT <KEY> <timestamp> :  设置KEY到UNIX时间戳timestamp时间点过期 单位精度：秒
PEXPIREAT <KEY> <timestamp> : 设置KEY到UNIX时间戳timestamp时间点过期 单位精度：毫秒
TTL <KEY> : 查看KEY剩余有效期时间 单位精度 ： 秒
PTTL <KEY> : 查看KEY剩余有效期时间 单位精度 ： 毫秒
PERSIST <KEY> : 移除KEY的过期时间
    
    
 	底层原理：
    	虽然有多种不同的单位和不同形式设置KEY的过期时间，但是实际上 EXPIRE、PEXPIRE、EXPIREAT底层都是使用PEXPIREAT命令来实现的。
    	EXPIRE ----> PEXPIRE ----> PEXPIREAT
    	PEXPIRE ----> PEXPIREAT
    	EXPIREAT ----> PEXPIREAT
    
    	当为某个KEY设置过期时间后，Redis会将设置的过期时间保存在Redis库结构中expires字典中，这个字典被成为过期字典：
    	typedef struct redisDb {
    		//....
    	   	//....
    		dict *expires;
            //....
		}redisDb;

Redis过期键删除策略

目前业界常用的过期删除策略有：
    
    定时删除策略 ： 在设置键的过期同时，创建一个定时器（Timer），让定时器在键的过期时间来临时，立即执行对键				      的删除擦欧洲哦。定时删除策略对内存是最友好的：通过使用定时器，定时删除策略可以保证过期键					会尽可能快地被删除，并释放过期键所占用的内存；但另一方面，定时删除策略的缺点是，他对CPU				   是最不友好的：在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU时间，在				  内存不紧张但是CPU时间非常紧张的情况下，将CPU时间用在删除和当前任务无关的过期键上，无疑				  会对服务器的响应时间和吞吐量造成影响
    
    惰性删除策略 ： 放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话就删除该				  键；如果没有过期就返回该键；惰性删除策略对CPU时间来说是最友好的：程序只会在取出键时才对键				 进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行；惰性删除策略的缺点是，				   它对内存是最不友好的：如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键				 不被删除，它所占用的内存就不会释放；
    
	定期删除策略 ： 每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要				  检查多少个数据库，则由算法决定。定时删除占用太多CPU时间，影响服务器的响应时间和吞吐					 量；惰性删除浪费太多内存，有内存泄漏的危险。定期删除策略是前两种策略的一种整合和折中：
				 定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删				   除操作对CPU时间的影响；通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的内存				  浪费；定期删除策略的难点是确定删除操作执行的时长和频率。

    
	其中定时、定期策略为主动删除策略，惰性删除为被动删除策略
    
    
上面三种策略对Redis影响：
    
    定时删除：
    	如果某时刻正有大量的命令请求在等待服务器处理，并且服务器当前不缺少内存。那么服务器应该优先将CPU时间			用在处理客户端请求上面，而不是用在删除过期键上面。除此之外，创建一个定时器需要用到Redis服务器中的时		间事件，而当前Redis时间事件底层使用的是无序列表，查找一个事件的时间复杂度是 O(N),并不能高效处理大		  量时间事件。因此，要让Redis创建大量定时器来实现删除策略，目前并不现实。
    
    惰性删除：
    	如果数据库中有非常多的键，而这些过期键恰好没有被访问到的话，那么它们也许永远不会被删除（除非手动执行		  FlushDB），我们甚至可以将这种情况视为是一种内存泄漏 （无用的过期数据占用了大量内存而服务器却不释放			这些内存），这对Redis来说肯定不是一个好消息。
    
    定期删除：
    	定期删除的难点是确定删除操作的时长和频率：如果删除操作执行太频繁或执行时间太长，定期删除就会退化成定		  时删除策略，以至于将CPU时间过多的消耗在删除键上；如歌删除操作执行太少或执行时间太短，定期删除又会和		 惰性策略一样造成内存浪费，
    
    
   
    Redis服务器实际使用的是惰性删除和定期删除两种策略：通过配合这两种策略，服务器可以很好的使用CPU时间和避免内存浪费之间取得平衡。Redis中的惰性删除是通过访问键是对键有一个过期判断；Redis中的定期删除是通过定时任务在规定时间内每次从一定数量的数据库中取出一定数量的随机键进行检查并删除其中的过期键。每次定时任务到时间后都会记录下当前处理的进度，下次定时任务会接着上次的进度进行处理。
    
    TIP：
    	memcached只是用了惰性删除，而redis同时使用了惰性删除与定期删除，这也是二者的一个不同点（可以看做		是redis优于memcached的一点）

RDB、AOF、主从复制对过期键的处理

RDB :
	当生成新的RDB文件时，如果某个键已经过期则该键不会被写到RDB文件当中。因此，过期键不会对新的RDB文件造成影响。当Redis载入RDB文件时，以主服务器运行时在载入RDB时会对键进行检查，过期的键会被忽略。以从服务器运行时，不论键是否过期都会被载入数据库，不过，因为主从服务器进行数据同步时，从服务器数据库就被清空了，所以过期键对载入RDB不会造成影响。
 
        
AOF ：
    AOF文件写入时当某个键已经过期但是还没有被惰性删除或者定期删除时，该键不会对AOF产生任何影响，当被被惰性删除或者定期删除后会向AOF中追加一条DEL命令来显式记录该键被删除。AOF重写时会对键进行校验过期的键不会被写到AOF中。
      
主从复制：
        当服务器运行在复制模式下时，从服务器过期删除由主服务器控制：当主服务器删除一个过期键后会显式的向从服务器发送一个DEL命令。当从服务器接受到客户端读请求时，即使键过期也不会删除而是向客户端返回结果，这一点一定要注意，从服务器只有接到主服务器的DEL命令时才会删除过期键。
        
        
     TIP：
        使用主从复制时一定要注意从服务器可能存在脏数据的情况。