redis的RDB和AOF持久化原理与数据恢复

redis的两种持久化方式

save
阻塞当前进程，直到持久化完成。如果内存中需要持久化的实例较多，会严重影响redis性能

bgsave
save的改进版，主进程fork一个子进程，子进程在后台做持久化工作，期间不影响主进程的正常运行

RDB持久化原理

• RDB是redis默认的持久化方式，redis会按照持久化策略，隔一段时间保存一份内存的数据快照到dump.rdb文件。该文件是压缩后的全量复制的二进制文件
• redis启动的时候会根据配置文件指定的路径找dump.rdb文件，将数据从硬盘写到内存

RDB的持久化策略配置

save 900 1
save 300 10
save 60 10000

• 如果900秒内，redis执行了至少一次写操作，写入磁盘
• 如果300秒内，redis执行了至少十次写操作，写入磁盘
• 如果60秒内，redis执行了至少一万次写操作，写入磁盘

可以看到，RDB文件的更新频率是根据规定时间内的更新次数决定的，必须同时满足两个条件才会触发。并且使用的是bgsave方式做持久化

RDB的优缺点
优点：由于RDB文件存储的是全量的二进制文件，相对于AOF方式更接近底层，所以恢复数据更快

缺点：无法实时持久化，可能丢失最后一次持久化之后的数据。每次持久化都需要创建子进程，频繁操作会导致成本过高。RDB持久化方式存在高低版本不兼容问题。

AOF持久化原理

AOF是基于命令追加的方式，保存的是应用层面对redis做的操作命令

开启AOF持久化

appendonly yes （默认为no）

redis启动的时候会从配置文件中拿到AOF文件地址，自动恢复数据

重要参数

• appendfsync always //redis内存一旦有新数据，强制更新到硬盘，实时持久化，但是性能影响较大
• appendfsync everysec //每秒强制写入磁盘一次，在性能和防止数据丢失方面折中，推荐使用
• auto-aof-rewrite-percentage 100 //aof文件大小翻倍时进行压缩
• auto-aof-rewrite-min-size 64mb //aof文件超过64mb才考虑压缩

AOF的持久化流程

1. 所有的写入命令会追加到AOF缓冲区
2. 达到AOF同步条件后，像硬盘同步数据
3. 当AOF文件足够大时，会进行自我压缩
4. redis重启时加载AOF文件到redis的虚拟内存

问：RDB和AOF同时开启，redis会使用哪种方式恢复数据？
答： AOF。RDB是基于快照因为AOF数据更全。

在实际生产过程应该选择RDB还是AOF？

1. 如果redis数据仅仅是作为一个缓存使用，数据丢失对系统无影响，可以不做持久化处理。
2. 如果可以接受十几分钟的数据丢失，可以选择RDB，因为RDB数据恢复更快。如果数据非常重要，持久化要达到秒级，选择AOF。
3. 如果需要做数据同步，可以选择两者同时开启，启动redis做数据恢复时，用aof，做数据备份用rdb。