缓存应用在服务中我们经常都会使用的，其中尤其是Redis，今天给大家聊聊Redis的数据持久化。
Redis持久化主要有两种方式，一种是RDB，一种是AOF。
其中RDB（Redis DataBase）持久化是以快照（snapshotting）方式进行，把存在某一时刻的所有数据写入硬盘过程。
AOF（append-only file）是以追加文件方式持久化，它以日志文件的方式记录每次的写命令，在服务重启再重新执行AOF文件命令来恢复数据。
这两种数据备份方式即可以同时使用，又可以单独使用。
RDB 快照持久化
首先我们看下RDB快照方式，这种持久化方式主要分为手动触发和被动触发。
手动触发分为SAVE和BGSAVE，由于SAVE会阻塞Redis服务，直到RDB过程完成，所以生产环境我们主要使用BGSAVE操作，执行BGSAVE之后，Redis进程会执行fork子进程，让子进程负责，直到自动结束。
被动触发是由于我们配置文件进行了save配置选项，如果用户设置了多个配置save配置选项那么任何一个条件满足就会触发BGSAVE。
我们可以看下下面的一段配置：
1. save 60 10000 # 60s有10000次写入（修改）被动触发BGSAVE 2. save 900 10 # 900s有10次就触发BGSAVE，保存到硬盘（两个满足一个就触发） 3. stop-writes-on-bgsave-error no # 创建快照失败是否继续写命令 4. rdbcompression yes # 是否进行压缩（默认压缩） 5. dbfilename dump.rdb # 生成文件名
其中save的配置需要我们进行合理评估，过频繁会浪费资源，过于稀少可能会有丢失大量数据隐患。
在这里我们需要知道通过快照持久化的方式来保存数据，如果服务发生故障，用户将会丢失最近一次生成快照之后更改的所有数据。
当然如果缓存数据小于或者只有几个GB时候，使用快照进行保存数据没有啥问题的。
AOF 追加持久化
由于RDB快照持久化适合小规模或丢失一部分数据也不会造成问题的应用，但是大多数场景里面，我们需要尽量保证数据完整性，所以这里我们有了AOF这种方式。
AOF持久化会将执行的命令写到AOF文件的末尾，来记录数据发生的变化，所以只需要将AOF的文件命令在Redis重新执行一遍就能恢复AOF文件的数据。
但是AOF文件会随着命令的不断增加，文件会越来越大，所以Redis有了重写机制，通过重写机制来压缩控制文件大小。
重写机制的原理就是合并多个命令，比如同样 inc 操作了100次，那么就可以合并为1次进行，或者之前添加了某个数据，后面又删除了就可以删除之前无效的命令等等。
AOF重写这种方式和RDB触发同样分为手动触发和被动触发。
手动触发方式：bgrewriteaof
被动触发方式：auto-aof-rewrite-percentage, auto-aof-rewrite-min-sieze
我们可以看下下面的配置：
appendonly no # 是否进行aof持久化 appendfsync everysec # 每秒同步一次，有always，no选项 no-appendfsync-on-rewrite no # aof重写期间是否同步 auto-aof-rewrite-percentage 100 # 当前文件是上一次大小的两倍的时候触发重写 auto-aof-rewrie-min-size 64mb # 文件最小体积触发重写
AOF重写和RDB快照方式一样，都会创建子进程，然后AOF子进程进行文件重写，所以快照持久化因为创建子进程导致性能和内存问题在AOF一样存在。
通过AOF的方式能相对更完善保留数据，让我们更为放心。
在这儿我们需要知道服务重启之后Redis默认加载流程，优先加载AOF文件，如果没有再考虑加载RDB文件。
最后
我们来简单总结一下RDB和AOF优缺点：
RDB优点：压缩二进制适合备份，加载恢复数据比AOF快
RDB缺点：没法做到实时持久化，频繁操作消耗资源
AOF优点：通过追加命令可以实时持久化
AOF缺点：加载恢复数据慢
有了这两种持久化方式，我们服务在重启或者宕机的时候就能更加完整保留数据，除了进行持久化操作外，我们也应该尽量把数据文件备份到不同服务器，避免在出现严重问题的时候不会丢失数据。
