参考链接：
产生原因：
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）