Redis缓存何以一枝独秀？ —— 聊聊Redis的数据过期数据淘汰以及数据持久化的实现机制

Posted 2023-02-22

大家好，又见面了。

---

---

上一篇文章中呢，我们简单的介绍了下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（指定时间未使用再过期）的方式来过期清理，如用户鉴权场景：

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

实现缓存的续期

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

expire key1 30

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

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

对于上面说的用户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当做一个容器，容器已满的情况下继续往里面放东西，应对之法其实就两种：

1. 直接拒绝放入。

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

遵循上述认知，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里进行淘汰

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

• 从全量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操作的触发只有两个场景：

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

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

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

1. 客户端手动命令触发bgsave操作
2. 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命令执行效率的影响。

• no

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

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

1. AOF写入的方式类似与日志打印，将请求追加写入到磁盘文件中，文本文件未经过压缩，时间久了之后会占据大量磁盘空间，易造成磁盘满的问题。
2. 在需要从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文件实际上由两部分内容组成。如下图所示：

通过RDB + AOF混合的策略，很好的实现了两者的优势互补：

1. 先通过AOF的方式记录命令，达到门槛的时候才执行rewrite操作生成RDB，最大限度降低了RDB执行频率，降低了对redis业务命令处理过程的影响。
2. 通过RDB的方式替代了前期大量的AOF命令存储，有效的降低了磁盘占用。
3. 通过RDB + AOF的方式，系统重建缓存的时候，先加载RDB文件完成主体数据的重建，然后在此基础上重放AOF增量命令，大大降低了启动时AOF重放的耗时。

小结回顾

好啦，关于Redis的数据过期设定、数据淘汰机制以及数据持久化策略等方面的问题，就讨论到这里了。那么你对Redis是否有了新的了解呢？你觉得Redis的哪个方面特性最打动了你呢？欢迎评论区一起交流下，期待和各位小伙伴们一起切磋、共同成长。