Redis内存满了怎么办?

 我来答 举报
隐曼情3
2022-06-23 · TA获得超过2940个赞
知道小有建树答主
回答量:3848
采纳率:99%
帮助的人:190万
展开全部

长期把Redis做缓存用,总有一天Redis内存会满的,怎么处理呢?

在Redis的配置文件 redis.conf 文件中,配置 maxmemory 的大小参数如下所示:


倘若实际的存储中超出了Redis的配置参数的大小时,Redis中有 淘汰策略 ,把 需要淘汰的key给淘汰掉,整理出干净的一块内存给新的key值使用

Redis提供了 6种的淘汰策略 ,其中默认的是 noeviction ,这6中淘汰策略如下:


LRU(Least Recently Used) 即表示最近最少使用,也就是在最近的时间内最少被访问的key,算法根据数据的历史访问记录来进行淘汰数据。

它的核心的思想就是: 假如一个key值在最近很少被使用到,那么在将来也很少会被访问

实际上Redis实现的LRU并不是真正的LRU算法,也就是名义上我们使用LRU算法淘汰键,但是实际上被淘汰的键并不一定是真正的最久没用的。

Redis使用的是近似的LRU算法, 通过随机采集法淘汰key,每次都会随机选出5个key,然后淘汰里面最近最少使用的key

这里的5个key只是默认的个数,具体的个数也可以在配置文件中进行配置,在配置文件中的配置如下图所示:


当近似LRU算法取值越大的时候就会越接近真实的LRU算法,可以这样理解,因为 取值越大那么获取的数据就越全,淘汰中的数据的就越接近最近最少使用的数据

那么为了实现根据时间实现LRU算法,Redis必须为每个key中额外的增加一个内存空间用于存储每个key的时间,大小是3字节。

在Redis 3.0中对近似的LRU算法做了一些优化,Redis中会维护大小是 16 的一个候选池的内存。

当第一次随机选取的采样数据,数据都会被放进候选池中,并且候选池中的数据会根据时间进行排序。

当第二次以后选取的数据,只有 小于候选池内的最小时间 的才会被放进候选池中。

当某一时刻候选池的数据满了,那么时间最大的key就会被挤出候选池。当执行淘汰时,直接从候选池中选取最近访问时间最小的key进行淘汰。

这样做的目的就是选取出最近似符合最近最少被访问的key值,能够正确的淘汰key值,因为随机选取的样本中的最小时间可能不是真正意义上的最小时间。

但是LRU算法有一个弊端:就是假如一个key值在以前都没有被访问到,然而最近一次被访问到了,那么就会认为它是热点数据,不会被淘汰。

然而有些数据以前经常被访问到,只是最近的时间内没有被访问到,这样就导致这些数据很可能被淘汰掉,这样一来就会出现误判而淘汰热点数据。

于是在Redis 4.0的时候除了LRU算法,新加了一种LFU算法, 那么什么是LFU算法算法呢?


LFU(Least Frequently Used) 即表示最近频繁被使用,也就是最近的时间段内,频繁被访问的key,它以最近的时间段的被访问次数的频率作为一种判断标准。

它的核心思想就是:根据key最近被访问的频率进行淘汰,比较少被访问的key优先淘汰,反之则优先保留。

LFU算法反映了一个key的热度情况,不会因为LRU算法的偶尔一次被访问被认为是热点数据。

在LFU算法中支持 volatile-lfu 策略和 allkeys-lfu 策略。


在Redis种有三种删除的操作此策略,分别是:


在Redis中持久化的方式有两种 RDB 和 AOF

在RDB中是以快照的形式获取内存中某一时间点的数据副本,在创建RDB文件的时候可以通过 save 和 bgsave 命令执行创建RDB文件。

这两个命令都不会把过期的key保存到RDB文件中 ,这样也能达到删除过期key的效果。

当在启动Redis载入RDB文件的时候, Master 不会把过期的key载入,而 Slave 会把过期的key载入。

在AOF模式下,Redis提供了Rewite的优化措施,执行的命令分别是 REWRITEAOF 和 BGREWRITEAOF , 这两个命令都不会把过期的key写入到AOF文件中,也能删除过期key


RDB 是一种快照存储持久化方式,具体就是将 Redis 某一时刻的内存数据保存到硬盘的文件当中,默认保存的文件名为 dump.rdb ,而在 Redis 服务器启动时,会重新加载 dump.rdb 文件的数据到内存当中恢复数据

开启RBD持久化方式

开启 RDB 持久化方式很简单,客户端可以通过向 Redis 服务器发送 save 或 bgsave 命令让服务器生成 rdb 文件,或者通过服务器配置文件指定触发 RDB 条件。


