聊聊Redis的数据过期、数据淘汰以及数据持久化的实现机制

大家好，又见面了。

本文是笔者输出的缓存专栏系列内容，将会通过系列专题，讲清楚缓存的方方面面。如果感兴趣，欢迎关注以获取后续更新。

上一篇文章中呢，我们简单的介绍了下Redis的整体情况。作为集中式缓存的优秀代表，Redis可以帮助我们在项目中完成很多特定的功能。Redis准确的说是一个非关系型数据库，但是由于其超高的并发处理性能，及其对于缓存场景所提供的一系列能力构建，使其成为了分布式系统中的集中缓存的绝佳选择。

Redis对于缓存能力场景的支持，除了基础的缓存增删改查，还支持对记录的过期时间设定，支持多种不同的数据淘汰策略等等。此外为了解决内存型组件数据可靠性问题，还提供了一系列的数据持久化方案。

本篇文章中，我们就一起聊一聊这方面内容。

数据过期能力

为了节约内存的使用量，保证有限的内存空间能够被更有价值的数据使用，所以很多内存缓存组件都会支持数据过期能力。之前我们提过的本地缓存组件Guava Cache、Caffeine等支持基于缓存容器对象级别设置统一的过期时间，而Redis则支持对每条记录设定单独的过期时间。

创建时设定过期时间

可以在创建记录的时候指定过期时间，redis提供了setex命令可以实现插入的时候同步指定过期时间。比如：

setex key1 5 value1

上述命令实现了往redis中写入一个key1记录，并同时设定了5s后过期。如果在JAVA SpringBoot项目中可以直接使用相关API接口来实现：

stringRedisTemplate.opsForValue().set("key1", "value1", 5, TimeUnit.SECONDS);

这样缓存写入5s之后，缓存记录就会过期失效。描述到这里可以看出，这是一种基于创建时间来判定是否过期的机制，也即常规上说的TTL策略，当设定了过期时间之后不管有没有被使用都会到期被强制清理掉。但有很多场景下也会期望数据能够按照TTI（指定时间未使用再过期）的方式来过期清理，如用户鉴权场景：

假设用户登录系统后生成token并存储到Redis中，指定token有效期30分钟，那么如果用户一直在使用系统的时候突然时间到了然后退出要求重新登录，这个体验感就会很差。正确的预期应该是用户连续操作的时候就不要退出登录，只有连续30分钟没有操作的时候才过期处理。

略有遗憾的是，Redis并不支持按照TTI机制来做数据过期处理。但是作为补偿，Redis提供了一个重新设定某个key值过期时间的方法，可以通过expire方法来实现指定key的续期操作，以一种曲线救国的方式满足诉求。

实现缓存的续期

通过expire命令，可以对已有的记录重新设定过期时间，如果此前已经有设定了过期时间，则覆盖原先的过期时间。

expire key1 30

执行上述命令，可以将key1的过期时间给重新设定为30s,不管此前是否有过期时间。同样地，在代码中也可以方便的实现这一命令：

stringRedisTemplate.expire("key1", 30, TimeUnit.SECONDS);

对于上面说的用户token续期的诉求，可以这样来操作：

用户首次登录成功后，会生成一个token令牌，然后将令牌与用户信息存储到redis中，设定30分钟有效期。
每次请求接口中携带token来鉴权，每次get请求的时候，就重新通过expire操作将token的过期时间重新设定为30分钟。
持续30分钟无请求后，此条token缓存信息过期失效。

同样实现了TTI的效果。

实现指定时刻过期

Redis的过期时间设定，是基于当前命令执行时刻开始的相对过期时间，只能设定距离当前多久后失效，如果想要实现在固定时刻失效，还需要调用端执行一点小小的换算处理来实现。

public void test() {
    LocalDateTime dateTime = LocalDateTime.parse("2022-11-23 22:00:00", DateTimeFormatter.ofPattern("yyyy-MM-dd " +
            "HH:mm:ss"));
    Date date = Date.from(dateTime.atZone(ZoneId.systemDefault()).toInstant());
    long expireTimeLong = date.getTime() - System.currentTimeMillis();
    stringRedisTemplate.expire("key1", expireTimeLong, TimeUnit.MILLISECONDS);
}

通过计算出目标时刻与当前时刻的时间差值，作为过期时间设定到记录上，即可。

数据淘汰策略

前面强调过，Redis是一个基于内存的缓存数据库，而内存的容量通常是有限的。虽然Reids有提供数据过期处理逻辑，但是当数据量特别多的时候就需要数据淘汰机制来兜底了。

这里数据淘汰策略与数据过期两个概念的差异要先弄清楚：

