大白话看明白Redis数据淘汰策略,渣男提裤不认人

点赞多大胆,就有多大产!开源促使进步,献给每一位技术使用者和爱好者!
干货满满,摆好姿势,点赞发车

Redis数据淘汰策略

前言

Redis作为一个内存数据库,性能十分高,主要依赖的硬件资源就是内存,据官方数据表示Redis读的速度是110000次/s,写的速度是81000次/s,我们向Redis中源源不断存储数据,内存空间有限,这时淘汰无用数据释放空间,存储新数据就变得尤为重要,Redis提供了数据淘汰策略来释放内存

内容偏向理论,需要大家发挥想象脑补画面,最好记下来,成为面试时的谈资

内存配置

Redis在生产环境中,采用配置参数maxmemory 的方式来限制内存大小。当实际存储内存超出maxmemory 参数值时,可以通过Redis内存淘汰策略,来决定如何腾出新空间继续支持读写工作

在这里插入图片描述
上图是Redis5.0.5版本的配置,默认是被注释掉关闭的,单位是字节,当设置为0时没有限制

淘汰策略

Redis4之后为我们提供了八个不同的内存置换策略。之前版本提供了6种

  • volatile-lru:从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰。没有设置过期时间的key不会被淘汰,这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失
  • volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰。
  • volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰。
  • volatile-lfu:从已设置过期时间的数据集(server.db[i].expires)挑选使用频率最低的数据淘汰。
  • allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰
  • allkeys-lfu:从数据集(server.db[i].dict)中挑选使用频率最低的数据淘汰。
  • allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰
  • no-enviction(驱逐):禁止驱逐数据,这也是默认策略。意思是当内存不足以容纳新入数据时,新写入操作就会报错,请求可以继续进行,线上任务也不能持续进行,采用no-enviction策略可以保证数据不被丢失。

这八种大体上可以分为4中,lru、lfu、random、ttl,其中lfu方式是新增策略,也就是根据使用率来淘汰数据

在这里插入图片描述

通过设置maxmemory-policy设置淘汰策略

Redis是怎么触发淘汰机制的呢

首先,客户端存储数据,肯定需要有内存来存储

其次,Redis检查内存使用情况,如果实际使用内存已经超出maxmemory,Redis就会根据用户配置的淘汰策略选出无用的key

最后,确认选中数据没有问题,成功执行淘汰任务

过期键删除策略

我们都知道Redis中的key是可以设置过期时间的,这里提一下怎么判定过期键

  • Redis键的过期时间都保存在过期字典中

  • 检查给定键是否存在于字典中,如果有取得键的过期时间

  • 检查当前UNIX时间戳是否大于键的过期时间,如果是的话那么该键已经过期,否则键未过期

    接下来我们就说说过期的key如何被无情抛弃的

定时删除

  • 在设置键的过期时间的同时,创建一个定时器(timer),让定时器在键的过期时间来临时,立即执行对键的删除操作;

  • 定时删除操作对于内存来说是友好的,通过使用定时器,可以保证尽快的将过期键删除,释放所占内存

  • 对于CPU来说不是友好的,如果过期键比较多的话,删除过期键这一行为可能占用相当一部分CPU时间,在内存不紧张但是CPU紧张的情况下,将CPU时间用在删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响,在某些情况下有点分不清主次啦!

  • 例如:如果有大量的命令请求等待服务器处理,并且服务器当前不缺少内存,那么服务器应该优先将CPU时间用在处理客户端的请求上,而不是删除过期键上面

  • 创建一个定时器需要用到Redis服务器中的事件事件,当前时间事件的实现方式是无序链表,查找一个事件的时间复杂度为O(N),并不能高效处理大量时间事件

  • 因此要让服务器创建大量的定时器,从而实现定时策略删除,在这里是不现实的

惰性删除

  • 对CPU是友好的,程序只会在取出键时才对键进行过期检查,这可以保证删除过期键的操作只会在非做不可时进行,并且删除的目标仅限于当前处理的键,这个策略不会在删除其他无关的过期建上浪费任何CPU时间

  • 对内存是不友好的,如果一个键已经过期,而这个键仍然保留在数据库中,那么只要这个过期键不被删除,它所占的内存就不会释放

  • 在使用惰性删除策略时,如果数据库中有非常多的过期键,而这些过期建又恰好没有被访问到的话,那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB或者FLUSHALL,谨慎别用,企业中一般会将这连个命令禁用甚至删除掉,劲太猛了),这种情况是不是就是我们程序中说的内存泄漏,无用的数据占用大量内存,对于Redis这种内存数据库来说肯定不是好事

  • 例如:对于一些和时间有关的数据,比如日志(log),在某个时间点之后,对它们的访问就会减少,甚至不再访问,如果这类过期数据大量的积压在数据库中,用户以为服务器已经将它们删除了,但实际还存在,而且键所占内存也没有释放,会造成很严重的后果

