Redis持久化的必要性
首先要明白redis是一个数据库, redis是一个内存数据库, 所有数据基本上都存在于内存当中, 会定时以追加或者快照的方式刷新到硬盘中. 由于redis是一个内存数据库, 所以读取写入的速度是非常快的, 所以经常被用来做数据, 页面等的缓存。
由于Redis的数据都存放在内存中,如果没有配置持久化,redis重启后数据就全丢失了,即便是重启后数据也无法很快恢复，而此时可能会有大量请求找到DB，DB扛不住，也就会出现所谓的“缓存雪崩”问题。
于是需要开启redis的持久化功能,将数据保存到磁盘上,当redis重启后,可以从磁盘中恢复数据。
Redis持久化的两种机制
1、RDB持久化
RDB是将当前数据生成快照保存到硬盘上。
RDB的工作流程：
执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
父进程执行fork操作创建子进程，fork操作过程中父进程被阻塞。（注意：父进程会被阻塞）
父进程fork完成后，bgsave命令返回“* Background saving started by pid xxx”信息，并不再阻塞父进程，可以继续响应其他命令。
父进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。根据lastsave命令可以获取最近一次生成RDB的时间，对应info Persistence中的rdb_last_save_time。
进程发送信号给父进程表示完成，父进程更新统计信息。
触发机制：
（1）手动触发
使用save命令：此命令会使用Redis的主线程进程同步存储，阻塞当前的Redis服务器，造成服务不可用，直到RDB过程完成。无论当前服务器数据量大小，线上不要用。
使用bgsave命令：此命令会通过fork()创建子进程，在后台进程存储。只有fork阶段会阻塞当前Redis服务器，不必到整个RDB过程结束，一般时间很短。因此Redis内部涉及到RDB都采用bgsave命令。这里注意一点，无论RDB还是AOF，由于使用了写时复制，fork出来的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。
（2）自动触发
Redis支持自动触发RDB持久化机制，配置都在redis.conf文件里面，看一下该配置文件中的
save9001save30010save6010000#stop-writes-on-bgsave-erroryes#rdbcompressionyes#rdbchecksumyes#dbfilenamedump.rdb#dir/usr/local/var/db/redis/
- save m n：代表Redis服务器在m秒内数据存在n次修改时，自动触发rdb。这个参数比较关键。
- stop-writes-on-bgsave-error：如果是yes，当bgsave命令失败时Redis将停止写入操作。
- rdbcompression：是否对RDB文件进行压缩，但是在LZF压缩消耗更多CPU
- rdbchecksum：是否对RDB文件进程校验
- dbfilename：配置文件名称，默认dump.rdb
- dir：配置rdb文件存放的路径，这个参数比较重要。
- RDB的优缺点：
因为bgsave每次运 行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。所以不适用于实时持久化
但是其数据体量小，执行速度快，适合备份。
2、AOF持久化
AOF以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令来恢复数据。AOF的主要作用 是解决了数据持久化的实时性
AOF的工作流程：
所有的写入命令追加到aof缓冲区
AOF缓冲区根据对应appendfsync配置向硬盘做同步操作
定期对AOF文件进行重写
Redis重启时，可以加载AOF文件进行数据恢复
触发机制：
（1）手动触发
使用bgrewriteaof命令：Redis主进程fork子进程来执行AOF重写，这个子进程创建新的AOF文件来存储重写结果，防止影响旧文件。因为fork采用了写时复制机制，子进程不能访问在其被创建出来之后产生的新数据。Redis使用“AOF重写缓冲区”保存这部分新数据，最后父进程将AOF重写缓冲区的数据写入新的AOF文件中，然后使用新AOF文件替换老文件。
（2）自动触发
和RDB一样，配置在redis.conf文件里
appendonlyno#appendfilename"appendonly.aof"#appendfsynceverysec#no-appendfsync-on-rewriteno#auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb#aof-load-truncatedyes#aof-use-rdb-preambleno
- appendonly：是否打开AOF持久化功能
- appendfilename：AOF文件名称
- appendfsync：同步频率
- auto-aof-rewrite-min-size：如果文件大小小于此值不会触发AOF，默认64MB
- auto-aof-rewrite-percentage：Redis记录最近的一次AOF操作的文件大小，如果当前AOF文件大小增长超过这个百分比则触发一次重写，默认100
这里介绍一下appendfsync参数的可配置值
always：命令写入aof缓冲区后，每一次写入都需要同步，直到写入磁盘（阻塞，系统调用fsync）结束后返回。显然和Redis高性能背道而驰，不建议配置
everysec：命令写入aof缓冲区后，在写入系统缓冲区直接返回（系统调用write），然后有专门线程每秒执行写入磁盘（阻塞，系统调用fsync）后返回
no：命令写入aof缓冲区后，在写入系统缓冲区直接返回（系统调用write）。之后写入磁盘（阻塞，系统调用fsync）的操作由操作系统负责，通常最长30s
打开AOF功能把appendonly值改为yes即可。
AOF优缺点：
对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据 如果你要保证一条数据都不丢失，也是可以的，将AOF的fsync设置为没写入一条数据就fsync一次，但是Redis的性能将会大幅度下降。
AOF的持久化也可能会造成阻塞。
扩展：
AOF重写的流程。
- 执行AOF重写请求。
- 如果当前进程正在执行bgsave操作，重写命令会等待bgsave执行完后再执行。
- 父进程执行fork创建子进程。
- fork操作完成后，主进程会继续响应其它命令。所有修改命令依然会写入到aof_buf中，并根据appendfsync策略持久化到AOF文件中。
- 因fork操作运用的是写时复制技术，所以子进程只能共享fork操作时的内存数据，对于fork操作后，生成的数据，主进程会单独开辟一块aof_rewrite_buf保存。
- 子进程根据内存快照，按照命令合并规则写入到新的AOF文件中。每次批量写入磁盘的数据量由aof-rewrite-incremental-fsync参数控制，默认为32M，避免单次刷盘数据过多造成硬盘阻塞。
- 新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
- 父进程将aof_rewrite_buf（AOF重写缓冲区）的数据写入到新的AOF文件中。
- 使用新AOF文件替换老文件，完成AOF重写。
- 实际上，当Redis节点执行完一个命令后，它会同时将这个写命令发送到AOF缓冲区和AOF重写缓冲区。
