前言：
redis持久化方式分为两种：RDB快照和AOF方式（默认为RDB模式），当Redis服务器重启的时候，会自动恢复数据，优先从AOF中恢复，其次才从RDB中恢复
一、RDB快照模式
RDB方式原理：当redis需要做持久化时（执行SAVA或者BGSAVA命令，或者是达到配置条件时执行），redis会fork一个子进程，子进程将数据写到磁盘上一个临时RDB文件中，当子进程完成写临时文件后，将原来的RDB替换掉（默认文件名为dump.rdb）
RDB备份条件和命令：
1、执行SAVE命令，在当前线程执行，会卡住
2、执行BGSAVE命令，在后台线程执行，马上返回
已经预置了3个条件：
save 900 1 # 900秒内有至少1个键被更改则进行快照 save 300 10 # 300秒内有至少10个键被更改则进行快照 save 60 10000 # 60秒内有至少10000个键被更改则进行快照
RDB优缺点：
定时备份，Redis效率高，但是容易造成数据丢失，丢失的多少和备份策略有关，例如：5分钟备份一次，但是第8分时宕机了，那么就丢失了后面的3分钟数据
一、AOF模式
AOF方式原理：AOF就可以做到全程持久化，Redis每执行一个修改数据的命令，都会把这个命令添加到AOF文件中，当Redis重启时，将会读取AOF文件进行“重放”以恢复到 Redis关闭前的最后时刻。
由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）
appendonly yes //启用aof持久化方式
# appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
# appendfsync no //完全依赖os，性能最好,持久化没保证
AOF优缺点
AOF基本可以保证数据不丢失，但是AOF持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。
