Redis的AOF、RDB和复制功能对过期键的处理

Redis过期键管理
本文介绍了Redis中过期键的设置、移除方法及删除策略,包括惰性删除和定期删除。并详细阐述了AOF、RDB和复制功能如何处理过期键。

一、过期键

1. 设置键的生存时间或过期时间

通过EXPIRE命令为键设置过期时间,单位是秒

redis> SET key value
OK
redis> EXPIRE key 5
(integer) 1
redis> GET key //5秒内
"value"
redis> GET key //5秒后
(nil)

还可以通过PEXPIRE设置过期时间,单位是毫秒

除了这种设置剩余存活时间的方式,还可以通过EXPIREAT或者PEXPIREAT为键设置具体的过期时间

redis> EXPIREAT key 1377257300
(integer) 1

Redis中所有添加了过期时间的键都会保存到一个expires字典中,但是不代表expires中的所有键都过期了。

2. 移除键的生存时间或过期时间

通过PERSIST命令来移除设置在键上的剩余时间或过期时间

redis> SET key value
OK
redis> EXPIRE key 5
(integer) 1
redis> TTL key
(integer) 5
redis> PERSIST key
(integer) -1

这里的TTL命令则是查看键的剩余存活时间,单位是秒。此外也可以通过PTTL查看剩余存活时间,单位是毫秒。

3、Redis中过期键的删除策略

既然键过期了,存放在Redis中就等于浪费了空间,所以需要去删除这些过期键。那么具体什么时候删除呢?Redis中采用惰性删除和定期删除两种策略:通过两种策略配合使用,可以很好的平衡CPU使用效率和避免空间浪费。

(1)惰性删除

惰性删除就是过期了之后不会立即删除,而是等到下次GET这个键的时候,先去判断有没有过期,如果过期了就删除。
expire
实际上在执行增删改查的时候都会调用expireIfNeeded()函数去判断键有没有过期。

(2)定期删除

定期删除策略则是通过Redis服务器内部的周期性操作,从数据库中的expires字典中随机检查一部分的过期时间,并删除其中的过期键。

二、AOF、RDB和复制功能对过期键的处理

1. 生成RDB文件

在执行SAVE或者BGSAVE命令创建一个RDB文件时,Redis不会将过期键保存到RDB文件中

2. 载入RDB文件
  • 如果服务器是主服务器,那么在载入RDB文件时,会对过期键进行过滤,也就是不会加载RDB中的过期键到主服务器中
  • 如果服务器是从服务器,那么在载入RDB文件时,不会对过期键过滤,先将RDB中的全部数据加载到从服务器中。然后再进行主从同步,删除过期键
3. AOF文件写入

因为AOF采取的是追加写,所以如果过期键被删除的话,其实是向AOF文件中追加一条DEL命令,来显示的标记该key被删除了

4. AOF重写

和生成RDB文件一样,在执行AOF重写的时候,也会将过期键过滤掉,也就是过期键不会保存到重写后的AOF中

5. 复制功能

当服务器运行在复制模式下时,从服务器的过期键删除动作还是根据主服务器来决定的。只有当主服务器同步了DEL命令到从服务器之后,从服务器才会删除过期键。


THE END.

### Redis AOFRDB 持久化方式的区别及特点 #### 1. **RDB(快照持久化)** RDBRedis 的一种持久化方式,通过将内存中的数据集快照写入磁盘来实现持久化。以下是 RDB 的主要特点: - **技术原理** RDB 使用快照的方式将 Redis 在某个时间点的数据保存到一个二进制文件中,默认命名为 `dump.rdb`[^3]。Redis 提供了两个命令用于生成 RDB 文件:`save` `bgsave`。其中,`save` 命令会在主线程中执行,导致阻塞;而 `bgsave` 则会创建一个子进程来完成文件写入操作,避免了对主线程的干扰[^2]。 - **优点** - 数据恢复速度快,因为 RDB 文件是经过压缩的二进制文件,体积较小。 - 对于需要备份或迁移的场景非常友好,由于文件小且完整,便于传输存储。 - 性能较高,特别是在大规模数据集的情况下,RDB 的效率优于 AOF。 - **缺点** - 数据安全性较低,因为它是基于时间间隔的快照机制。如果 Redis 实例在两次快照之间崩溃,则可能会丢失这段时间内的数据。 - 如果配置的快照频率过高,可能会增加 I/O 负担。 --- #### 2. **AOF(追加文件持久化)** AOF 是另一种 Redis 的持久化方式,通过记录服务器接收到的每个写操作指令,并在 Redis 重启时重新执行这些指令来恢复数据。 - **技术原理** AOF 将每个写操作以日志的形式追加到文件中,每次写入都会被记录下来。Redis 4.0 后支持同时开启 RDB AOF,优化后的 AOF 文件分为两部分:前半部分为 RDB 文件,后半部分为从上次 RDB 快照之后的所有写操作日志[^4]。 - **优点** - 数据安全性更高,可以通过调整同步策略(如每秒同步、每次写入同步等)减少数据丢失的风险。 - 配置灵活,可以根据实际需求选择不同的同步频率(`always`、`everysec` 或 `no`)。 - 支持重写功能,可以压缩 AOF 文件大小,降低磁盘占用。 - **缺点** - 文件体积较大,尤其是在写操作频繁的情况下,AOF 文件可能迅速增长。 - 数据恢复速度较慢,因为需要逐条执行日志中的写操作。 - 如果 AOF 文件损坏,可能需要手动修复。 --- #### 3. **AOFRDB 的区别** | 特性 | RDB(快照持久化) | AOF(追加文件持久化) | |---------------------|-------------------------------------------------------|---------------------------------------------------------| | **持久化方式** | 定期生成数据快照 | 记录每个写操作到日志文件 | | **文件大小** | 较小,压缩后的二进制文件 | 较大,文本格式的日志文件 | | **数据安全性** | 较低,可能丢失最后一次快照之后的数据 | 较高,根据同步策略可减少数据丢失 | | **恢复速度** | 较快 | 较慢,需逐条执行日志 | | **适用场景** | 对性能要求较高,对少量数据丢失容忍度较高的场景 | 对数据安全性要求较高,写操作频繁的场景 | --- ### 示例代码 以下是一个简单的 Redis 配置示例,展示如何启用 RDB AOF: ```conf # 启用 RDB 快照 save 900 1 save 300 10 save 60 10000 # 启用 AOF 持久化 appendonly yes appendfsync everysec ``` 上述配置中,`save` 指令定义了触发 RDB 快照的时间条件,而 `appendonly` `appendfsync` 则分别启用了 AOF 并设置了同步频率。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值