Redis内存满了怎么办?让你玩懂8种内存淘汰策略

简介: 我们知道redis是一个非常常用的内存型数据库,数据从内存中读取是它非常高效的原因之一,那么但是如果有一天, 「 redis分配的内存满了怎么办 」 ?遇到这个面试题不要慌,这种问题我们分为两角度回答就可以:

我们知道redis是一个非常常用的内存型数据库,数据从内存中读取是它非常高效的原因之一,那么但是如果有一天, 「 redis分配的内存满了怎么办 」 ?遇到这个面试题不要慌,这种问题我们分为两角度回答就可以:

  • 「 redis会怎么做 」
  • 「 我们可以怎么做 」

增加redis可用内存

这种方法很暴力,也很好用,我们直接通过增加redis的可用内存就可以了, 有两种方式

  • 「 通过配置文件配置 」通过在redis安装目录下面的redis.conf配置文件中添加以下配置设置内存大小//设置redis最大占用内存大小为1000M
    maxmemory 1000mb
    复制代码
  • 「 通过命令修改 」redis支持运行时通过命令动态修改内存大小//设置redis最大占用内存大小为1000M
    127.0.0.1:6379> config set maxmemory 1000mb
    复制代码

这种方法是立竿见影的,reids 内存总归受限于机器的内存,也不能无限制地增长,那么如果没有办法再增加 redis 的可用内存怎么办呢?

内存淘汰策略

实际上Redis定义了 「 8种内存淘汰策略 」 用来处理redis内存满的情况:

  • noeviction:直接返回错误,不淘汰任何已经存在的redis键
  • allkeys-lru:所有的键使用lru算法进行淘汰
  • volatile-lru:有过期时间的使用lru算法进行淘汰
  • allkeys-random:随机删除redis键
  • volatile-random:随机删除有过期时间的redis键
  • volatile-ttl:删除快过期的redis键
  • volatile-lfu:根据lfu算法从有过期时间的键删除
  • allkeys-lfu:根据lfu算法从所有键删除

这些内存淘汰策略都很好理解,我们着重讲解一下lru,lfu,ttl是怎么去实现的

lru的最佳实践?

lru是Least Recently Used的缩写,也就是 「 最近很少使用 」 ,也可以理解成最久没有使用。最近刚刚使用过的,后面接着会用到的概率也就越大。 由于内存是非常金贵的,导致我们可以存储在缓存当中的数据是有限的。比如说我们固定只能存储1w条,当内存满了之后,缓存每插入一条新数据,都要抛弃一条最长没有使用的旧数据。 我们把上面的内容整理一下,可以得到几点要求:

  • 「 1.保证其的读写效率,比如读写的复杂度都是O(1) 」
  • 「 2.当一条数据被读取,将它最近使用的时间更新 」
  • 「 3.当插入一条新数据的时候,删除最久没有使用过的数据 」

所以我们要尽可能地保证查询效率很高,插入效率很高,我们知道如果只考虑查询效率,那么hash表可能就是最优的选择,如果只考虑插入效率,那么链表必定有它的一席之地。

但是这两种数据结构单独使用,都有它的弊端,那么说,有没有一种数据结构,既能够保证查询效率,又能够保证插入效率呢? 于是 hash+链表这种结构出现了

hash表用来查询在链表中的数据位置,链表负责数据的插入 当新数据插入到链表头部时有两种情况;

  • 1.当链表满的时候,将链表尾部的数据丢弃。这个比较简单,直接将链表尾部指针抹去,并且清除对应hash中的信息就好了
  • 2.每当缓存命中(即缓存数据被访问),则将数据移到链表头部;这种情况我们发现,如果命中到链表中间节点,我们需要做的是1).将该节点移到头节点2). 「 将该节点的上一个节点的下一个节点,设置为该节点的下一个节点 」 ,这里就会有一个问题,我们无法找到该节点的上一个节点,因为是单向链表,所以,新的模型产生了。

这时双向链表的作用也体现出来了。能直接定位到父节点。 这效率就很高了。而且由于双向链表有尾指针,所以剔除最后的尾节点也十分方便,快捷

