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

数据过期策略和淘汰策略

过期策略

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

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

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

两种删除策略：

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

定时扫描策略

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

具体流程：

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

从过期字典中随机选择20个key
删除这20个key中已经过期的key
如果过期的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的时候，redis对key的过期时间进行检查，如果过期了就立即删除。

淘汰策略

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

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

在配置文件redis.conf中，可以通过参数maxmemory <bytes>来设定最大运行内存，只有在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;

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 是这样变化的：