Redis主从模式下从库过期的key仍然能够被读到的解决方案

Redis主从模式下,当对一个key设定过期时间,到期之后从库依然能够读取到数据。这个问题困扰了我很久,相信很多人都遇到过这种问题了。(前提是你不去读主库,并且redis版本在3.2以下)。

经过一番搜寻,发现很多人遇到的问题和我一样。

主Redis

setex test 20 1
+OK
get test
$1
1
ttl test
:18

从Redis

get test
$1
1
ttl test
:7

以上都没问题,然而过几秒再看从Redis

ttl test
:-1
get test
$1
1

test这个key已经过期了,然而还是可以获取到test的值。

在使用Redis做锁的时候,如果直接取读从库的值,这就有大问题了。

为什么从库不删除数据?

redis删除过期数据有以下几个策略:

1.惰性删除:当读/写一个已经过期的key时,会触发惰性删除策略,直接删除掉这个过期key,很明显,这是被动的!

2.定期删除:由于惰性删除策略无法保证冷数据被及时删掉,所以 redis 会定期主动淘汰一批已过期的key。(在第二节中会具体说明)

3.主动删除:当前已用内存超过maxMemory限定时,触发主动清理策略。主动设置的前提是设置了maxMemory的值

int expireIfNeeded(redisDb *db, robj *key) { 
 time_t when = getExpire(db,key); 
 
 if (when < 0) return 0; /* No expire for this key */ 
 
 /* Don't expire anything while loading. It will be done later. */ 
 if (server.loading) return 0; 
 
 /* If we are running in the context of a slave, return ASAP: 
 * the slave key expiration is controlled by the master that will 
 * send us synthesized DEL operations for expired keys. 
 * 
 * Still we try to return the right information to the caller, 
 * that is, 0 if we think the key should be still valid, 1 if 
 * we think the key is expired at this time. */ 
 if (server.masterhost != NULL) { 
 return time(NULL) > when; 
 } 
 
 /* Return when this key has not expired */ 
 if (time(NULL) <= when) return 0; 
 
 /* Delete the key */ 
 server.stat_expiredkeys++; 
 propagateExpire(db,key); 
 return dbDelete(db,key); 
}
通过以上源码发现,4行:没有设置超时时间,则不删;7行:在”loading”时不删;16行:非主库不删;21行未到期不删。25行同步从库和文件。
所以说,在从库执行主动删除操作,或者通过惰性删除的方式触发删除key的操作,最终都不会执行成功。原因就在上面的第16行代码。
如何解决这种问题
1.升级到redis 3.2
2.通过ttl判断
生产环境升级有风险,运维可能不相干,那么就通过ttl来进行判断是否过期吧。
参考网页
[1] http://www.cnblogs.com/bridger/archive/2012/11/07/2758734.html
[2] http://www.tuicool.com/articles/INRZFr

你可能还喜欢下面这些文章

wordpress支撑百万文章解决方案

作为一个博客系统,wordpress在易用性和可扩展性上都非常出色。后题用户体验是非友好,插件众多。然而由于定位的问题,wordpress无法支撑大量文章。当文章数量达到上万的时候,有些主题的前台可能会非常卡。当文章数量达到数十万的时候,wordpress后台可能会特别卡。更何况大部分插件并没有在性能上下功夫,插件越多,wordpress越卡。那么有没有什么方案能让wordpress支撑大量文章?十万,百万,甚至更多?支撑百万数据并不是存入一百万文章就可以了。实际上百万文章对mysql来说毫无压力。在mysql中,百万文章仅仅是百万条记录而已。导致缓慢的是mysql的查询。对于百万条记录的数据

js保存用户自定义的样式重新载入会闪烁的解决方案

在制作一个页面的时候,有需要前台js保存用户自定义的样式的需求,但是保存之后,重新刷新页面,会显示原来的样式,然后再变更为现在的自定义的样式。这是一个有闪烁的例子,点击打开保存样式之后,再重新强制刷新几次,可以看到页面在载入的时候会出现闪烁的情况。强迫症患者表示这不能接受,页面这么小的情况都闪烁的这么厉害,这页面大了,加载速度慢了,自定义样式还得等着加载完成之后才能显示,就失去了自定义的意义了。上面的闪烁是可以理解的,css渲染完成之后,js给body增加了一个class,浏览器又会重新渲染,因此会出现短暂的闪烁那么在渲染到head的时候,此时再用js给head标签里面增加css呢?这样不就在

使用expect之后无法使用rz和sz的解决方法

在机器太多的时候,我们会使用expect来自动化登录,然而使用expect之后就不能使用rz和sz了。经过一番寻找之后,发现有一个解决方案,在脚本之前增加一个export LC_CTYPE=en_US注意,这个语句放到登录脚本里面就可以了,不要放到.bash_profile里面,如果放到bash_profile里面可能你当前的终端语言都变了,中文可能会乱码。这个缺点是远程机器里面的中文可能会乱码了,如果有更好的解决方案,我会在这里更新。

如何避免GIT修改文件权限导致的提交变更

默认情况下当文件权限变更的时候,GIT会认为该文件有变更,提交的时候会将权限变更的文件一并提交上去,这样会让我们的代码修改记录变得混乱。解决方案解决方案很简单,忽略文件权限的变更。使用如下命令:

ftp传输binary和ascii模式(二进制和文本)的区别

ASCII模式和BINARY模式的区别是回车换行的处理,binary模式不对数据进行任何处理,asci模式将回车换行转换为本机的回车字符,比如Unix下是\n,Windows下是\r\n,Mac下是\rascii模式下会转换文件不能说是不同系统对回车换行解释不同,而是不同的系统有不同的行结束符unix系统下行结束符是一个字节,即十六进制的0A,而ms的系统是两个字节,即十六进制的0D0A所以当你用ascii方式从unix的ftp server下载文件时(不管是二进制或者文本文件),每检测到一个字节是0A,就会自动插入一个0D,所以如果你的文件是二进制文件比如可执行文件、压缩包什么的,就肯定不能

赞赏

微信赞赏支付宝赞赏

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注