RDB对过期键的处理
生成RDB文件
在RDB
中是以快照的形式获取内存中某一时间点的数据副本,在创建RDB
文件的时候可以通过save
和bgsave
命令执行创建RDB文件。这两个命令都不会把过期的key保存到RDB文件中,这样也能达到删除过期key的效果。如:数据库中包含3个键k1、k2、k3
,并且k2已经过期
,那么创建新的RDB
文件时,程序只会将k1
和k3
保存到RDB
文件中,k2
则会被忽略。
载入RDB文件
/*
* 如果服务器为主节点的话,
* 那么在键已经过期的时候,不再将它们关联到数据库中去
*/
if (server.masterhost == NULL && expiretime != -1 && expiretime < now) {
decrRefCount(key);
decrRefCount(val);
// 跳过
continue;
}
在启动Redis服务器时,如果服务器只开启了RDB持久化
,那么服务器将会载入RDB文件
:
- 如果服务器以主服务器模式运行,在载入
RDB
文件时,程序会对文件中保存的键进行检查,未过期的键会被载入到数据库中,过期键会被忽略。 - 如果服务器以从服务器模式运行,在载入RDB文件时,文件中保存的所有键,不论是否过期,都会被载入到数据库中。
因为主从服务器在进行数据同步的时候,从服务器的数据库会被清空,所以一般情况下,过期键对载入RDB文件的从服务器不会造成影响。
AOF对过期键的处理
AOF文件写入
如果数据库中的某个键已经过期,并且服务器开启了AOF持久化功能
,当过期键被惰性删除
或者定期删除
后,程序会向AOF文件
追加一条DEL命令
,显式记录该键已被删除
。举个例子,如果客户端执行命令GET message
访问已经过期的message
键,那么服务器将执行以下3个动作:
- 从数据库中删除message键;
- 追加一条
DEL message
命令到AOF文件; - 向执行·GET message·命令的客户端返回空回复。
AOF文件重写
在执行AOF文件重写时,程序会对数据库中的键进行检查,已过期的键不会被保存到重写后的AOF文件中。
复制功能对过期键的处理
在主从复制模式下,从服务器的过期键删除动作由主服务器控制:
- 主服务器在删除一个过期键后,向所有从服务器发送一个
DEL
命令,从服务器删除这个过期键。 - 从服务器在执行客户端发送的读命令时,即使发现该键已过期也不会删除该键,照常返回该键的值。
- 从服务器只有接收到主服务器发送的
DEL命令
后,才会删除过期键
。
问题:你可能会为问了,既然Redis有过期数据删除策略,那为什么还会拉取到已经过期的数据呢?
当客户端往主库写入数据后,并设置了过期时间,数据会以异步方式同步给从库。
- 如果此时读主库,数据已经过期,主库的惰性删除会发挥作用,主动触发删除操作,客户端不会拿到已过期数据
- 但是如果读从库,则有可能拿到过期数据。原因如下
- 原因一:跟
Redis
的版本有关系,Redis 3.2
之前版本,读从库并不会判断数据是否过期
,所以有可能返回过期数据。
-原因二:跟过期时间的设置方式有关系,我们一般采用EXPIRE
和PEXPIRE
,表示从执行命令那个时刻开始,往后延长ttl
时间。严重依赖于开始时间
从什么时候算起。
- 原因一:跟
原因一解决方案:
升级Redis的版本,至少要3.2 以上版本,读从库,如果数据已经过期,则会过滤并返回空值。
原因二:
如上图所示,简单描述下过程:
- 主库在
t1
时刻写入一个带过期时间的数据,数据的有效期一直到t3
。 - 由于网络原因、或者缓存服务器的执行效率,从库的命令并没有立即执行。一直等到了
t2
才开始执行, 数据的有效期则会延后到t5
。 - 如果,此时客户端访问从库,发现数据依然处于有效期内,可以正常使用。
原因二解决方案:
可以采用Redis
的另外两个命令,EXPIREAT
和 PEXPIREAT
,相对简单,表示过期时间为一个具体的时间点。避免了对开始时间从什么时候算起的依赖。
EXPIREAT:单位为秒
PEXPIREAT:单位为毫秒
特别注意:
EXPIREAT 和 PEXPIREAT 设置的是时间点,所以要求主从节点的时钟保持一致,需要与NTP 时间服务器保持时钟同步。
主从同步,除了读从库可能拉取到过期数据,还可能遇到数据一致性问题。这个。。。。以后再说。