总结
RDB持久化方法: redis database的简写. 默认文件是dump.rdb, 因为该文件是二进制格式的文件,所以文件占用空间很小. 按照一定的时间间隔(该时间间隔是可以调整的), 存储数据快照, 存储在磁盘中. 适用于对数据实时性要求不高, 但是对数据恢复速度要求高的场景. 优点: 备份速度快, 文件占用空间小, 重启redis实例的时候数据恢复很快, 不会对业务造成很大的影响. 缺点: 不能做到数据的实时的持久化,也就是说:会丢失最后一次快照后业务更新的数据.
AOF持久化(append only file): append only file,简写. 把每个写操作, 都添加到文件中,
AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。理解掌握好 AOF 持久化机制对我们兼顾数据安全性和性能非常有帮助。
默认文件是appendonly.aof, 该文件是文本类型的文件, 占用空间比二进制文件大. 适用于对数据的实时性要求很高的场景,同时可以接受占用空间大的情况.
RDB与AOF 的区别
1. RDB 持久化
-
原理：在指定的时间间隔内将[数据快照]保存到磁盘。
-
文件生成：会生成一个存储整个数据库状态的二进制文件，默认文件名为
dump.rdb。 -
触发方式：可以在指定时间间隔后自动触发（如在
save配置下）或手动执行BGSAVE命令。 -
优点：
- 速度快：适合快速备份和恢复大量数据。
- 体积小：生成的文件是数据的压缩快照，占用空间小。
- 加载快：启动时加载RDB文件速度较快。
-
缺点：
- 不实时：无法做到数据实时持久化，会丢失最近一次快照后的数据。
- 大量数据写入时性能波动：RDB文件生成时需要Fork子进程，内存占用较高。
2. AOF 持久化
-
原理：将每个写操作记录到文件中，类似于日志的方式。
-
文件生成：会记录每条写命令，默认文件名为
appendonly.aof。 -
触发方式：可以通过
always、everysec、no三种模式控制写入频率。 -
优点：
- 数据安全性高：可以实时保存数据，减少数据丢失风险，适合对数据安全性要求高的场景。
- 可读性：AOF是文本格式，便于读取和修改。
-
缺点：
-
文件体积大：比RDB文件更大，尤其是频繁写入数据的场景。
-
恢复速度慢：因为需要逐条命令执行，恢复速度较慢。
-
写入效率稍低：频繁写入的场景可能会影响性能。
-
适用场景
- RDB适用于备份数据和快速恢复场景，适合对数据实时性要求不高、恢复速度要求高的场景。
- AOF适用于需要更高数据安全性、能够接受较大存储空间的场景。
1/RDB
(1)简介
RDB 持久化是把当前进程数据生成快照保存到硬盘的过程。所谓内存快照，就是指内存中的数据在某一个时刻的状态记录。这就类似于照片，当你给朋友拍照时，一张照片就能把朋友一瞬间的形象完全记下来。RDB 就是 Redis DataBase 的缩写。
Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照。也就是说，把内存中的所有数据都记录到磁盘中。但是，RDB 文件越大，往磁盘上写数据的时间开销就越大。
(2)工作流程
(3)优缺点
优点
RDB 是一个紧凑压缩的二进制文件，代表 Redis 在某个时间点上的数据快照。非常适用于备份，全量复制等场景。
比如每隔几小时执行 bgsave 备份，并把 RDB 文件拷贝到远程机器或者文件系统中，用于灾难恢复。Redis 加载 RDB 恢复数据速度远远快于 AOF 的方式。
缺点
RDB 方式数据没办法做到实时持久化甚至秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高。
RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个格式的 RDB 版本，存在老版本 Redis 服务无法兼容新版 RDB 格式的问题。
2/AOF持久化
(1)简介
AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。
AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。
理解掌握好 AOF 持久化机制对我们兼顾数据安全性和性能非常有帮助。
