【Redis】数据过期策略和数据淘汰策略

数据过期策略和淘汰策略

过期策略

Redis所有的数据结构都可以设置过期时间，时间一到，就会自动删除。

问题：大家都知道，Redis是单线程的，如果同一时间太多key过期，Redis删除的时间也会占用线程的处理时间，如果删除的太过于频繁，会不会导致线上读写指令出现卡顿？

这些问题Redis作者 Antirez 早就想到了，所以在过期这件事上，Redis非常小心 。

两种删除策略：

• 定时扫描策略：集中处理
• 惰性删除策略：零散处理

定时扫描策略

redis将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定时遍历这个字典来删除到期的key。

具体流程：

Redis默认会每秒进行十次过期扫描，过期扫描不会遍历过期字典中所有的key，而是采用了一种简单的贪心策略。

1. 从过期字典中随机选择20个key
2. 删除这20个key中已经过期的key
3. 如果过期的key比率超过1/4，那就重复步骤1

同时，为了保证过期扫描不会出现循环过度，导致线程卡死现象，算法还增加了扫描时间的上限，默认不会超过25ms。

问题：设想一个大型的Redis实例中所有的key在同一时间过期了，会出现怎样的结果？

毫无疑问，Redis会持续扫描过期字典（循环多次），直到过期字典中过期的 key 变得稀疏，才会停止（循环次数明显下降）。这就会导致线上读写请求出现明显卡顿现象。导致这种卡顿的另外一种原因是内存管理器需要频繁回收内存页，这也会产生一定的CPU消耗。

但是我们不是已经有25ms的时间上限了么，怎么会导致卡顿呢？

eg ：
假如有101个客户端同时将请求发过来了，然后前100个请求的执行时间都是25ms，那么第101个指令需要等待多久才能执行？

答案：2500ms，这个就是客户端的卡顿时间，是由服务器不间断的小卡顿积少成多导致的。

所以业务开发人员一定要注意过期时间，如果有大批量的key过期，要给过期时间设置一个随机范围，而不能全部在同一时间过期。

在目标过期时间上增加一天的随机时间

redis.expire_at(key, random.randint(86400) + expire_ts)

优点：可以保证过期key会被尽快删除，也就是内存可以尽快地被释放。因此，定时删除策略对内存来说是比较友好的。

缺点：在过期key比较多的情况下，删除过期key可能会占用相当一部分CPU时间，在内存不紧张但CPU时间紧张的情况下，将CPU时间用于删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响。所以，定时删除策略对CPU不友好。

惰性删除策略

惰性删除策略就是在客户端访问这个key的时候，redis对key的过期时间进行检查，如果过期了就立即删除。

优点：因为每次访问时，才会检查key是否过期，所以此策略只会使用很少的系统资源，因此，惰性删除策略会节约CPU性能。

缺点：内存压力很大，出现长期占用内存的数据。

淘汰策略

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

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

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

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

Redis内存淘汰策略有哪些？

不进行数据淘汰的策略

noeviction(Redis3.0之后，默认的内存淘汰策略)：它表示当运行内存超过最大设置内存时， 不淘汰任何数据，这时如果有新的数据写入，会报错通知禁止写入，不淘汰任何数据，但是如果没用数据写入的话，只是单纯的查询或者删除操作的话，还是可以正常工作。

进行数据淘汰的策略

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

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

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

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

如何修改Redis内存淘汰策略？

设置内存淘汰策略的两种方法：

• 方式一：通过config set maxmemory-policy <策略>命令设置。它的优点是设置之后立即生效，不需要重启Redis服务，缺点是重启Redis之后，设置就会失效。
• 方式二：通过修改Redis配置文件修改，设置maxmemory-policy <策略>，它的优点是重启Redis服务后配置不会丢失，缺点是必须重启Redis服务，设置才能生效。

LRU算法和LFU算法有什么区别？

什么是LRU算法？

LRU 全称是 Least Recently Used翻译为最近最少使用，会选择淘汰最近最少使用的数据。

传统的 LRU 算法的实现是基于【链表】结构，链表中的元素按照操作顺序从前往后排列，最新操作的键会被移动到表头，当需要内存淘汰时，只需要删除链表尾部的元素即可，因为链表尾部的元素就代表最久未被使用的元素。

Redis并没有使用这样的方式实现LRU算法，因为传统的LRU算法存在两个问题：

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

Redis是如何实现LRU算法的？

Redis 实现的是一种近似LRU算法，目的是为了更好的节约内存，它的实现方式是在Redis的对象结构体中添加一个额外的字段，用于记录此数据的最后一次访问时间。

当Redis 进行内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值（个数可配置），然后淘汰最久没有使用的那个。

Redis实现的LRU算法的优点：

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

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

因此，在Redis 4.0 之后引入了LFU算法来解决这个问题。

什么时LFU算法？

LFU全程是 Least Frequently Used翻译为最近最不常用，LFU算法是根据数据访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。

所以，LFU算法会记录每个数据的访问次数。当一个数据被再次访问时，就会增加该数据的访问次数。这样就解决了偶尔被访问一次之后，数据留存在缓存中很长一段时间的问题，相比于LRU算法也更合理一些。

实现：

typedef struct redisObject {
    ...
      
    // 24 bits，用于记录对象的访问信息
    unsigned lru:24;  
    ...
} robj;
1
2
3
4
5
6
7

Redis 对象头中的 lru 字段，在 LRU 算法下和 LFU 算法下使用方式并不相同。

在 LRU 算法中，Redis 对象头的 24 bits 的 lru 字段是用来记录 key 的访问时间戳，因此在 LRU 模式下，Redis可以根据对象头中的 lru 字段记录的值，来比较最后一次 key 的访问时间长，从而淘汰最久未被使用的 key。

在 LFU 算法中，Redis对象头的 24 bits 的 lru 字段被分成两段来存储，高 16bit 存储 ldt(Last Decrement Time)，低 8bit 存储 logc(Logistic Counter)。

• ldt 是用来记录 key 的访问时间戳；
• logc 是用来记录 key 的访问频次，它的值越小表示使用频率越低，越容易淘汰，每个新加入的 key 的logc 初始值为 5。

注意，logc 并不是单纯的访问次数，而是访问频次（访问频率），因为 logc 会随时间推移而衰减的。

在每次 key 被访问时，会先对 logc 做一个衰减操作，衰减的值跟前后访问时间的差距有关系，如果上一次访问的时间与这一次访问的时间差距很大，那么衰减的值就越大，这样实现的 LFU 算法是根据访问频率来淘汰数据的，而不只是访问次数。访问频率需要考虑 key 的访问是多长时间段内发生的。key 的先前访问距离当前时间越长，那么这个 key 的访问频率相应地也就会降低，这样被淘汰的概率也会更大。

对 logc 做完衰减操作后，就开始对 logc 进行增加操作，增加操作并不是单纯的 + 1，而是根据概率增加，如果 logc 越大的 key，它的 logc 就越难再增加。

所以，Redis 在访问 key 时，对于 logc 是这样变化的：

1. 先按照上次访问距离当前的时长，来对 logc 进行衰减；
2. 然后，再按照一定概率增加 logc 的值

redis.conf 提供了两个配置项，用于调整 LFU 算法从而控制 logc 的增长和衰减：

• lfu-decay-time 用于调整 logc 的衰减速度，它是一个以分钟为单位的数值，默认值为1，lfu-decay-time 值越大，衰减越慢；
• lfu-log-factor 用于调整 logc 的增长速度，lfu-log-factor 值越大，logc 增长越慢。