数据过期，是符合业务预期的一种数据删除机制，为记录设定过期时间，过期后从缓存中移除。
数据淘汰，是一种“有损自保”的降级策略，是业务预期之外的一种数据删除手段。指的是所存储的数据没达到过期时间，但缓存空间满了，对于新的数据想要加入内存时，为了避免OOM而需要执行的一种应对策略。

试想下，把Redis当做一个容器，容器已满的情况下继续往里面放东西，应对之法其实就两种：

直接拒绝放入。
扔掉容器中部分已有内容，腾出空间接纳新内容放入。

遵循上述认知，Redis提供了6种不同的数据淘汰机制，供使用方按需选择，将有限的空间仅用来存储热点数据，实现缓存的价值最大化。如下：

对几种策略具体含义梳理归纳如下表所示：

数据淘汰策略	具体含义说明
noeviction	淘汰新进入的数据，即拒绝新内容写入缓存，直到缓存有新的空间。
allkeys-lru	将内存中已有的key内容按照`LRU策略`将最久没有使用的记录淘汰掉，然后腾出空间用来存放新的记录。
volatile-lru	从设置了过期时间的key里面按照LRU策略，淘汰掉最久没有使用的记录。与allkeys-lru相比，这种方式仅会在设定了过期时间的key里面进行淘汰。
allkeys-random	从已有的所有key里面随机剔除部分，腾出空间容纳新数据。
volatile-random	从已有的设定了过期时间的key里面随机剔除部分，腾出空间容纳新的数据
volatile-ttl	从已有的设定了过期时间的key里面，将最近将要过期的数据提前剔除掉，与volatile-lru的区别在于排序逻辑不一样，一个基于ttl规则排序，一个基于lru策略排序。

从上述策略里面可以看出，根据LRU和Random两种操作的范围不同，各自又细分了两种不同的执行策略。

从设定过期时间的key里进行淘汰

相对来说，设定了过期时间的数据，说明业务层面已经默许了其可以被删除，所以即使被提前淘汰了，对业务层面的影响也是比较小的。

系统中缓存最近30分钟的用户浏览历史记录，即使这些数据被删除淘汰，对系统主体功能而言，不会受损。

从全量key里面执行淘汰

从全量数据里面执行淘汰，就有可能淘汰掉没有设置过期时间的key记录。未设置过期时间的数据如果数据被淘汰掉，很有可能会影响业务的运行逻辑逻辑正确性。

缓存中存储了系统内的黑名单用户列表，用户鉴权的时候，会判断用户是否在黑名单中，如果在黑名单中则禁止登录。这个黑名单是永久的，不会自己解封。如果由于被动淘汰策略触发删除部分黑名单，那原先的黑名单用户就会不受限制而进入到系统中，导致预期之外的情况发生。

不得不说，Redis的这一细分处理原则，还是很贴心的。具体实践中，可以根据自身系统内存储的数据体量以及存储的数据内容性质，选择合适的数据淘汰策略。

数据持久化方案

除了容量有限之外，存储在内存中的数据最大的风险点是什么？数据丢失！

因为内存中的数据是非持久化存储的，一旦断电或者出现系统异常等情况，很容易导致内存数据丢失。所以大部分的系统里面都只是将内存型缓存用作数据库的辅助扛压，最终的数据存储在DB等可以持久化存储容器中，同步一份数据到缓存中用于并发场景下的业务使用。

这种组网场景下，Redis的数据其实是没有持久化的诉求的，因为Redis中数据仅仅是一份副本，最终数据在DB中都有。即使系统异常或者掉电重启，也可以基于数据库的数据进行缓存重建 —— 最多就是数据量特别巨大的时候，重建缓存的耗时会比较长。

另外一种场景，业务里面会有有些写操作会比较频繁、强依赖Redis特性来实现的功能，这部分数据不能丢、但又没有重要到必须每次更新都需要存入DB的地步。比如博客系统中的文章阅读量数据，文章每次被读取都需要更新阅读数，写操作非常频繁，如果阅读量存储到DB中，会导致DB压力较大，这种情况就希望可以将数据存储在内存中，然后内存数据可以持久化保存。

Redis提供了多种持久化方案，可以实现将内存数据定期存储到磁盘上，重启时候可以从磁盘加载到内存中，以此来避免数据的丢失。

下面一起看下。

RDB全量持久化模式

全量模式很好理解，就是定时将当前内存里面所有的key-value键值对内容，全部导出一份快照数据存储到磁盘上。这样下次如果需要使用的时候，就可以从磁盘上加载快照文件，实现内存数据的恢复。

RDB全量模式持久化将数据写入磁盘的动作可以分为SAVE与BGSAVE两种。所谓BGSAVE就是background-save，也就是后台异步save，区别点在于SAVE是由Redis的命令执行线程按照普通命令的方式去执行操作，而BGSAVE是通过fork出一个新的进程，在新的独立进程里面去执行save操作。

