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）