1. 概述
Redis的数据一般保存在内存中，这个时候如果Redis突然宕机了，再重启，内存中的数据就全丢了。为了防止这种情况的发生，需要使用Redis的持久化机制。
2. 持久化类型
Redis提供了两种持久化方式，它们分别是：
- RDB
- AOF
3. RDB
RDB是每隔一段时间就基于当前Redis的所有内存数据就生成一份全量的快照，它存储的内容是内存数据的二进制序列化形式，所占空间小。
3.1. 优点
-
RDB会生成多个数据文件，每个数据文件都代表了某一时刻中Redis的所有数据。它非常适合做冷备，可以将生成的RDB文件上传到云服务器上，等到需要的时候再从云服务上下载下来。 -
RDB在生成快照的时候，对服务影响很小，因为Redis是从主进程中fork出一个子进程，然后再在子进程中进行RDB持久化。 - 对于
AOF来说，直接基于RDB数据文件进行重启和恢复Redis进程，更加快速。
3.2. 缺点
- 做冷备时，容易丢失数据。一般来说，配置成每隔5分钟或者更新的时间做一次
RDB备份，就可能丢失最近5分钟的数据；
4. AOF
AOF以追加的方式记录的是Redis对内存进行修改的指令记录。它记录的是数据的指令文本。
Redis会在收到客户端修改指令后，先进行参数校验，校验通过后，就立刻将指令文本存储到AOF日志中，然后在执行指令命令，这样即使遇到宕机，也能通过对已经存储到AOF日志的指令进行重放就可以恢复到宕机钱的状态。
AOF文件会不断膨胀，当大到一定程度时，AOF通过执行rewrite操作来进行瘦身。
4.1. fsync
当程序对AOF日志进行写操作时，实际上是将内容写到内存的缓存中，然后再异步地将数据刷回到磁盘。
fsync是Linux内核提供的函数，它的作用就是将内存缓存中的数据刷到磁盘，redis在写AOF文件时，会调用fsync函数以保证日志不会丢失。但是fsync是个磁盘IO操作，会比较慢。
和fsync相关的配置：
appendfsync no #Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
appendfsync everysec # 每分钟调用一次fsync
appednfsync always # 每执行一个写操作就调用一次fsync
4.2. 优点
-
AOF可以更好得保护数据不丢失，一般会每隔1s进行一次fsync操作，保障os cache中的数据写入到磁盘中。 -
AOF通过append-only模式写入，没有磁盘寻址的开销，写入性能高。 - 内容可读性比较好。
4.3. 缺点
- 对于同一份数据，AOF日志文件通常笔RDB快照文件要大；
- AOF需要配置fsync，会影响redis写的性能；
- 数据恢复时，比较慢，因为它是基于指令重放。
5. 持久化方案的选择
我们重启Redis时，如果通过RDB来恢复内存状态，那么可能会导致丢失大量数据。而通过AOF日志重放也可以恢复，但是重放AOF性能会比较慢，这样可能会导致Redis恢复需要花费很长的时间。
在Redis4.0中，提供了一个新的持久化选项"混合持久化"，即AOF和RDB一起使用。此时，AOF的日志不再是全量的日志，而是自RDB持久化开始到RDB持久化结束的这段时间发生的增量日志，通常这部分增量很小。
这样我们在恢复的时候，就可以先加载RDB的内容，然后再重放AOF增量日志。
