介绍
Redis 做为一款内存型的 key-value 数据库，对于数据的永久保存只有将数据存放于硬盘中，而将内存中的数据迁移到硬盘的过程就是持久化。数据能够永久储存才能是数据库软件作为生产力工具的重要标准，对于随时可能会丢失的数据，企业或个人会逐渐丧失使用的信心。Redis 持久化有两种方式，一种是通过特定时间节点形成的快照（RDB持久化），另一种是由日志（AOF持久化）来进行备份管理。
RDB持久化
- RDB 的配置
通过配置文件指定备份的时间间隔，数据集依据这个时间节点形成快照，快照默认保存在 dump.rdb 文件中。
当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：
1、Redis 调用 fork() ，同时拥有父进程和子进程。
2、子进程将数据集写入到一个临时 RDB 文件中。
3、当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB
文件。
以下是RDB的触发条件配置选项，意思为60秒内至少有1万次改动，就开始生成快照，如果60秒不够1万次，开始查找300秒内是否有10次改动，以此向上类推。除了自动保存，RDB也可以通过手动执行save 和 bgsave 来生成快照。
#RDB进行备份的触发条件
save 900 1
save 300 10
save 60 10000
如果开启RDB后，磁盘出现问题，比如磁盘空间不足导致持久化失败，redis 将停止写入操作，直至硬盘恢复正常，直接停止 redis 的工作是个很无奈的举动，但是如果不这样做用户可能无法及时发现磁盘问题，如果通过其它方式正确监视 redis 的持久化状态，则这个选项可以选择关闭。
stop-writes-on-bgsave-error yes
- RDB的优点
1、面对大数据的恢复速度很快
2、适合容灾备份，备份存储的是一个内容紧凑的二进制文件，加密后可上传至其它数据中心
3、最大化 redis 的性能，在备份时只需要分出一个子进程去处理，父进程无需进行任何磁盘 I/O 操作
- RDB的缺点
1、因为 RDB 保存的是一个时间段内的所有数据，所以执行保存操作时很耗时，当数据非常多时，会造成服务端停止处理客户端的请求
2、RDB 文件采用的是时间节点保存，如果在下次保存前服务器发生故障宕机，就会丢失这个时间段内的数据，对数据保存有更高要求的应用场景不适合
AOF持久化
通过将命令以日志的形式逐条追加到文件中，相比 RDB 可能会存在的时间间隔“漏洞”，这种逐条记录命令的形式更容易减少数据丢失的数量，当 redis 服务重启时，就会根据日志中记录的命令恢复数据。
- AOF 配置
#默认关闭，输入YES就可以启用 AOF 持久化
appendonly yes
同步频率有三种方式：
1、每执行一次命令，就在文件末端写入一次，速度很慢，但安全性最高
2、每秒执行一次，速度很快，如果发生故障会丢失1秒的数据，redis 默认配置
3、从不同步，将数据交给操作系统去处理，速度更快，但安全性较差
#每执行命令写入
appendfsync always
#每秒执行命令写入
appendfsync everysec
#不执行写入
appendfsync no
- AOF 重写
AOF 相对于 RDB 的形式，是记录每一次的更新操作，它的文件大小是要大于 RDB 的，并且对于一个 KEY 的多条命令，在恢复时只需要用到最新的一条命令就可以了，考虑到以上需要优化的两点，redis 为 AOF 提供了文件重写功能，精简了命令记录的同时也起到了缩减文件大小的作用，这个操作不会影响主进程的运作。
#当文件增长大于 100% 时重写
auto-aof-rewrite-percentage 100
#当文件大小大于 64MB 时重写
auto-aof-rewrite-min-size 64mb
当 AOF 开始重写时，服务器做一下操作：
1、Redis 调用 fork()，分出一个子进程处理同步
2、子进程将新的 AOF 文件内容写入到临时文件中
3、对于新执行的命令，一边累加到内存缓存，一边追加到AOF文件末尾，这样如果发生服务器故障导致不会影响现有的 AOF 文件
4、子进程工作完成，父进程会将缓存中的所有数据追加到AOF文件中
5、Redis 原子性的操作新的文件替换旧文件，之后新的命令都追加到新文件中
- AOF 错误修复
如果服务器正在对 AOF 文件写入时停机，会造成 AOF 文件出错，再次启动服务时，为了保证数据一致性不会被破坏，redis 拒绝接入有错误的 AOF 文件，这个时候可以修复 AOF 文件来使其恢复正常工作，方法如下：
1、备份现有的 AOF 文件，确定一个修复前的文件节点
2、使用 redis-check-aof
3、重启 redis 服务等待重新载入 AOF 文件
- AOF 的优点
1、数据存储的精度得到了很大都提升，即使发生故障也只是丢失1秒钟的数据
2、文件写入时如果发生问题，可以通过 redis-check-aof 轻易修复
3、文件体积过大时，可以通过重写来精简记录的命令，缩小文件体积，重写是原子性操作有效保护了数据
4、AOF 文件以 redis 协议有序保存，可读性很强，方便排查问题
RDB 和 AOF 如何选择
1、对于数据保存的要求不太高，如果发生故障，可以接受几分钟内的数据丢失，那么选择 RDB 持久化的方式是一个很好的备份手段，按时间节点存储片段的特性很适合做数据库备份，恢复速度也比 AOF 的快
2、对于数据保存要求高的，就选择 AOF 持久化方式
3、两种持久化方式可同时使用，但发生故障时要恢复时，会优先 AOF 的备份，因为通常 AOF 的备份的数据更加完整
容灾备份
数据库的备份非常重要，是项目设计里不可缺失的一部分，至少要每天都要对数据库进行备份，可以使用 RDB 进行备份，并将备份后的文件加密上传到亚马逊或阿里云这样可靠的数据中心进行存储。
