一、 文档介绍
redis作为一个内存数据库，读写快，效率高，但是也会有宕机丢失数据的风险，于是就需要持久化操
Q&A：
数据量大于内存大小时应该怎么做？
增加内存or采用内存淘汰策略orRedis集群
持久化会辅助扩大Redis的存储空间么？
不会，持久化的主要作用是数据备份，保证数据不会因进程退出而丢失
（在dump的基础上开始准备Restore的实现，dump操作的第一步就是将aof文件内的记录同步到redis内，故了解一下aof文件）
二、RDB与AOF持久化的原理
2.1 RDB
RDB可以认为是Snapshot文件，当恢复时，通过加载RDB文件。把数据从磁盘加载读取到Redis中。
RDB产生：（考虑快照时的操作）
- SAVE方式：阻塞请求
- BGSAVE：fork一个子进程，子进程将快照写到一个临时的RDB文件，写完之后替换旧的RDB文件
RDB的加载：
Redis持久化可以禁用，此时数据仅存在于服务器的运行时间内
Redis持久化也可以共存，当同时存在的时候，Redis重启是会先加载AOF文件
2.2 AOF
AOF可以认为是日志文件，Append only File，每次对数据的变更或者操作都会先记录打AOF内，当服务启动的时候就会先读取这些文件，重新执行一遍来恢复原始数据。
AOF提供三种同步（写aof文件与操作数据的同步）的方式：
- always：每次操作记录都同步到磁盘上，最低效，最安全
- everysec：每秒执行一次将操作记录同步到磁盘。默认
- no：不自动执行同步，让操作系统将缓存数据写到硬盘上，不可靠，最快
AOF文件的格式与解析：
- *，表示命令的参数个数，例如上面的set a 1 是三个 因此为*3
- ¥，表示参数的字节数，例如a这个参数是一个字节，因此为$1
- 无符号，表示是参数数据
AOF优化：（重写）
当对一个现在为0的值执行100遍“a++”操作的话，如果每一次都记录一个操作再同步，非常浪费资源与时间，并且文件也会变大，重写即将这一百条数据写成set a 100，减少文件大小，并且提高载入速率
三、RDB与AOF的优缺点
3.1 RDB
优点：
- RDB是某一个时间点的备份，是一个紧凑的单文件，多用于数据备份。可以按每小时或每日来备份，方便从不同的版本恢复
- 单文件方便远程传输便于故障恢复
- RDB可以Fork子进程进行持久化，使得Redis可以更好的处理用户的请求
- 在数据量大的情况下，RDB相比较于AOF加载的更快
缺点：
- 如果RDB保存不及时会导致数据丢失
- RDB经常需要Fork子进程去执行，fork操作十分耗费CPU，并且是全量的，AOF的Fork是增量的，并且AOF是可控的
3.2 AOF
优点：
- AOF可以设置 完全不同步、每秒同步、每次操作同，默认是每秒同步。因为AOF是操作指令的追加，所以可以频繁的大量的同步。
- AOF文件是一个值追加日志的文件，即使服务宕机为写入完整的命令，也可以通过redis-check-aof工具修复这些问题。
- 如果AOF文件过大，Redis会在后台自动地重写AOF文件。重写后会使AOF文件压缩到最小所需的指令集。
- AOF文件是有序保存数据库的所有写入操作，易读，易分析。即使如果不小心误操作数据库，也很容易找出错误指令，恢复到某个数据节点。例如不小心FLUSHALL，可以非常容易恢复到执行命令之前。
缺点：
- 相同数据量下，AOF的文件通常体积会比RDB大。因为AOF是存指令的，而RDB是所有指令的结果快照。但AOF在日志重写后会压缩一些空间。
- 在大量写入和载入的时候，AOF的效率会比RDB低。因为大量写入，AOF会执行更多的保存命令，载入的时候也需要大量的重执行命令来得到最后的结果。RDB对此更有优势。
三、取舍
一般来说，不考虑硬盘大小，最安全的做法是RDB与AOF同时使用，即使AOF损坏无法修复，还可以用RDB来恢复数据。
如果Redis的数据在你的服务中并不是必要的数据，例如只是当简单的缓存，没有缓存也不会造成缓存雪崩。说明数据的安全可靠性并不是首要考虑范围内，那么单独只使用RDB就可以了。
不推荐单独使用AOF，因为AOF对于数据的恢复载入来说，比RDB慢。