Redis提供两种备份方式：RDB 持久化机制和AOF 持久化机制
1、RDB持久化机制
会在指定时间点生成数据集快照，通过save（阻塞的）和bgsave（后台 fork 子进程进行不会阻塞主进程处理命令请求）指令来生成RDB文件，如果需要恢复数据，只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务
优点
- 比起 AOF，在数据量比较大的情况下，RDB的启动速度更快；
- RDB文件方便传输，可以在异地快速启动新服务
- 性能好，可以起fork子进程，不影响主线程
缺点
- 数据丢失，假设5分钟备份一次，在宕机的这5分钟数据就丢失了
- 当数据量很大时，在 fork 子进程备份过程中，会出现明显的停顿现象
AOF 持久化机制
记录 server 端收到的每一条写命令，当 server 重启时会进行重放以此来重建之前的数据集。AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加(append)到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写(rewrite) ，使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。AOF 持久化实现可以分为命令追加(append)、文件写入(write)、文件同步(fsync) 三个步骤。Append 追加命令到 AOF 缓冲区，Write 将缓冲区的内容写入到程序缓冲区，Fsync 将程序缓冲区的内容写入到文件。
优点
- 比RDB可靠。你可以制定不同的 fsync 策略：no、everysec 和 always。默认是 everysec。这意味着你最多丢失一秒钟的数据
- 当AOF文件太大时，Redis 会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时 Redis 会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。当新文件重写完，Redis 会把新旧文件进行切换，然后开始把数据写到新文件上
缺点
- AOF比较大，比RDB大
Redis 4.0 混合持久化
Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。先以RDB格式写入全量数据，再追加增量日志，这样既可以提高AOF Rewrite和恢复速度，也可以减少文件大小，还可以保证数据的完毕性。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分就是压缩格式不再是 AOF 格式，可读性较差。
