Redis内存管理

Cutewr大约 9 分钟

Redis内存管理

讲一讲Redis的内存管理

给缓存数据设置过期时间，减少内存消耗。key过期后，采用对内存和CPU都相对友好的过期删除策略
当Redis的运行内存已经超过Redis设置的最大内存之后，执行相应的内存淘汰策略。

过期删除策略

设置过期时间的命令

expire key n：设置 key 在n 秒后过期，比如 expire key 100 表示设置 key 在100秒后过期；
pexpire key n：设置 key 在n 毫秒后过期，比如 pexpire key2 100000 表示设置 key2在100000 毫秒（100秒）后过期。
expireat key n ：设置key 在某个时间戳（精确到秒）之后过期，比如 expireat key3 1655654400 表示 key3 在时间戳1655654400 后过期（精确到秒）
pexpireat key n：设置key 在某个时间戳（精确到毫秒）之后过期，比如 pexpireat key4 1655654400000 表示 key4 在时间戳1655654400000 后过期（精确到毫秒）

当然，在设置键值对的时候，也可以同时对 key 设置过期时间，共有3种命令：

set key value ex n ：设置键值对的时候，同时指定过期时间（精确到秒）；
set key value px n ：设置键值对的时候，同时指定过期时间（精确到毫秒）；
setex key n valule ：设置键值对的时候，同时指定过期时间（精确到秒）。

在java中就是使用StringRedisTemplate的set方法，设置其中的超时时间参数

如何判断key已经过期了？

每当我们对一个 key 设置了过期时间时，Redis 会把该 key 带上过期时间存储到一个过期字典（expires dict）中。过期字典存储在 redisDb 结构中，如下：

过期字典的key 是一个指针，指向某个键对象；
过期字典的 value 是一个long long 类型的整数，这个整数保存了 key 的过期时间；

我们可以用0（1）的时间复杂度来快速查找某个key是否过期。当我们查询一个key ，Redis 首先检查该 key 是否存在于过期字典中：

如果不在，则正常读取键值；
如果存在，则会获取该key 的过期时间，然后与当前系统时间进行比对，如果比系统时间大，那就没有过期，否则判定该key 已过期。

过期删除策略有哪些？

有定时删除、惰性删除和定期删除。

定时删除策略的做法是，在设置 key 的过期时间时，同时创建一个定时事件，当到达过期时间时，由事件自动执行 key 的删除操作。定时删除策略的优点：可以保证过期 key 会被尽快删除，对内存友好。定时删除策略的缺点：在过期 key 比较多的情况下，删除过期 key 可能会占用相当一部分CPU时间，对 CPU 不友好。
惰性删除：不主动删除过期键，每次从数据库访问 key 时，都检测key 是否过期，如果过期则删除该key。惰性删除策略的优点：因为每次访问时，才会检查 key 是否过期，所以此策略只会使用很少的CPU资源，因此，惰性删除策略对 CPU 时间最友好。惰性删除策略的缺点：如果一个 key 已经过期，但是这个过期key 一直没有被访问，它所占用的内存就不会释放，造成了一定的内存空间浪费。
定期删除：每隔一段时间「随机」从数据库中取出一定数量的key 进行检查，并删除其中的过期key。定期删除策略的优点：通过限制删除操作执行的频率和时长，减少删除操作对 CPU 的影响；同时也能删除一部分过期的数据减少了过期键对空间的无效占用。定期删除策略的缺点：
1. 内存清理方面没有定时删除效果好，同时没有惰性删除使用的CPU资源少。
2. 难以确定删除操作执行的时长和频率。如果执行的太频繁，定期删除策略变得和定时删除策略一样，对CPU不友好；如果执行的太少，那又和惰性删除一样了，过期key 占用的内存不会及时得到释放。

Redis的过期删除策略是什么？

Redis采用的是惰性删除和定期删除搭配使用。

首先惰性删除，Redis 在访问或者修改key 之前，都会检查 key 是否过期：如果过期，则删除该 key，可以选择异步删除，还是同步删除，根据 lazyfree_lazy_expire 参数配置决定（Redis 4.0版本开始提供参数），然后返回 null给客户端；如果没有过期，返回正常的键值对给客户端；
1. 同步删除：就是在主线程中从字典中删除键值对并进行内存释放。
2. 异步删除：在主线程中解除键值对引用，判断对象大小，如果对象大于门限值，就会创建一个后台线程进行内存释放；如果对象较小直接在主内存中释放内存，这样可以避免异步操作带来的额外开销。
定期删除，Redis默认是一秒随机检查十次数据库，可以在配置文件中修改这个频率。每次检查，会随机选择20个key判断是否过期，定期删除是一个循环的过程：如果本次检查的过期key的数量超过五个，那么再进行随机抽取；如果小于5个，就停止，等待下一轮再检查。并且Redis 为了保证定期删除不会出现循环过度，导致线程卡死现象，为此增加了定期删除循环流程的时间上限，默认不会超过 25ms。

