Redis持久化策略以及优缺点
Redis是基于内存的，为了防止一些意外情况导致数据丢失，需要将数据持久化到磁盘上。
Redis提供了两种持久化方式，一种是RDB ，一种是AOF。
RDB
RDB(Redis Database)是Redis的默认持久化方式，按照一定的时间间隔将内存的数据以快照的形式保存到磁盘，恢复时将快照读取到内存中。RDB持久化实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储，如下图。
优点：
- 适合对大规模的数据恢复，比AOF的启动效率高
- 只有一个文件
dump.rdb，方便持久化 - 性能最大化，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
缺点：
- 数据安全性低，在一定间隔时间内做一次备份，如果Redis突然宕机，会丢失最后一次快照的修改
- 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
AOF
AOF(Append-only File)持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF:
AOF的命令记录的频率也可以通过redis.conf文件来配：
| 配置项 | 刷盘时机 | 优点 | 缺点 |
|---|---|---|---|
| Always | 同步刷盘 | 可靠性高，几乎不丢数据 | 性能影响大 |
| everysec | 每秒刷盘 | 性能适中 | 最多丢失1秒数据 |
| no | 操作系统控制 | 性能最好 | 可靠性较差，可能丢失大量数据 |
因为是记录命令，AOF文件会比RDB文件大的多 。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：
优点：
- 具备更高的安全性，Redis提供了3种同步策略，分别是每秒同步、每修改同步和不同步。相比RDB突然宕机丢失的数据会更少，每秒同步会丢失一秒钟的数据，每修改同步不会丢失数据。
- 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。
- AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作，可以通过该文件完成数据的重建。
缺点：
- 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB在恢复大数据集时的速度比AOF快。
- 根据AOF选择同步策略的不同，效率也不同，但AOF在运行效率上往往会慢于RDB。
AOF和RDB对比