所以最终的解决方案就是采用 「 哈希表+双向链表 」 的结构

lfu的最佳实践?

LFU:Least Frequently Used,最不经常使用策略,在一段时间内,数据被 「 使用频次最少 」 的,优先被淘汰。最少使用(LFU)是一种用于管理计算机内存的缓存算法。主要是记录和追踪内存块的使用次数,当缓存已满并且需要更多空间时,系统将以最低内存块使用频率清除内存.采用LFU算法的最简单方法是为每个加载到缓存的块分配一个计数器。每次引用该块时,计数器将增加一。当缓存达到容量并有一个新的内存块等待插入时,系统将搜索计数器最低的块并将其从缓存中删除。

这里我们提出一种达到 O(1) 时间复杂度的 LFU 实现方案,它支持的操作包括插入、访问以及删除

如图:

由两个双向链表+哈希表组成,上方的双向链表用来计数,下方的双向链表用来记录存储的数据,该链表的头节点存储了数字,哈希表的value对象记录下方双向链表的数据 我们这里按照插入的流程走一遍:

  • 将需要存储的数据插入
  • 在hash表中 「 存在 」 ,找到对应的下方双向链表,将该节点的上一个节点和该节点的下一个节点相连(这里可能只有自己,直接移除就好),然后判断自己所在上方双向链表的计数是否比当前计数大1「 如果是 」 ,则将自己移到该上方双向链表,并且 「 判断该双向链表下是否含有元素 」,如果没有,则要删除该节点「 如果不是或者该上方双向列表无下个节点 」 则新加节点,将计数设为当前计数+1
  • 在hash表 「 不存在 」 ,将数据存入hash表,将数据与双向链表的头节点相连(这里有可能链表未初始化)

这样当查找,插入时效率都为O(1)

redis TTL 是怎么实现的?

TTL存储的数据结构

redis针对TTL时间有专门的dict进行存储,就是redisDb当中的dict *expires字段,dict顾名思义就是一个hashtable,key为对应的rediskey,value为对应的TTL时间。  dict的数据结构中含有2个dictht对象,主要是为了解决hash冲突过程中重新hash数据使用。

TTL 设置过期时间

TTL设置key过期时间的方法主要是下面4个:

  • expire 按照相对时间且以秒为单位的过期策略
  • expireat 按照绝对时间且以秒为单位的过期策略
  • pexpire 按照相对时间且以毫秒为单位的过期策略
  • pexpireat 按照绝对时间且以毫秒为单位的过期策略
{"expire",expireCommand,3,"w",0,NULL,1,1,1,0,0},
{"expireat",expireatCommand,3,"w",0,NULL,1,1,1,0,0},
{"pexpire",pexpireCommand,3,"w",0,NULL,1,1,1,0,0},
{"pexpireat",pexpireatCommand,3,"w",0,NULL,1,1,1,0,0},
复制代码

expire expireat pexpire pexpireat

从实际设置过期时间的实现函数来看,相对时间的策略会有一个当前时间作为基准时间,绝对时间的策略会 「 以0作为一个基准时间 」

void expireCommand(redisClient *c) {
    expireGenericCommand(c,mstime(),UNIT_SECONDS);
}
void expireatCommand(redisClient *c) {
    expireGenericCommand(c,0,UNIT_SECONDS);
}
void pexpireCommand(redisClient *c) {
    expireGenericCommand(c,mstime(),UNIT_MILLISECONDS);
}
void pexpireatCommand(redisClient *c) {
    expireGenericCommand(c,0,UNIT_MILLISECONDS);
}
复制代码

整个过期时间最后都会换算到绝对时间进行存储,通过公式基准时间+过期时间来进行计算。  对于相对时间而言基准时间就是当前时间,对于绝对时间而言相对时间就是0。  中途考虑设置的过期时间是否已经过期,如果已经过期那么在master就会删除该数据并同步删除动作到slave。  正常的设置过期时间是通过setExpire方法保存到 dict *expires对象当中。

