Redis持久化

RDB快照

默认持久化方式,redis将内存中的数据库快照保存在dump.rdb的二进制文件到磁盘

可以设置条件 "N秒内M次修改", 满足条件时触发保存快照. 可以配置多个条件, 满足任一条件, 都会触发保存.

在redis.config配置文件设置:save 10 3, 表示10秒内修改超过3次命令就持久化一次

可以客户端执行save/bgsave, 立即保存快照

命令	save	bgsave
是否同步	同步	异步
是否阻塞redis命令	是	否
缺点	阻塞客户端线程	消耗额外子线程资源

AOF追加命令

将redis每一条修改的命令写入到appendonly.aof文件(先写入cache，每隔一段时间fsync到磁盘)

1. 配置开启AOF持久化:        appendonly yes

2. 配置持久化频率

配置	描述
appendfsync always	每条命令写一次磁盘, 性能低
appendfsync everysec	每秒写一次
appendfsync no	从不, 交给操作系统处理, 不安全不稳定

3. 配置是否重写

        大量执行incr命令, 会写入很多命令, 实际可以重写合并成一条set命令

配置	描述
auto-aof-rewrite-min-size 64mb	文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
auto-aof-rewrite-percentage 100	aof文件自上一次重写后文件大小增长了100%则再次触发重写

RDB和AOF对比

命令	RDB	AOF
恢复速度	快	慢
安全性	易丢数据	看策略,如果配每秒一次, 最多丢一秒数据
空间	低	高

混合模式

        重启 Redis 时，如果用 RDB来恢复，会丢失大量数据。通常用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB来说要慢很多，在 Redis 实例很大的情况下，启动需要花费很长的时间。Redis 4.0 为了解决这个问题，带来了一个新的持久化选项, 混合持久化。

开启混合持久化配置(必须先开启aof):    aof-use-rdb-preamble yes

持久化流程:

        AOF在重写时，将此刻的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

Redis 重启的时候，先加载 RDB 的内容，然后再重放增量 AOF 日志，恢复效率大幅提升。