Redis过期策略和持久化机制全面揭秘，教你如何合理配置

我是小酒

已于 2023-07-08 14:21:08 修改

阅读量343

点赞数 1

分类专栏：【缓存相关】文章标签： redis 数据库缓存热门文章原力计划

于 2023-07-08 11:44:06 首次发布

本文链接：https://blog.csdn.net/Goligory/article/details/131609941

版权

【缓存相关】专栏收录该内容

4 篇文章 0 订阅

订阅专栏

告诉大家一个秘密，，，我今天加班了……哈哈，欢迎来到-->英雄联盟

下面给大家介绍下Redis的过期策略是什么样的，持久化机制是什么样的，并且我们的配置依据是什么

Redis过期策略

Redis过期策略就是指Redis如何处理设置了过期时间的键值对。Redis的过期策略有两种：定期删除和惰性删除。

定期删除

定期删除，指的是Redis默认每隔100ms就随机抽取一些设置了过期时间的key，检查是否过期，如果过期就删除。这种方式可以保证过期的key不会占用太多内

但是毕竟是随机，有些key可能还是躲过一劫，也有可能导致一些key过期后还没有被删除，或者一些不常访问的key占用内存过久。所以下面两种策略就来了

惰性删除

惰性删除，指的是当访问一个key时，Redis会检查这个key是否过期，如果过期就删除并返回空。这种方式可以保证每次访问的key都是有效的

但是也有一个问题，如果用户一直不访问那些过期的key呢？还是在那占着茅坑不拉屎，下面更优秀的来了

Redis内存淘汰机制 Redis提供了8种内存淘汰策略，可以通过配置文件或者命令行来设置。这8种策略分别是：

noeviction：当内存不足以写入新数据时，返回错误信息，不会淘汰任何数据。
allkeys-lru：当内存不足以写入新数据时，在所有的key中淘汰最近最少使用（LRU）的key。
allkeys-random：当内存不足以写入新数据时，在所有的key中随机淘汰一个key。
volatile-lru：当内存不足以写入新数据时，在设置了过期时间的key中淘汰最近最少使用（LRU）的key（推荐）
volatile-random：当内存不足以写入新数据时，在设置了过期时间的key中随机淘汰一个key。
volatile-ttl：当内存不足以写入新数据时，在设置了过期时间的key中淘汰剩余生存时间（TTL）最短的key。
volatile-lfu：从已设置过期时间的数据集挑选使用频率最低的数据淘汰。
no-enviction（禁止驱逐）：禁止驱逐数据，这也是默认策略。意思是当内存不足以容纳新入数据时，新写入操作就会报错，请求可以继续进行，线上任务也不能持续进行，采用no-enviction策略可以保证数据不被丢失。

Redis持久化方式

Redis持久化方式就是指将Redis中的数据保存到硬盘中，以防止数据丢失，这也是Redis厉害的地方。

Redis支持两种持久化方式：快照（snapshotting）和追加文件（append-only file）。

快照（snapshotting）

快照持久化是指在一定的条件下，将Redis中的所有数据一次性写入到一个RDB文件中。这个条件可以是基于时间或者基于写操作的数量来触发。例如：

save 900 1 #在900秒（15分钟）之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 300 10 #在300秒（5分钟）之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 60 10000 #在60秒（1分钟）之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

也可以手动执行SAVE或者BGSAVE命令来创建快照。SAVE命令会阻塞Redis服务器直到快照完成，BGSAVE命令会在后台执行快照操作（推荐）。

快照持久化的优点是：RDB文件紧凑，恢复速度快，适合做备份和灾难恢复。缺点是可能会丢失最后一次快照之后的数据，而且快照过程可能会影响Redis的性能。比如设置5分钟快照一次，如果恰巧4分59秒时服务挂了，那就相当于丢了5分钟数据，对于要求严谨的业务还是不能接受的，后面我们统一介绍配置

追加文件（append-only file）

追加文件持久化是指将Redis执行的每一条写命令都追加到一个AOF文件中。当Redis重启时，会通过重新执行AOF文件中的命令来恢复数据。

追加文件持久化可以通过配置文件中的appendonly参数来开启，默认为no，可以设置为yes。开启后，还可以通过appendfsync参数来设置同步频率，有三个选项：

always：每次写入都同步到硬盘，最安全但是性能最差。
everysec：每秒同步一次，折中方案。
no：由操作系统决定何时同步，性能最好但是风险最高。

追加文件持久化的优点是数据实时性好，最多只会丢失一秒的数据，并且对Redis的性能影响小。缺点是AOF文件会比RDB文件大，恢复速度慢，并且可能存在AOF文件过大或者写入出错的问题。

为了解决这些问题，Redis提供了AOF重写机制，可以在不影响Redis服务的情况下，对AOF文件进行压缩和优化，去除冗余的命令。AOF重写可以通过BGREWRITEAOF命令手动触发，也可以通过auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数自动触发。