save 命令是一个同步操作。


当客户端向服务器发送 save 命令请求进行持久化时,服务器会阻塞 save 命令之后的其他客户端的请求,直到数据同步完成。


与 save 命令不同, bgsave 命令是一个异步操作。






当客户端发服务发出 bgsave 命令时, Redis 服务器主进程会 forks 一个子进程来数据同步问题,在将数据保存到rdb文件之后,子进程会退出。

所以,与 save 命令相比, Redis 服务器在处理 bgsave 采用子线程进行IO写入,而主进程仍然可以接收其他请求,但 forks 子进程是同步的,所以 forks 子进程时,一样不能接收其他请求,这意味着,如果forks一个子进程花费的时间太久(一般是很快的),bgsave命令仍然有阻塞其他客户的请求的情况发生。


除了通过客户端发送命令外,还有一种方式,就是在 Redis 配置文件中的 save 指定到达触发RDB持久化的条件,比如【多少秒内至少达到多少写操作】就开启 RDB 数据同步。

例如我们可以在配置文件redis.conf指定如下的选项:


之后在启动服务器时加载配置文件。


这种通过服务器配置文件触发RDB的方式,与bgsave命令类似,达到触发条件时,会forks一个子进程进行数据同步,不过最好不要通过这方式来触发RDB持久化,因为设置触发的时间太短,则容易频繁写入rdb文件,影响服务器性能,时间设置太长则会造成数据丢失。


介绍了三种让服务器生成rdb文件的方式,无论是由主进程生成还是子进程来生成,其过程如下:


Redis 的另外一个持久化方式: AOF(Append-only file) 。

与 RDB 存储某个时刻的快照不同, AOF 持久化方式会记录客户端对服务器的每一次写操作命令,并将这些写操作以 Redis 协议追加保存到以后缀为 aof 文件末尾,在Redis服务器重启时,会加载并运行 aof 文件的命令,以达到恢复数据的目的。


Redis默认不开启AOF持久化方式,我们可以在配置文件中开启并进行更加详细的配置,如下面的redis.conf文件:


在上面的配置文件中,我们可以通过 appendfsync 选项指定写入策略,有三个选项


客户端的每一个写操作都保存到 aof 文件当,这种策略很安全,但是每个写请注都有IO操作,所以也很慢。


appendfsync 的默认写入策略,每秒写入一次 aof 文件,因此,最多可能会丢失1s的数据。


Redis 服务器不负责写入 aof ,而是交由操作系统来处理什么时候写入 aof 文件。更快,但也是最不安全的选择,不推荐使用。


AOF将客户端的每一个写操作都追加到 aof 文件末尾,比如对一个key多次执行incr命令,这时候, aof 保存每一次命令到aof文件中,aof文件会变得非常大。


aof文件太大,加载aof文件恢复数据时,就会非常慢,为了解决这个问题,Redis支持aof文件重写,通过重写aof,可以生成一个恢复当前数据的最少命令集,比如上面的例子中那么多条命令,可以重写为:


通过在redis.conf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写,这种方式会在每次fsync时都重写,影响服务器性能,因此默认值为no,不推荐使用。


客户端向服务器发送bgrewriteaof命令,也可以让服务器进行AOF重写。


AOF重写方式也是异步操作,即如果要写入aof文件,则Redis主进程会forks一个子进程来处理,如下所示:



在写入aof日志文件时,如果Redis服务器宕机,则aof日志文件文件会出格式错误,在重启Redis服务器时,Redis服务器会拒绝载入这个aof文件,可以通过以下步骤修复aof并恢复数据。


AOF只是追加日志文件,因此对服务器性能影响较小,速度比RDB要快,消耗的内存较少。


我们可以从几个方面对比一下RDB与AOF,在应用时,要根本自己的实际需求,选择RDB或者AOF,其实,如果想要数据足够安全,可以两种方式都开启,但两种持久化方式同时进行IO操作,会严重影响服务器性能,因此有时候不得不做出选择。


当RDB与AOF两种方式都开启时,Redis会优先使用AOF日志来恢复数据,因为AOF保存的文件比RDB文件更完整。

抢首赞 已赞过 已踩过<
你对这个回答的评价是?
评论 举报 收起
推荐律师服务: 若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询

为你推荐:

下载百度知道APP,抢鲜体验
使用百度知道APP,立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。
扫描二维码下载
×

类别

我们会通过消息、邮箱等方式尽快将举报结果通知您。

说明

0/200

提交
取消

辅 助

模 式