Redis的RDB和AOF
目录
Redis的RDB和AOF
概述
Redis 提供了两种持久化方式：RDB和AOF
RDB使用一次生成内存快照的方式，产生的文件紧凑压缩比更高，因此读取RDB恢复速度更快，由于每次生成RDB开销较大，无法做到实时持久化，一般用于数据冷备和复制传输
AOF持久化 以独立日志的方式记录每次写命令，重启时在重新执行AOF文件中的命令达到恢复数据的目的。AOF主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
RDB
触发机制
手动触发save命令
save命令会阻塞当前Redis服务器，直到RDB完成，对于内存较大的实例会造成长时间阻塞不建议线上环境使用
手动触发bgsave命令
Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，阻塞只发生在fork阶段
自动触发
- 使用save相关配置 “save m n” 表示在m秒内数据集存在n次修改自动触发bgsave
- 从节点执行全量复制操作
- 执行debug reload命令重新加载Redis时
- 默认情况下执行 shutdown 命令，并且没有开启AOF持久化功能时
bgsave触发流程
如图所示
1) 执行bgsave 命令，redis父进程判断当前是否存在正在执行的进程(RDB/AOF) 存在直接返回
2）父进程执行fork操作创建子进程，fork会发生阻塞
3）父进程fork完成后，bgsave命令返回“background saving started”信息并不会阻塞进程，可以继续响应其他命令
4）子线程创建RDB文件，根据父进程内存生成的临时快照文件，完成后对原有文件进行原子替换
5）进程发送信号给父进程表示江湾城，父进程更新统计信息
Redis默认采用LZF算法对成圣的RDB文件做压缩处理，压缩后的文件远远小于内存大小
RDB的优点
- RDB是紧凑压缩的二进制文件，代表Redis早某个时间点上的数据快照，非常适合用于备份，全量复制的场景
- Redis加载RDB恢复数据远远快于AOF
RDB的缺点
- RDB的方式数据没办法做到持久化/秒级持久化。
- RDB文件使用特定二进制保存，Redis版本演变过程有多个格式的RDB。存在不兼容问题
AOF
AOF工作流程
如图所示：
1）所有的命令都会追加到aof_buf(缓冲区)中
2）AOF缓冲区根据对赢得策略向硬盘做同步策略
3）随着AOF文件越来越大，定期对AOF进行重写
4） Redis重启时，加载AOF文件进行数据恢复
命令写入
AOF命令写入直接用的是文本协议格式，文本协议有较好的兼容性，开启AOF之后所有命令写入直接采用文本协议避免了二次开销，文本协议具有可读性，方便修改和处理
Redis把命令追加到缓冲区的好处：Redis使用单线程响应命令，如果吧AOF文件命令直接追加到硬盘，性能完全取决于当前硬盘的负载，Redis可以提供多种缓冲区同步硬盘策略，可以再性能和安全方面做出平衡
文件同步
everysec:命令写入aof_buf后调用系统write操作，write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次
no:命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期最长30s
write操作会触发延迟写（delayed write）机制，Linux在内核提供页缓冲区用来提高硬盘IO性能，write操作在写入系统缓冲区后直接返回，同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。
always:命令写入aof_buf后调用系统fsync操作同步到AOF文件，fsync完成后线程返回
配置为always时，每次写入都要同步AOF文件，在一般的SATA硬盘上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议配置。
配置为no，由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证。
配置为everysec，是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。
重写机制
- 为什么重写之后AOF 的文件可以变小 进程中超时数据不在写入文件，旧的AOF文件含有无效命令，多条写命令可以合并为一个
