Redis持久化机制有RDB和AOF两种

RDB机制

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，持久化的东西是一个时间点的快照，触发RDB持 久化过程分为手动触发和自动触发。

RDB有手动触发和被动触发机制

手动触发是save和bgsave命令，其中save命令是阻塞当前服务器的，不推荐用

RDB持久化文件保存在dir配置指定的目录下面，文件名通过dbfilename配置指定，支持使用config set dire [newDir]热更新

RDB文件的压缩算法默认是LZF算法

RDB的优点包括：

• RDB是数据备份，因此故障恢复速度远快于AOF

• 适用于全量复制

RDB的缺点包括：

• 没法做到持久化/秒级持久化，因为save和bgsave都是重量级操作，需要拉起子进程，成本高

• 新老版本不支持

AOF机制

以独立日志记录每次写命令，持久化的东西是命令和执行顺序，类似mysql中的binlog

AOF默认不开启，可以调整appendonly yes开启、

AOF文件名 通过appendfilename配置设置，默认文件名是appendonly.aof，保存路径同 RDB持久化方式一致，通过dir配置指定

AOF写入命令的格式是文本协议格式，例如set hello world 写入格式是：

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

AOF将命令写入磁盘前，都会先写入aof_buf缓冲区，很好地调节性能和硬盘负载，缓冲策略有三种：

• always：写入aof_buf后调用系统fsync操作即时同步AOF文件

• everysec：写入aof_buf后调用系统write操作，由专门线程定期调用系统fsync写AOF文件

• no：写入aof_buf后调用系统write操作，同步AOF文件由操作系统负责，通常同步周期最长30s

AOF文件随着命令写入逐渐变大，因此redis引入重写机制压缩文件：

• 重写后，失效数据不再写入AOF

• 旧的AOF中的无效命令不再写入（例如对一个key两次set，实际上只写最后一次就行）

• 多条命令合并，例如lpush list a、lpush list b、lpush list c可以转化为lpush list a b c ，以64个元素为界拆分

重启加载数据时，redis优先判断开启AOF以及有AOF文件，否则才会去找RDB文件