目录
RDB
手动触发
1.save
这个命令会全力以赴地生成“快照”，如果数据量过大的话，可能会阻塞其他客户端地命令。
2.bgsave
与save不同，这个命令会创建出子进程来进行生成“快照”的过程。而父进程可以继续接收到其他客户端传来的命令，互不影响。
bgsave的执行过程
1.判断当前是否存在其他正在工作的子进程，如果有，则bgsave直接返回。
2.如果没有其他子进程，则fork出一个子进程执行任务。
3.子进程负责写文件，生成“快照”，父进程继续接收其他客户端的命令。
4.子进程完成持久化的操作后会通知父进程，并退出。
注意：
1.当在生成新的快照时，会把数据先保存在一个临时文件中，当生成完后，就删除之前的文件，将本次写完的文件的名字改成dump.rdb。实现了替换，保证了有且只有一个dump.rdb文件。
2.文件一般保存在/var/lib/redis中，当然也可以自行修改：
3.文件格式是二进制文件，将数据以压缩的方式写入该文件：
自动触发
自动触发顾名思义就是系统自动进行生成快照，不需要手动操作。
在redis的配置文件中可以修改redis进行自动生成快照的频率：
save 900 1的意思就是900秒内修改了一次就进行保存
AOF
可以在配置文件中手动设置AOF是否开启和设置AOF的文件名：
AOF的执行流程
1.因为AOF的实时保存的，所以它需要经常与磁盘打交道，但是频繁的I/O会严重影响效率，所以AOF设计了一个缓冲区，积累一定的数据之后，再写入到磁盘。（但是期间若发生断电或者其他事故，那么数据就没了）。
2.缓冲区的刷新策略也可以由程序员自行设计：
需要根据不同的业务进行选择。缓冲区的刷新频率越高，那么意味着保存数据的可靠性更高，但是换来的是效率的下降。
重写机制
为什么要进行重写？什么是重写？
总的来说重写就是把.aof中的文件进行了整理和修改的过程，去除了冗余并进行了合并。节省了内存也提高了将数据从磁盘读到内存的效率。
重写的流程
1.创建出子进程，子进程进行重写，父进程继续接收客户端的命令。
2.因为在创建子进程的时候仅仅是保存了父进程当前的数据，所以之后父进程写入的数据父进程将获取不到。所以设计了一个缓冲区，专门存放fork之后产生的数据。当子进程完成重写后，利用信号通知父进程。父进程再把缓冲区的数据写入到子进程刚刚写入的aof文件里。
混和持久化
因为考虑到aof文件恢复到内存中的速度比较慢，所以设计出了一种混合持久化的操作。即按照AOF的方式将每条命令都记录到磁盘上，同时aof文件中存的数据的格式也是二进制格式。
可以在配置文件中开启是否进行混合持久化：
比较AOF和RDB
1.RDB的文件格式是二进制格式，AOF是文本格式。
2.RDB不是实时保存，而AOF是实时保存。
3.RDB加载恢复数据的速度要大于AOF。
总结：根据不同的业务需求和场景进行选择。
