Redis主从+读写分离中可以在从机读取到过期数据

参考链接:

https://mp.weixin.qq.com/s?__biz=MzIyNzUwMjM2MA==&mid=2247483696&idx=1&sn=c69e364b189fe261a466e4f8d290258b&scene=2&srcid=0812sWPJjYmbGOEzR8oMS0Oe#wechat_redirect

产生原因:

  redis的从库是无法主动的删除已经过期的key的,所以如果做了读写分离,就很有可能在从库读到脏数据

解决方法:

  通过一个程序循环便利所有的key,例如scan

  升级到reidis3.2

详细分析:

我们首先来了解一下redis的三种过期策略:

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

  2 定期删除:由于惰性删除策略无法保证冷数据(偶尔会被查询或调用的数据)被及时删掉,所以redis会定期主动淘汰一批已经过期的key

  3 主动删除:当前内存超过maxmemory限定时,触发主动清理策略,该策略由2启动参数的配置决定,可配置参数及说明:

volatile-lru:从已设置过期时间的数据集中根据LRU算法删除数据(redis3.0之前的默认策略)
volatile-ttl:从已设置过期时间的数据集中挑选过期时间最小的数据删除
volatile-random:从已设置过期时间的数据集中随机选择数据删除 allkeys-lru:从所有数据集中根据LRU算法删除数据
allkeys-random:从所有数据集中任意选择删除数据 noenviction:禁止从内存中删除数据(从redis3.0开始的默认策略) maxmemory-samples:删除数据的抽样样本数,redis3.0之前默认样本数为3,redis3.0之后默认样本数为5,该参数过小会导致主动删除策略不准确,过大会消耗多余的cpu

定期删除:

  redis定位为轻量、快速的内存数据库,所以如果为所有key都加上定时器,过期即删除的定时策略显然后消耗大量的性能,这与redis的价值观不符;而且过期即删的定时策略只会在主库上进行,对于目前redis使用的组合策略来说,单位时间过期的数据量越多,越可能会带来key的过期延迟,对于做了读写分离的业务,很容易导致从库读取到过期的脏数据

如何避免从库读取到脏数据:

  1 通过scan命令扫库:

    当redis中的key被scan的时候,相当于访问了该key,同样也会做过期检测,充分发挥redis惰性删除的策略,这个方法能大大降低了脏数据读取的概率,答案缺点也比较明显,会造成一定的数据库压力,谨慎合理是哟个,够则有可能影响线上业务的效率

  2 升级redis到新的版本:

    在redis3.2中,redis加入了一个新特性来解决主从不一致导致读取到过期数据问题,在db.c文件中,作者对lookupKeyRead做了相应的修改,增加了key是否过期以及对主从库的判断,如果key已过期,当前访问的master则返回null;当前访问的是从库,且执行的是只读命令也返回null(老版本从库真实的返回该操作的结果,如果该key过期后主库没有删除,就返回为null)

上一篇:flask中使用ajax 处理前端请求,结果展示在同一页面,不点击页面不展示


下一篇:JavaScript模块化演变 CommonJs,AMD, CMD, UMD(一)