还记得前面文章中说的么？Redis的请求命令执行是通过单线程的方式执行的，所以要尽量避免耗时操作，而save动作需要将内存全部数据写入到磁盘上，对于redis而言，这一操作是非常耗时的，会阻塞住全部正常业务请求，所以save操作的触发只有两个场景：

客户端手动发送save命令执行
Redis在shutdown的时候自动执行

从数据保存完备性方面看，这两种方式都起不到自动持久化备份的能力，如果出现一些机器掉电等情况，是不会触发redis shutdown操作的，将面临数据丢失的风险。

相比而言，bgsave的杀伤力要小一些、适用度也更好一些，它可以保证在持久化期间Redis主进程可以继续处理业务请求。bgsave增加了过程中自动持久化操作的机制，触发条件更加的“智能”：

客户端手动命令触发bgsave操作
Redis配置定时任务触发（支持间隔时间+变更数据量双重维度综合判断，达到任一条件则触发）

此外，在master-slave主从部署的场景中还支持仅由slave节点触发bgsave操作，来降低对master节点的影响。值得注意的是，在fork子进程的时候需要将redis主进程中内存所有数据都复制一份到子进程中，所以bgsave操作实际上是将子进程内存中的数据快照导出到磁盘上，在执行期间对机器的剩余内存有较高要求，如果机器剩余内存不足，则可能导致fork的时候两份内存数据量超过机器物理内存大小，导致系统启用虚拟内存，拷贝速度大打折扣（虚拟内存本质上就是把磁盘当内存用，操作速度相比物理内存大大降低），会阻塞住Redis主进程的命令执行。

如果开启了RDB的bgsave定时触发执行机制，在出现异常掉电等情况，可能会丢失最后一部分尚未来及持久化的内容。在恢复的时候，Redis启动之后会先去读取RDB文件然后将其写入内存中恢复此前的缓存数据，数据恢复期间不受理外部业务请求。

AOF增量同步方式

RDB全量模式简单粗暴，直接将内存全量数据存储为快照序列化到本地。AOF（Append Only File）与RDB的思路不同，AOF更像是记录住Redis的每一次写请求执行命令，将每次执行的写操作命令记录存储到磁盘上，然后通过一种类似命令重放执行的方式，来实现数据的恢复。

AOF具体实现的时候，包含几种不同的策略：

always

可以简单的理解为每一条redis写请求执行的时候会触发一次磁盘写入操作，且只有在磁盘写入完成之后，请求的响应才会返回。这种方式可以保证AOF记录的准确性，但是会严重影响Redis的并发吞吐量。

every sec

异步执行，任务执行线程执行命令后将命令写入任务放入队列中，由子线程异步方式每秒一次将执行命令分批写入文件中，相比always方式在异常情况下可能会丢失最后1s的执行记录，但可以大大降低对redis命令执行效率的影响。

redis不控制落盘时间，由操作系统去决定什么时候该往磁盘flush，这种情况一般不推荐使用，无法准确掌控是否落盘，可靠性不够。

AOF的方式落盘持久化的时候，每次仅写入增量的部分，所以对系统整体运行期的影响较小，但随着系统在线运行时长的累加，AOF中存储的命令也越来越多，这样问题也随着出现：

AOF写入的方式类似与日志打印，将请求追加写入到磁盘文件中，文本文件未经过压缩，时间久了之后会占据大量磁盘空间，易造成磁盘满的问题。
在需要从AOF文件回放重新构建缓存内容时，可能会耗时较久（相当于要将长期累积下来的写操作命令逐个重新执行一下）。

RDB与AOF混合使用

从前面的介绍中可以看出：

RDB在过程中每次写磁盘的时候对Redis业务处理的性能影响较大，但是从磁盘加载到内存重建缓存的时候效率很高。
AOF通过增量的方式降低了运行过程中对Redis业务处理的影响，但是命令回放重建缓存的时候效率较差。

如果将两者结合起来使用，是否可以取长补短呢？事实似乎的确如此。从4.0版本开始，Redis支持了RDB + AOF的混合持久化方式，通过rewrite机制来实现。需要在redis的配置文件中开启对应开关：

aof-use-rdb-preamble yes

开启之后，redis在每次执行aof操作的时候会判断下是否达到了触发rewrite的条件，如果达到，则fork出一个新的子进程进行RDB操作将当前时刻全量内存数据生成RDB数据然后写入到AOF文件中，而后续的写操作命令则继续append方式追加记录到AOF文件中。这样一来AOF文件实际上由两部分内容组成。如下图所示：