本文已参与「新人创作礼」活动，一起开启掘金创作之路。
持久化机制
Redis是一个内存数据库，当redis服务器重启，获取电脑重启，数据会丢失，我们可以将redis内存中的数据持久化保存到硬盘的文件中。
持久化分为AOF日志与RDB快照两种方案。
AOF日志
- AOF 里记录的是 Redis 执行后每一条命令，这些命令是以文本形式保存的。
为什么采用后记命令？
- 因为redis不会对写入AOF的语句进行语法检查，如果是先记命令的话，在后续恢复的时候可能会报错，而后记命令则不会
- 后记命令不会阻塞当前正在执行的命令
写回策略
后记命令的两个风险
- 刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险
- AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险
这两个风险都是和 AOF 写回磁盘的时机相关的，Redis有三种写回策略：
Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
没有哪种策略是完美的，只有贴切使用场景的策略，这是一种取舍。
重写机制
AOF会随着Redis的使用不断扩大，我们可能会对一个键值对频繁操作很多次，而AOF日志也会记录所有的操作。
当发生宕机时，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用。
这时候，重写机制就很重要了。
重写机制是这样的：
- 在重写的时候，是根据这个键值对当前的最新状态，为它生成对应的写入命令。
- 和 AOF 日志由主线程写回不同，重写过程是由后台子进程 bgrewriteaof 来完成的，保证了性能
RDB快照
机制为：在一定的间隔时间中，检测key的变化情况，然后持久化数据，就像虚拟机的快照功能一样。
Redis采用bgsave 子进程进行RDB，通过写时复制机制（操作系统提供的）保证快照期间数据可修改
- 多个快照之间的时间段采用“增量快照”，只记录改变部分
- 增量快照的内容由AOF负责
- AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。
总结
内存快照和AOF混合使用，互相弥补了其不足，发挥了令人赞叹的效果。
