一，RDB
每隔一段时间，把内存中的数据写入磁盘的临时文件，作为快照，恢复的时候把快照文件读进内存。
- 优势
- 每隔一段时间备份，全量备份
- 灾备简单，可以远程传输
- 子进程备份的时候，主进程不会有任何io操作（不会有写入修改或删除），保证备份数据的的完整性
- 相对AOF来说，当有更大文件的时候可以快速重启恢复
- 劣势
- 发生故障是，有可能会丢失最后一次的备份数据
- 子进程所占用的内存比会和父进程一模一样，如会造成CPU负担
- 由于定时全量备份是重量级操作，所以对于实时备份，就无法处理了。
RDB持久化流程
5.jpg
在做RDB持久化时会fork一个子进程，会与主进程共享一块只读内存空间。
子进程在做数据镜像持久化时不会应该主进程继续接收请求。
当有新的写入命令发到主进程，会触发操作系统给一个copyonwrite操作，也就是只有父进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程
二，AOF
- AOF特点
- 以日志的形式来记录用户请求的写操作。读操作不会记录，因为写操作才会存存储。
- 文件以追加的形式而不是修改的形式。
- redis的aof恢复其实就是把追加的文件从开始到结尾读取执行写操作。
- 优势
- AOF更加耐用，可以以秒级别为单位备份，如果发生问题，也只会丢失最后一秒的数据，大大增加了可靠性和数据完整性。
- 以log日志形式追加，如果磁盘满了，会执行 redis-check-aof 工具
- 当数据太大的时候，redis可以在后台自动重写aof。当redis继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客户端。
- AOF 日志包含的所有写操作，会更加便于redis的解析恢复。
- 劣势
- 相同的数据，同一份数据，AOF比RDB大
- 针对不同的同步机制，AOF会比RDB慢，因为AOF每秒都会备份做写操作，这样相对与RDB来说就略低。 每秒备份fsync没毛病，但是的每次写入就做一次备份fsync的话，那么redis的性能就会下降。
- AOF发生过bug，就是数据恢复的时候数据不完整，这样显得AOF会比较脆弱，容易出现bug，因为AOF没有RDB那么简单，但是AOF就不会根据旧的指令去重构，而是根据当时缓存中存在的数据指令去做重构，这样就更加健壮和可靠了
- 配置不同的写日志策略：
no：不同步
everysec：每秒备份，推荐使用
always：每次操作都会备份，安全并且数据完整，但是慢性能差
AOF写入流程：
- 命令会先写入一个AOF缓冲区
- 根据上面不同策略，将缓冲区同步到磁盘（默认每秒一次）
- 当AOF文件达到文件大小阈值会触发AOF文件重写，对AOF进行压缩（阈值可配置）。
AOF文件重写就是把Redis进程内的数据转化为写命令同步到新的AOF文件。
