Redis的过期删除策略和内存淘汰机制以及如何保证双写的一致性
- 过期删除策略
- 内存淘汰机制
- 怎么保证redis双写的一致性?
- 更新策略
- 先删除缓存后更新数据库
- 先更新数据库后删除缓存
- 如何选择?
- 如何保证先更新数据库后删除缓存的线程安全问题?
过期删除策略
为了保证缓存和数据的一致性和节省缓存空间,就可以给存储的数据设置过期时间,而对于过期键的删除,redis以下三种策略,分别是定时删除、惰性删除、定期删除。
定时删除策略:在给键设置过期时间的同时,创建一个定时事件,当到达事件时,会执行事件删除过期键
优点:缓存能够及时被删除,占用的缓存可以被及时释放
缺点:当键比较多时,定时删除策略会占用;一部分cpu时间,浪费性能
惰性删除策略:不会主动删除过期键,每次访问该键时都会检验是否过期,如果过期就会删除过期键
优点:不会浪费过多性能
缺点:可能会造成大量过期键的堆积,浪费内存空间
定期删除策略:每割一段时间都会随机抽选一些键检查是否过期。
定期删除过程:1.每一秒进行十次检查(可以自定义修改)
2.每次检查都会随机抽取20个键进行检查,如果检查的键中过期的超过五个,也就是四分之一,则继续执行2,否则进入下一次检查
为了避免循环过度和死循环,redis每次检查都设置了超时时间,默认未25ms
优点:通过限制删除操作执行的时长和频率,减少对cpu的影响,同时清理一部分内存
缺点:内存清除方面没有定时删除好,对系统资源的消耗又没有惰性删除少。并且删除的频率不好控制
内存淘汰机制
当redis的内存不足时,当仍然有需要缓存的请求到达时,需要使用内存淘汰机制进行处理
删除过期键策略
volatile-lru:从设置过期删除的键中,选择最近最少使用的键值删除
volatile-lfu: 选择最少使用的键值删除
volatile-random: 随机挑选键值删除
volatile-ttl:选择将要过期的键值删除
删除所有键策略
allkeys-lru:从所有键中,选择最近最少使用的键值删除
allkeys-lfu:选择最少使用
allkeys-random:随机挑选键值删除
不做任何处理
noeviction:不淘汰键值,报错禁止写入
当前redis的默认内存淘汰机制就是noeviction
怎么保证redis双写的一致性?
如果有更新数据库的操作时,我们需要怎么操作缓存才能保证双写的一致性,是更新缓存还是删除缓存
更新策略
更新策略的问题
1.可能造成无效更新。
如果连续执行一百个更新数据库的操作,那么就要更新一百次缓存,那么中间九十九次更新就是无效更新了。
2.可能造成线程安全问题。如下图
线程A:
Time1:更新数据库
Time4:更新缓存
线程B
Time2:更新数据库
Time3:更新缓存
按照以上的执行顺序,更新后的数据库是线程B更新的值,而缓存时线程A更新的值,此时数据库和缓存不一致,造成线程安全问题,因此避免使用更新策略
先删除缓存后更新数据库
可能会造成线程安全问题,如下
当线程A删除缓存后还没有更新数据库,线程B查询数据没有命中缓存从原数据库中查询旧数据并且放入缓存中,导致缓存中存在旧数据,造成了数据库和缓存不一致的问题
先更新数据库后删除缓存
存在线程安全问题,如下
线程A查询数据,如果此时由于缓存过期导致缓存失效,开始查询数据库,线程B相继更新数据库删除缓存,Time4线程A将查询出的旧数据放入缓存,导致缓存和数据库不一致
如何选择?
选择先更新数据库后删除缓存。更新缓存存在可能会造成更新失效和线程安全问题,优先将更新策略排除。而先删除缓存策略相对后删除缓存策略,它发生的可能性更高,因此我们选择先更新数据库后删除缓存的策略。
如何保证先更新数据库后删除缓存的线程安全问题?
我们可以使用延迟双删策略,即更新数据库和删除缓存之后让线程休眠一段时间再次删除缓存。但是这并不能严格的保证线程安全问题,如果要保证数据的高一致性,可以使用分布式锁来实现。