Redis的持久化 RDB和AOF的区别

持久化

触发方式：RDB持久化的触发方式分为手动触发和自动触发

1. 手动触发：SAVE和BGSAVE命令都可以生成RDB文件。SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。而BGSAVE会fork出一个子进程，由子进程来负责创建RDB文件，父进程（Redis主进程）则继续处理请求。BGSAVE仅仅在fork子进程时会阻塞主线程一会儿，而SAVE则是整个过程都会阻塞主线程，因此SAVE已基本被废弃，线上环境要杜绝SAVE命令的使用。
2. 自动触发：自动触发最常见的情况是在配置文件中通过save m n的形式，指定当m秒内发生n次变化时，会触发bgsave。执行shutdown命令时，也会自动执行rdb持久化。

RDB文件：RDB文件是一种经过压缩的二进制文件，dir配置指定目录，dbfilename指定文件名。默认是Redis根目录下的dump.rdb文件。RDB文件默认采用LZF算法对RDB文件进行压缩。RDB文件的载入工作是在服务器启动时自动进行的，并没有专门的命令。当AOF和RDB同时开启时，AOF的优先级更高，因此会优先载入AOF文件恢复数据，只有当AOF关闭时，才会加载RDB文件，当服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

关于RDB常用配置的总结：

save m n：bgsave自动触发的条件，m秒内发生n次更改，就执行bgsave完成持久化
stop-writes-on-bgsave-error yes：当bgsave出现错误时，Redis是否停止执行写命令
rdbcompression yes：是否开启RDB文件压缩
rdbchecksum yes：是否开启RDB文件的校验，在文件写入和读取时都起作用
dbfilename dump.rdb：RDB文件名
dir ./：RDB文件和AOF文件所在目录

AOF持久化：

RDB持久化是将进程数据写入文件，二AOF持久化，则是将Redis执行的每次写命令记录到单独的日志文件中，当Redis重启时再次执行AOF文件中的命令来恢复数据，与RDB相比，AOF的实时性更好。

Redis服务器默认开启RDB，关闭AOF，要开启AOF，需要在配置文件中配置：appendonly yes

当AOF开启时，Redis启动时会优先加载AOF文件来恢复数据，只有当AOF关闭时，才会载入RDB文件来恢复数据。当AOF开启，但是AOF文件不存在时，即使RDB文件存在，也不会被加载。与载入RDB文件类似，Redis载入AOF文件时，也会对AOF文件进行校验，如果文件损坏，则会在日志中打印错误，Redis启动失败。

AOF常用配置总结：

appendonly no：是否开启AOF
appendfilename "appendonly.aof"：AOF文件名
dir ./：RDB文件和AOF文件所在目录
appendfsync everysec：fsync持久化策略
aof-load-truncated yes：如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件

RDB和AOF的优缺点：

1. RDB持久化

   优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。

   缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF成为主流。此外，RDB文件需要满足特定的格式，兼容性差。

2. AOF持久化

   与RDB持久化相对应，AOF的优点在于支持秒级持久化，兼容性好，缺点是文件大，恢复速度慢，对性能影响较大。