1. 简介
Redis作为内存型数据库，数据都保存在内存中，如果重启或意外宕机后，数据会全部丢失。因此，Redis提供了完善的持久化机制，将内存中的数据持久化到磁盘上，避免了完整性和安全性的问题，也方便进行数据备份和恢复。
2. 持久化方式
- RDB：产生一个数据快照文件
- AOF：实时追加命令的日志文件
3. RDB
RDB（Redis Database Backup file），即Redis数据备份文件或Redis数据快照。通过执行save或bgsave命令让Redis在本地生成RDB快照文件，这个RDB文件包含了整个实例接近完整的数据内容。
- 优点
内存小：RDB将数据压缩写入，因此要比整个实例内存小；
恢复快：当宕机恢复时，可以快速加载RDB文件并恢复文件中的数据； - 缺点
数据不全：因为是某一时刻的数据对照，因此可能会数据不全；
消耗大：生成RDB文件时会消耗大量的CPU和内存资源； - 适用场景
对丢失数据不敏感的业务场景；
主从全量同步数据；
数据库备份； - 定时生成RDB
# 最近1分钟内，至少生成1次 save 60 1 # 最近5分钟内，至少生成10次 save 300 10 # 最近15分钟内，至少生成10000次 save 900 10000 - Copy On Write
通过执行save或bgsave命令都可以生成RDB文件，前者为前台执行，即生成RDB文件时，会阻塞整个实例，在生成之前，任何请求都是无法处理的，对于数据量非常大的实例，生成RDBwen文件将非常耗时。因此，通常会使用bgsave命令在后台执行，这样Redis依旧可以处理客户端请求，不会阻塞整个实例。
通过执行bgsave命令生成RDB文件采用操作系统的的Copy On Write技术，即fork系统调用。fork系统调用会产生一个子进程，它与父进程共享相同的内存地址空间，于是子进程在这一时刻就能拥有与父进程的相同的内存数据，操作系统将父进程的内存页表拷贝给子进程，如果整个Redis实例内存占用很大，那它的内存页表也会很大，在拷贝时就会非常耗时，同时这个过程也会消耗大量的CPU资源。在完成拷贝之前父进程处于阻塞状态，无法处理客户端请求。即fork系统调用完成之后，子进程把全部数据写入到RDB文件中；以此同时，父进程依旧处理客户端的请求，当在处理写命令时父进程会从操作系统申请新的内存地址空间，不再与子进程共享，这样父子进程的内存会分离开，父进程在新申请的内存地址中修改数据对子进程不受影响。
由此可以看出，通过执行save或bgsave命令在生成RDB文件时，不仅消耗CPU资源，还有需要占用最多一倍的内存空间。因此，使用此方式时需要评估即fork系统调用耗时，并且保证Redis实例所在的机器拥有足够的CPU和内存资源，并合理设置生成RDB的时机。
4. AOF
AOF（Append Only File）即追加日志文件。它与RDB不同的是，AOF中记录的是每一个命令的详细信息，包括完整的命令类型、参数等。只要产生写命令，就会实时写入到AOF文件中。
- 优点
数据完整：AOF数据文件更新比较及时，比RDB保存更完整的数据，这样在数据恢复时能够恢复尽量完整的数据，降低丢失数据的风险。 - 缺点
增加IO负担：随着时间增长，AOF文件会越来越大
AOF文件刷盘会增加磁盘IO的负担，可能影响Redis的性能（开启每秒刷盘时）。 - 适用场景
对丢失数据敏感的业务场景。
Redis会优先使用AOF文件进行数据恢复。 - 刷盘方式
开启AOF后，Redis会把每个写操作的命令记录到文件并持久化到磁盘中，为了保证数据文件的安全性，Redis还提供了三种文件刷盘的机制：
（1）appendfsync always：每次写入都刷盘。对性能影响最大，占用磁盘IO比较高，数据安全性最高。
（2）appendfsync everysec：1秒刷一次盘，对性能影响相对较小，节点宕机时最多丢失1秒的数据。
（3）appendfsync no：按照操作系统的机制刷盘，对性能影响最小，数据安全性低，节点宕机丢失数据取决于操作系统刷盘机制。 - 开启AOF
# 开启AOF appendonly yes # AOF文件名 appendfilename "appendonly.aof" # 文件刷盘方式 appendfsync everysec - AOF重写
Redis提供了AOF瘦身的功能，可以设置在AOF文件很大时，自动触发AOF重写，Redis会扫描整个实例的数据，重新生成一个AOF文件达成瘦身的效果。但这个重写过程也需要消耗大量的CPU资源。# AOF文件距离上次文件增长多少百分比时触发重写 auto-aof-rewrite-percentage 100 # AOF文件体积达到多少时触发重写 auto-aof-rewrite-min-size 64mb - 性能影响
如果AOF的刷盘机制设置为每次写入都刷盘，那么会大大降低Redis的写入性能，因为每次写命令都需要写入文件并刷到磁盘中才会返回，当写入量很大时，会增加磁盘IO的负担。
虽然Redis提供了实时刷盘的机制，但是在真正场景中使用的不多。通常我们会选择每秒刷盘这种方式，既能保证良好的写入性能，在实例宕机时最多丢失1秒的数据。
5. 总结
| 特性 | RDB | AOF |
|---|---|---|
| 持久化方式 | 生成某一时刻的数据快照文件 | 实时记录每一个写命令到文件 |
| 数据完整性 | 不完整，取决于备份周期 | 相对完整性高，取决于文件刷盘方式 |
| 文件大小 | 压缩二进制写入，文件较小 | 原始的操作命令，文件大 |
| 宕机恢复时间 | 快 | 慢 |
| 恢复优先级 | 低 | 高 |
| 持久化代价 | 高，消耗大量CPU和内存 | 低，只占用磁盘IO资源 |
| 使用场景 | 对丢数据不敏感的业务场景快速数据恢复；数据备份；主从全量复制 | 对于丢失数据敏感的场景 |