Redis 内存

使用 redis-cli 登录到 Redis Server，执行 info 命令, 其中 '# Memory' 段落部分就是 Redis 内存的使用情况，例如：

这个在配置文件中:

Redis 支持运行时通过命令动态修改内存大小

既然可以设置 Redis 最大占用内存大小，那么配置的内存就有用完的时候。那在内存用完的时候，还继续往 Redis 里面添加数据不就没内存可用了吗？

实际上 Redis 定义了几种策略用来处理这种情况：

一种是写在配置文件中，redis.conf :

另一种是使用命令

上面说到了Redis可使用最大内存使用完了，是可以使用LRU算法进行内存淘汰的，那么什么是LRU算法呢？

近似LRU算法

Redis使用的是近似LRU算法，它跟常规的LRU算法还不太一样。近似LRU算法通过随机采样法淘汰数据，每次随机出5（默认）个key，从里面淘汰掉最近最少使用的key。

Redis为了实现近似LRU算法，给每个key增加了一个额外增加了一个24bit的字段，用来存储该key最后一次被访问的时间。

Redis3.0对近似LRU的优化

Redis3.0对近似LRU算法进行了一些优化。新算法会维护一个候选池（大小为16），池中的数据根据访问时间进行排序，第一次随机选取的key都会放入池中，随后每次随机选取的key只有在访问时间小于池中最小的时间才会放入池中，直到候选池被放满。当放满后，如果有新的key需要放入，则将池中最后访问时间最大（最近被访问）的移除。

当需要淘汰的时候，则直接从池中选取最近访问时间最小（最久没被访问）的key淘汰掉就行。

LFU 算法是Redis4.0里面新加的一种淘汰策略。它的全称是Least Frequently Used，它的核心思想是根据key的最近被访问的频率进行淘汰，很少被访问的优先被淘汰，被访问的多的则被留下来。

LFU算法能更好的表示一个key被访问的热度。假如你使用的是LRU算法，一个key很久没有被访问到，只刚刚是偶尔被访问了一次，那么它就被认为是热点数据，不会被淘汰，而有些key将来是很有可能被访问到的则被淘汰了。如果使用LFU算法则不会出现这种情况，因为使用一次并不会使一个key成为热点数据。

LFU一共有两种策略：

参考文档: 面试官：Redis 内存数据满了，会宕机吗？

封面图片来源: http://download.redis.io/logocontest/

在客户端通过 redis-cli 连接服务器后，输入 info memory 命令会显示 Redis 系统关于存储的统计信息，本文重点对 used_memory、used_memory_rss、mem_fragmentation_ratio 这三个词条做个详细的说明，欢迎大家批评讨论。

used_memory 为 Redis 内存分配器（如：jemalloc）分配的 内存总量 ，这些内存主要用于存储 Redis 实际运行时产生的数据。注意，这里说的内存总量包含 内存 和 虚拟内存 。

used_memory_rss 为 Redis 进程占据操作系统的内存，所以除了分配器分配的内存之外，还包括进程运行本身需要的内存、内存碎片等，但是 不包括虚拟内存 。

从 used_memory 和 used_memory_rss 的描述来看，它们之间孰大孰小不好确定，原因如下：

1.如果 used_memory 使用了虚拟内存，如果虚拟内存使用量超过 Redis进程本身占用内存大小 + 程序内存碎片 ，则 used_memory 值可能大于 used_memory_rss。

2.used_memory_rss 本身包含Redis系统进程占据的内存，还有程序运行产生的内存碎片，如果used_memory未占用或占用少量虚拟内存，则与上一条相反，used_memory_rss 值可能大于 used_memory。

这二者的大小关系可以从侧面体现 Redis 系统的运行状态，这就引出了第三个词条 mem_fragmentation_ratio 。

mem_fragmentation_ratio 为 used_memory_rss / used_memory 的比值。根据前面对 used_memory_rss 和 used_memory 含义的描述，很容易得出以下结论：

长期把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文件更完整。

---