目录
对于redis来说，他的数据不仅保存在内存中，其实在硬盘中也有数据备份。一般来说在像redis中插入数据的时候，redis会将数据既写到内存中又写入硬盘中，当查询某个数据的时候，是直接从内存中读取。redis的持久化能够将数据恢复到内存中，避免redis服务重启的时候数据丢失。
针对redis的持久化，存在不同的策略。
RDB策略
RDB（Redis DataBase）策略会定期的把我们redis内存中的所有数据，都给写入硬盘中，生成一个"快照"。保存redis数据的文件为在/var/lib/redis路径下的dump.rdb文件中。
当我们在redis中添加这样的数据并手动保存数据：
在dump.rdb文件中以二进制格式进行保存，内容如下:
RDB策略触发方式为手动和自动触发两种方式。
1.手动触发
save命令
通过save命令，来触发生成快照，当执行save的时候，redis作为单线程模型会一直将这个命令执行完毕，才会处理其他请求，如果要保存的数据特别大那么很可能造成阻塞，一般不推荐这种方法。
bgsave 命令
命令执行流程图：
Redis 主进程会先检查当前是否已有持久化操作正在进行，如果有，则直接返回错误。如果没有，主进程会调用 fork 创建一个子进程。
在fork 阶段，主进程会出现短暂阻塞以复制页表，但完成后主进程仍然可以继续处理其他请求。
子进程通过 fork 得到与主进程相同的页表，最初共享相同的物理页数据。随后，子进程依次将所有数据写入一个临时 RDB 文件。
如果在此期间主进程对数据进行了新增或修改，内核会通过写时复制（COW）机制，为被修改的物理页复制一份新的物理页，父进程在新页上修改，子进程则继续读取原始页，从而保证快照的一致性。
当子进程写入完成后，它会使用原子操作将临时文件替换旧的 dump.rdb 文件，进程发送信号给父进程表示完成，父进程更新统计信息，然后退出并销毁自身。
2.自动触发
通过修改redis的配置文件，能够达到定时自动触发RDB保存的效果。进入/etc/redis目录，打开redis.conf配置文件。
此处说明在配置文件中通过在特定时间内，进行修改的次数超过指定次数就会触发依次RDB。
例如save 3600 1 : 如果在3600秒（一小时）内至少有1次修改，那么时间一到就会自动触发RDB操作
redis默认的自动保存时机为：
3600 秒（1 小时）内至少发生 1 次修改
300 秒（5 分钟）内至少发生 100 次修改
60 秒内至少发生 10000 次修改
配置文件中# save 3600 1 300 100 60 10000这一行被注释（#开头），只是表示 “没有显式配置”，但 Redis 会自动使用上述默认规则。如果需要修改或禁用自动保存，才需要显式配置。
如果显示进行修改，那么就会按照我修改的60秒内，至少发生2次修改就会进行自动保存。
AOF策略
AOF（Append Only File）策略是以日志形式记录 Redis 接收到的所有写命令，重启时再重新执行 AOF
文件中的命令达到恢复数据的目的。与RDB区别是，这是通过文本的形式保存数据，而RDB保存的是二进制文件。AOF 的主要作用是解决了数据持久化的实时性。
开启AOF
使用AOF策略需要在配置文件中开启，配置文件路径同样是在/etc/redis/redsi.conf，找到下面选项讲no改为yes即可开启。
开启后
在redis中增加下面这几条数据：
aof缓冲区文件格式为：
AOF工作流程
1.每当redis接收到写命令，会将该命令写入到AOF缓冲区（该AOF缓冲区遵守Redis 格式协议）。
2.AOF 缓冲区根据对应的同步策略（appendfsync）向硬盘做同步操作。
3.当 Redis 服务器启动时，可以加载 AOF 文件逐条解析命令并执行，恢复数据。
同步策略
AOF 缓冲区同步文件策略同样是通过/etc/redis/redsi.conf该路径下的配置文件进行选择修改。
不同的配置能够调整数据的性能和可靠性之间的权衡
always：每次写命令都立刻 fsync 到磁盘，频率最高，数据可靠性最高，性能最低。
everysec：每秒 fsync 一次，频率低一些，数据可靠性也降低一些，性能有所提高。
no：让操作系统决定什么时候fsync（例如缓冲区满，进程正常退出），频率最低，数据可靠性最低，性能最高。
重写机制
如果 AOF 文件长期只追加，会越来越大，恢复时速度会变慢，所以需要 压缩，“压缩”指的是 逻辑重写，把 AOF 文件中冗余的历史命令去掉，仅保留能恢复当前数据库状态的最小命令集，从而减小文件体积、提升恢复效率。因此就有了重写机制（bgrewriteaof），该机制触发时机分为手动触发和自动触发。
手动触发
手动触发是直接调用bgrewriteaof命令即可触发重写机制。
注意：如果执行bgrewriteaof命令的时候，redis会先判定当有正在执行aof命令，此时不会在执行该命令了，就会直接返回。如果执行bgrewriteaof命令的时候，redis发现当前正在执行rdb文件的快照，那么aof操作就会进行的等待，等待rdb文件执行完毕后再执行aof重写。
自动触发
自动触发是根据配置文件中 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时
机。
auto-aof-rewrite-percentage：代表当前 AOF 占用大小相比较上次重写时增加的比例。
auto-aof-rewrite-min-size：表示触发重写时 AOF 的最小文件大小，默认为 64MB。
AOF重写流程
Redis fork创建子进程。
子进程根据当前内存状态，写一个全新的临时 AOF 文件。
父进程任然负责接收请求，并把新写命令记录到 aof_buf 重写缓冲区和aof_rewrite_buf缓冲区
子进程写完后发送信号通知父进程，父进程将aof_rewrite_buf缓冲区中的命令一次性追加到新AOF文件，并让新AOF文件覆盖旧 AOF 文件。
通过重写机制，新AOF文件 覆盖旧 AOF 文件，这样生成的新 AOF 文件更小，恢复速度也快。这里的子进程写数据的过程，非常类似于RDB生成一个镜像快照。
注意：子进程写好的新的AOF文件每次都会替代旧的AOF文件，那么父进程还是需要往aof_buf缓冲区写入数据，因为在极端情况下，如果子进程还未写完数据服务器出现掉电或者异常终止，那么子进程内存中的内容就会丢失，新的aof文件不完整，而有了父进程持续的写入旧文件，能够确保提高数据的完整性。
混合持久化
AOF本来是按照文本的方式进行文件写入的，但是文本的方式写文件相较于二进制来说服务重启的加载成本比较高，速度比较慢。redis就引入了“混合持久化”的方式，结合了rdb和aof的特点。在配置文件中默认开启
在触发重写后，会把当前的内存状态按照rdb的二进制格式写入到新的aof文件中，后续再进行的操作任然是按照aof文本的方式追加到文件后面。