Redis之所以能被称之为内存数据库而不单单是内存缓存是因为其有自己的持久化机制,可以持久化数据库到硬盘当中，在宕机之后能及时的恢复，其持久化方式主要有两种，AOF和RDB,下面的内容是对这两种方式的总结。
AOF
基本概念
AOF方式也就是Append Only File，其是在执行命令之后，将对应的日志写到日志文件中的，因为是先执行操作，再写日志，因此不会阻塞当前的写操作。
何时将日志刷盘，决定了Redis宕机恢复时丢失数据的多少，Redis提供了三种策略
- Always: 同步写回，命令执行完成，立马写回到磁盘
- Everysec: 每秒写回，隔一秒就将缓存页数据写回磁盘
- No: 依赖操作系统控制的写回，操作系统自己决定刷盘时机。 以上三种策略，对数据的可靠性要求越高的对性能的影响也就越大，因此如何配置是一个取舍问题。
AOF日志写的格式是执行命令的Redis协议内容，Redis协议是文本协议，自然占据空间比较大，而由于其记录的是操作流，对同一个Key的不断修改使得AOF日志中记录了很多历史的Value,为了解决这个问题，Redis引入了AOF重写机制,如何重写，是否影响Redis对外提供的服务是我们关心的内容，下面是关于AOF重写过程的总结,以问题的形式呈现。
AOF重写
1. 何时开启重写
这是由redis中的配置决定的，可以根据百分比和文件大小设置，相关的配置是auto-aof-rewrite-*
2. 重写过程中会不会影响Redis对外提供服务？
不会,重写过程是后台子进程bgrewriteaof来完成的，由于在fork过程中操作系统会拷贝页表等相关信息,这个过程会阻塞，但是拷贝完成之后,子进程会同父进程共享内存空间，而父进程也由于Copy On Write机制对内存的修改不会影响到子进程。子进程重写AOF，父进程对外提供服务，同时工作，整体上来看还是不会影响的。
3. 重写过程会直接删除原来的AOF日志么?
不会，原来的日志依然会使用，直到AOF重写完成。
4. 重写AOF的日志的进程内存空间是快照,那重写过程中的数据怎么办?
在重写过程中，数据会写到两个缓存中，一个是原来的AOF缓存，一个是AOF重写缓存区，当重写完成之后，重写缓冲区记录的最新操作也会写入新的AOF文件中，以保证数据库最新的记录，完成之后进行替换
RDB
上面讲到了AOF来记录Redis操作,当进行数据恢复的时候，AOF需要从头到尾执行命令才能恢复到最新的状态，而如果能够直接将内存快照下来，就会快很多，这就是RDB也就是Redis Data Base
执行RDB操作有两个命令可以直接执行
- save
- bgsave 其中save是在主进程中执行save操作,会阻塞主进程，而bgsave会创建一个子进程，来负责生成快照，子进程如何做到不阻塞在上面AOF中有解释。
对于RDB,还有一个问题是快照频率的问题，从可靠性的角度出发，恨不得每时每刻都可以创建快照，但是由于拷贝的是整个Redis内存数据，开销和空间占用都比较大，对磁盘的压力都很大。此时AOF的优势就展现了出来，因此引出在Redis4.0中提出的AOF和RDB混合模式
AOF与RDB混合模式
混合模式同时使用了两种方式来生成快照，在配置文件中指定的时间周期生成RDB，最后又将过程中发生的写操作以AOF的形式写到快照文件中。