定期删除

  • 上边两种删除策略在单一使用时都有明显的缺陷,定时删除占用太多CU时间,降低服务器吞吐量和响应时间,惰性删除浪费太多内存,有内存泄漏危险,定期删除就是前两种策略的整合和折中方案
  • 定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响
  • 通过定期删除过期键,定期删除策略有效地减少因过期键带来的内存浪费

定期删除策略的难点在于确定删除操作的时长和频率

  • 如果删除处操作执行的太频繁,或者执行的时间太长(时间长不一定好),定时删除策略不就退化成定时删除策略了嘛,以至于CPU将过多的时间耗费在删除粗过期键上
  • 如果删除处理执行的太少,或者时间太短~~~,定期删除策略又会向惰性删除那样,出现内存浪费情况
  • 因此采用定期删除策略,服务器必须根据情况,设置删除操作的执行时长和执行频率

Redis服务器实际使用的删除策略是惰性删除和定时删除两种,相互配合可以在CPU使用时间和内存空间取得平衡,这里我们先说一下概念,具体实现待我阅读源码再与大家分享

AOF、RDB和复制功能对过期键处理

RDB

生成RDB文件

执行SAVE或者BGSAVE创建新的RDB文件时,程序会对数据库中的键进行检查,已过期的键不会被保存到新创建的RDB文件中,因此数据库包含过期键不会对新的RDB文件造成影响

载入RDB文件

在启动Redis服务器时,如果服务器开启了RDB文件,那么服务器就会对RDB文件进行载入

  • 如果当前服务器是Master,程序会对文件中保存的key进行检查,未过期的键会被载入到数据库中,而过期的键则会被忽略,所以过期键对载入RDB文件的主服务器不会造成影响
  • 如果当前服务器是Slave,文件中保存的所有键,无论是否过期,都会被载入到数据库中,不过,因为主从服务器在进行数据同步时,从服务器的数据库就会被同步成和主服务器一致,所以一般来讲,过期键对载入RDB文件的从服务器也不会造成影响
  • 例如:数据库中有k1, k2, k3三个键,k2已经过期,启动服务时
    • 如果是主服务器,k1, k3会被载入,k2会被忽略
    • 如果是从服务器,k1, k2, k3都会被载入

AOF

AOF文件写入

当服务器以AOF持久化模式运行时,如果数据库中的某个key已经过期,但是他还没有被惰性删除或者定期删除,那么AOF文件不会因为这个过期键产生任何影响,当该键被惰性删除或者定期删除之后,程序会向AOF文件追加一条DEL命令,来显式记录该键已被删除

  • 试图获取过期键zhishi,会有以下三个动作:
    • 从数据库中删除zhishi
    • 追加一条DEL zhishi命令到AOF文件
    • 向执行 GET命令的客户端返回空回复

AOF重写

AOF是将执行的写命令添加到AOF文件的末尾来记录数据的变化;为了避免文件被添加得越来越大,甚至有可能用完硬盘的所有空间,因此Redis提供了Rewrite的优化策略,分别是REWRITEAOFBGREWRITEAOF,两个命令的区别也是在于是否阻塞主进程,这两个命令都不会将数据空间中的过期键给保存到AOF文件中

主从复模式下对过期键的处理

复制模式下,从服务器的过期键删除动作由主服务控制

  • 主服务器在删除一个过期键之后,会显式地向所有从服务器发送一个DEL命令,告知从服务器删除这个过期键
  • 从服务器在执行客户端发送过来的读命令时,即使碰到过期键也不会删除,而是继续向处理未过期键一样来处理过期键
  • 从服务器只有接收到主服务器发送过来的DEL命令之后,才会删除过期键
  • 通过由主服务器来控制从服务器统一地删除过期键,可以保证主从服务器数据一致性,也正是因为这个原因,当一个过期键仍然存在于主服务器时,这个过期键在从服务器中的复制品也会继续存在

本文参考

  • 《Redis设计与实现》

本文若有任何看不懂,或者有错误的地方欢迎大家评论区留言,我时时关注哦

我是芝士,用你勤劳的双手点个赞吧,这将是我创作更多优质文章的动力!

展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 像素格子 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读