/* 
*
* 这个函数是 EXPIRE 、 PEXPIRE 、 EXPIREAT 和 PEXPIREAT 命令的底层实现函数。
*
* 命令的第二个参数可能是绝对值,也可能是相对值。
* 当执行 *AT 命令时, basetime 为 0 ,在其他情况下,它保存的就是当前的绝对时间。
*
* unit 用于指定 argv[2] (传入过期时间)的格式,
* 它可以是 UNIT_SECONDS 或 UNIT_MILLISECONDS ,
* basetime 参数则总是毫秒格式的。
*/
void expireGenericCommand(redisClient *c, long long basetime, int unit) {
   robj *key = c->argv[1], *param = c->argv[2];
   long long when; /* unix time in milliseconds when the key will expire. */
   // 取出 when 参数
   if (getLongLongFromObjectOrReply(c, param, &when, NULL) != REDIS_OK)
       return;
   // 如果传入的过期时间是以秒为单位的,那么将它转换为毫秒
   if (unit == UNIT_SECONDS) when *= 1000;
   when += basetime;
   /* No key, return zero. */
   // 取出键
   if (lookupKeyRead(c->db,key) == NULL) {
       addReply(c,shared.czero);
       return;
   }
   /* 
    * 在载入数据时,或者服务器为附属节点时,
    * 即使 EXPIRE 的 TTL 为负数,或者 EXPIREAT 提供的时间戳已经过期,
    * 服务器也不会主动删除这个键,而是等待主节点发来显式的 DEL 命令。
    *
    * 程序会继续将(一个可能已经过期的 TTL)设置为键的过期时间,
    * 并且等待主节点发来 DEL 命令。
    */
   if (when <= mstime() && !server.loading && !server.masterhost) {
       // when 提供的时间已经过期,服务器为主节点,并且没在载入数据
       robj *aux;
       redisAssertWithInfo(c,key,dbDelete(c->db,key));
       server.dirty++;
       /* Replicate/AOF this as an explicit DEL. */
       // 传播 DEL 命令
       aux = createStringObject("DEL",3);
       rewriteClientCommandVector(c,2,aux,key);
       decrRefCount(aux);
       signalModifiedKey(c->db,key);
       notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,"del",key,c->db->id);
       addReply(c, shared.cone);
       return;
   } else {
       // 设置键的过期时间
       // 如果服务器为附属节点,或者服务器正在载入,
       // 那么这个 when 有可能已经过期的
       setExpire(c->db,key,when);
       addReply(c,shared.cone);
       signalModifiedKey(c->db,key);
       notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,"expire",key,c->db->id);
       server.dirty++;
       return;
   }
}
 setExpire函数主要是对db->expires中的key对应的dictEntry设置过期时间。
/*
* 将键 key 的过期时间设为 when
*/
void setExpire(redisDb *db, robj *key, long long when) {
   dictEntry *kde, *de;
   /* Reuse the sds from the main dict in the expire dict */
   // 取出键
   kde = dictFind(db->dict,key->ptr);
   redisAssertWithInfo(NULL,key,kde != NULL);
   // 根据键取出键的过期时间
   de = dictReplaceRaw(db->expires,dictGetKey(kde));
   // 设置键的过期时间
   // 这里是直接使用整数值来保存过期时间,不是用 INT 编码的 String 对象
   dictSetSignedIntegerVal(de,when);
}
复制代码

redis什么时候执行淘汰策略?

在redis中有三种删除的操作此策略

  • 定时删除:对于没有过期时间的key,时间到了,定时器任务立即执行删除因为要维护一个定时器,所以就会占用cpu资源,尤其是有过期时间的redis键越来越多损耗的性能就会线性上升
  • 惰性删除:每次只有在访问key的时候,才会检查key的过期时间,若是已经过期了就执行删除。这种情况只有在访问的时候才会删除,所以有可能有些过期的redis键一直不会被访问,就会一直占用redis内存
  • 定期删除:每隔一段时间,就会检查删除掉过期的key。这种方案相当于上述两种方案的折中,通过最合理控制删除的时间间隔来删除key,减少对cpu的资源的占用消耗,使删除操作合理化。

