由于数据更新会删除之前缓存的数据。后面的不改。其他数据访问的时候,会先请求redis读取数据,redis没有数据则从数据库获取数据,数据库有数据更新,就会删除缓存但不会更新redis。
Redis 中数据过期策略采用定期删除+惰性删除策略。
定期删除策略:Redis 启用一个定时器定时监视所有的 key,判断key是否过期,过期的话就删除。这种策略可以保证过期的 key 最终都会被删除,但是也存在严重的缺点:每次都遍历内存中所有的数据,非常消耗 CPU 资源,并且当 key 已过期,但是定时器还处于未唤起状态,这段时间内 key 仍然可以用。
惰性删除策略:在获取 key 时,先判断 key 是否过期,如果过期则删除。这种方式存在一个缺点:如果这个 key 一直未被使用,那么它一直在内存中,其实它已经过期了,会浪费大量的空间。
2、定期删除+惰性删除策略是如何工作的?
这两种策略天然的互补,结合起来之后,定时删除策略就发生了一些改变,不在是每次扫描全部的 key 了,而是随机抽取一部分 key 进行检查,这样就降低了对 CPU 资源的损耗,惰性删除策略互补了为检查到的key,基本上满足了所有要求。但是有时候就是那么的巧,既没有被定时器抽取到,又没有被使用,这些数据又如何从内存中消失?没关系,还有内存淘汰机制,当内存不够用时,内存淘汰机制就会上场。Redis 内存淘汰机制有以下几种策略:
noeviction:当内存不足以容纳新写入数据时,新写入 *** 作会报错。(Redis 默认策略)
allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的 Key。(推荐使用)
allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个 Key。
volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存,又做持久化存储的时候才用。
volatile-random:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个 Key。
volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的 Key 优先移除。
修改内存淘汰机制只需要在 redisconf 配置文件中配置 maxmemory-policy 参数即可。
懒惰处理
Redis在get *** 作时遇到过期的key会进行删除 *** 作。
集中处理
Redis会将设置了过期时间的key放到一个独立的字典里,默认每秒10次过期扫描。扫描方式:
为防止扫描时间过长,扫描时间限制为25ms,开发时应尽量避免大量key同时过期。
从库不会进行过期扫描,主库删除时,会在AOF文件里增加一条del指令,同步到所有从库,从库通过此指令来删除。由于指令的同步存在异步,所以会出现主从数据不一致的情况。
当Redis内存超出物理内存限制时,内存数据会开始和磁盘产生频繁的交换,使得性能急剧下降。为了限制内存的使用,Redis提供参数 maxmemory 来限制最大内存,当内存超出后,会有以下策略( maxmemory-policy )来淘汰key以腾出空间:
由于LRU算法需要消耗大量的额外内存,redis采用一种近似的LRU算法。它给每个 key 增加了一个额外的小字段(24bit),也就是最后一次被访问的时间戳。每次执行写 *** 作时,如果发现内存超出 maxmemory ,就随机采样5个(参数 maxmemory_samples 配置)key,然后淘汰最旧的。如果淘汰之后还是超出,那就继续随机淘汰,直到不超出为止。如果 maxmemory-policy 是volatile-xxx,就从设置过期时间的key里采样,否则就从所有key里采样。
Redis30里增加了一个淘汰池,就是一个大小为 maxmemory_samples 的数组。每次淘汰时会将随机出来的key和数组里的key融合,淘汰掉最旧的一个,然后将剩下的较旧的key放到淘汰池里给下个循环用。
redis的删除del在删除一个大对象的时候有可能造成卡顿。为了解决这个问题Redis40引入了unlink指令,将这个key的对象引用从Redis内存数据里删除,将删除 *** 作封装成一个任务丢到一个异步队列里。然后有个异步线程会从这个队列里取出任务并执行。
清空 *** 作 flushdb 和 flushall ,在Redis40后,在指令后面增加 async ,就也可以像上面一样异步执行。
《Redis深度历险:核心原理和应用实践》
以上就是关于如果redis没有数据则不会从数据库中读取数据全部的内容,包括:如果redis没有数据则不会从数据库中读取数据、Redis 的数据过期淘汰策略、Redis数据的过期与淘汰等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)