内存淘汰策略

过期删除策略，是删除已过期的key。

而当 Redis 的运行内存已经超过 Redis 设置的最大内存之后，则会使用内存淘汰策略删除符合条件的 key，以此来保障 Redis 高效的运行。

如何设置 Redis 最大运行内存？

在配置文件 redis.conf 中，可以通过参数 maxmemory bytes来设定最大运行内存，只有在 Redis 的运行内存达到了我们设置的最大运行内存，才会触发内存淘汰策略。不同位数的操作系统，maxmemory的默认值是不同的。

在64位操作系统中，maxmemory 的默认值是0，表示没有内存大小限制，那么不管用户存放多少数据到 Redis 中，Redis 也不会对可用内存进行检查，直到 Redis 实例因内存不足而崩溃也无作为。
在32位操作系统中，maxmemory 的默认值是 3G，因为32位的机器最大只支持4GB 的内存，而系统本身就需要一定的内存资源来支持运行，所以32位操作系统限制最大 3 GB 的可用内存是非常合理的，这样可以避免因为内存不足而导致 Redis 实例崩溃。

Redis 内存淘汰策略有哪些？

Redis 内存淘汰策略共有八种，这八种策略大体分为「不进行数据淘汰」和「进行数据淘汰」两类策略。 1、不进行数据淘汰的策略它表示当运行内存超过最大设置内存时，不淘汰任何数据，这时如果有新的数据写入，会报错通知禁止写入. 2、进行数据淘汰的策略针对「进行数据淘汰」这一类策略，又可以细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略。

在设置了过期时间的数据中进行淘汰：

volatile-random：随机淘汰设置了过期时间的任意键值；
volatile-ttl：优先淘汰更早过期的键值。
volatile-Iru （Redis3.0之前，默认的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最久未使用的键值；
volatile-Ifu（Redis 4.0后新增的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最少使用的键值；

在所有数据范围内进行淘汰：

allkeys-random：随机淘汰任意键值；
allkeys-Iru：淘汰整个键值中最久未使用的键值；
allkeys-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰整个键值中最少使用的键值。

Redis是如何实现LRU算法的？

LRU 是最近最少使用，会选择淘汰最近最少使用的数据。传统LRU 算法的实现是基于「链表」结构，链表中的元素按照操作顺序从前往后排列，最新操作的键会被移动到表头，当需要内存淘汰时，只需要删除链表尾部的元素即可，因为链表尾部的元素就代表最久未被使用的元素。 Redis 并没有使用这样的方式实现LRU 算法，因为传统的LRU 算法存在两个问题：

需要用链表管理所有的缓存数据，这会带来额外的空间开销；
当有数据被访问时，需要在链表上把该数据移动到头端，如果有大量数据被访问，就会带来很多链表移动操作，会很耗时，进而会降低 Redis 缓存性能。

Redis 的实现方式是在 Redis 的对象结构体中添加一个额外的字段，用于记录此数据的最后一次访问时间。当 Redis 进行内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5个值（此值可配置），然后淘汰最久没有使用的那个。 Redis 实现的 LRU 算法的优点：

不用为所有的数据维护一个大链表，节省了空间占用；
不用在每次数据访问时都移动链表项，提升了缓存的性能；

但是LRU算法有一个问题，无法解决缓存污染问题，比如应用一次读取了大量的数据，而这些数据只会被读取这一次，那么这些数据会留存在 Redis 缓存中很长一段时间，造成缓存污染。因此，在 Redis 4.0 之后引入了 LFU 算法来解决这个问题。

Redis是如何实现LFU算法的？

LFU：淘汰最近最不常用的数据。这样就能解决数据偶尔被访问一次，就留在缓存中很久的问题。

还是在redis对象中的lru字段记录的。在lru算法中，24bit都用来记录最后一次访问key的时间；在lfu算法中，高16位存储key的访问时间，低8位存储key的访问频次，这个访问频次并不是单纯的访问次数，它会随时间推移而减小。访问key时增加访问频次也不是+1，而是根据概率增加，对于访问频次越大的key，就越难再增加。