本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

相关文章
|
运维 NoSQL 测试技术
Redis:内存陡增100%深度复盘
本文深度分析了Redis内存陡增100%的一些细节和解决方案。
408 1
Redis:内存陡增100%深度复盘
|
3月前
|
存储 缓存 NoSQL
工作 10 年!Redis 内存淘汰策略 LRU 和传统 LRU 差异,还傻傻分不清
小富带你深入解析Redis内存淘汰机制:LRU与LFU算法原理、实现方式及核心区别。揭秘Redis为何采用“近似LRU”,LFU如何解决频率老化问题,并结合实际场景教你如何选择合适策略,提升缓存命中率。
457 3
|
5月前
|
存储 人工智能 自然语言处理
AI代理内存消耗过大?9种优化策略对比分析
在AI代理系统中,多代理协作虽能提升整体准确性,但真正决定性能的关键因素之一是**内存管理**。随着对话深度和长度的增加,内存消耗呈指数级增长,主要源于历史上下文、工具调用记录、数据库查询结果等组件的持续积累。本文深入探讨了从基础到高级的九种内存优化技术,涵盖顺序存储、滑动窗口、摘要型内存、基于检索的系统、内存增强变换器、分层优化、图形化记忆网络、压缩整合策略以及类操作系统内存管理。通过统一框架下的代码实现与性能评估,分析了每种技术的适用场景与局限性,为构建高效、可扩展的AI代理系统提供了系统性的优化路径和技术参考。
305 4
AI代理内存消耗过大?9种优化策略对比分析
|
4月前
|
存储 缓存 人工智能
Redis六大常见命令详解:从set/get到过期策略的全方位解析
本文将通过结构化学习路径,帮助读者实现从命令语法掌握到工程化实践落地的能力跃迁,系统性提升 Redis 技术栈的应用水平。
|
4月前
|
机器学习/深度学习 监控 安全
解密虚拟化弹性内存:五大核心技术与实施策略
本文深入解析虚拟化环境中实现内存弹性管理的五大核心技术与实施策略。内容涵盖内存架构演进、关键技术原理、性能优化方法及典型问题解决方案,助力提升虚拟机密度与资源利用率。
227 0
|
4月前
|
存储 NoSQL 算法
应对Redis中的并发冲突:有效解决策略
以上策略各有优劣:乐观锁和悲观锁控制得当时可以很好地解决并发问题;发布/订阅模式提高了实时响应能力;Lua脚本和Redis事务保证了命令序列的原子性;分布式锁适合跨节点的并发控制;限流措施和持久化配置从系统设计层面减少并发风险;数据分片通过架构上的优化减轻单个Redis节点的负担。正确选择适合自己应用场景的策略,是解决Redis并发冲突的关键。
301 0
|
4月前
|
边缘计算 算法 Java
Java 绿色计算与性能优化:从内存管理到能耗降低的全方位优化策略与实践技巧
本文探讨了Java绿色计算与性能优化的技术方案和应用实例。文章从JVM调优(包括垃圾回收器选择、内存管理和并发优化)、代码优化(数据结构选择、对象创建和I/O操作优化)等方面提出优化策略,并结合电商平台、社交平台和智能工厂的实际案例,展示了通过Java新特性提升性能、降低能耗的显著效果。最终指出,综合运用这些优化方法不仅能提高系统性能,还能实现绿色计算目标,为企业节省成本并符合环保要求。
183 0
|
6月前
|
存储 监控 NoSQL
流量洪峰应对术:Redis持久化策略与内存压测避坑指南
本文深入解析Redis持久化策略与内存优化技巧,涵盖RDB快照机制、AOF重写原理及混合持久化实践。通过实测数据揭示bgsave内存翻倍风险、Hash结构内存节省方案,并提供高并发场景下的主从复制冲突解决策略。结合压测工具链构建与故障恢复演练,总结出生产环境最佳实践清单。
223 9
|
7月前
|
缓存 NoSQL 关系型数据库
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?