Redis是基于内存，数据默认是在内存中操作，如果服务器重启内存的数据将会丢失，为了确保数据不丢失，Redis提供了2个不同形式的持久化方式。
- RDB (Redis DataBase)
- AOF (Append Of File)
1. RDB持久化
在指定的时间间隔内将内存中的数据快照存储到硬盘中。
1.1 RDB持久化流程 
RDB持久化时会创建一个单独的fork子进程先将内存的数据进行压缩成一个临时文件中，然后再将临时文件替换上次持久化的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。数据在写入时，父进程将原有的内存数据复制，等快照执行完成后将数据写入到原内存区域中。
1.2 RDB的配置项
appendonly no //这个是aof的配置项，如果开启的话则使用aof持久化
stop-writes-on-bgsave-error yes //默认为yes,保存数据失败，Redis是否停止接收数据
rdbcompression yes // 默认为yes 存储到磁盘中的快照，可以设置是否进行压缩存储
rdbchecksum yes //默认值是yes。在存储快照后是否使用CRC64算法来进行数据校验，这个功能会增加大约10%的性能消耗
dbfilename dump.rdb // 默认为dump.rdb 设置持久化文件的文件名
dir //设置持久化文件的存放路径
1.3 RDB持久化的优劣势
优势：
- 是某个时间节点的数据集，节省磁盘空间，适合大规模的数据恢复
- 在持久化时是在一个子进程中工作，主进程不需要进行任何磁盘IO操作
- 恢复速度比 AOF 的恢复速度要快
劣势：
- 在持久化过程中数据被复制了一份会占有两倍的空间比较消耗性能
- 它是在一定时间间隔内做持久化，所以如果在该时间间隔中出现宕机的话会有部分数据的丢失
2. AOF持久化
通过日志的形式增量保存写操作的指令，只在文件后面追加，不修改原来文件。
2.1 AOF持久化流程
当有Redis执行命令发生时，会将执行命令追加到buffer中(AOF缓冲区)，缓冲区将执行命令同步追加到AOF文件中，当Redis服务器重启时，就会加载AOF文件进行数据恢复。由于AOF文件会越来越大，Redis也提供定期重写(rewrite)功能。
2.2 AOF配置项
appendonly yes //使用aof持久化
appendfilename appendonly.aof // 默认appendonly.aof 文件名称，路径跟rdb的一致
appendfsync [always、everysec、no] //缓冲区同步到AOF文件的执行策略
| always | 一直同步，每次写操作都会同步记录下来，这种操作比较频繁，性能较差，数据较完整 |
| everysec | 每秒同步一次，在同一秒内的数据可能会丢失 |
| no | 不主动同步，需要有操作系统或者客户端命令进行同步 |
auto-aof-rewrite-min-size 64MB //设置文件达到最小值时重写
auto-aof-rewrite-percentage //设置文件内容达到百分之几时重写
2.3 AOF的优劣势
优势
- 数据丢失的概率更低
- 有重写机制，有一定的容错率
劣势
- aof文件较大，需要占用更多的存储空间
- 重启恢复时的速度较慢
- 可能存在BUG
3. RDB和AOF如何选择
- 官方建议两个都同时启用,不推荐单独使用AOF
- 如果数据不需要绝对的完整性可以只是用RDB
- 如果只用户内存的缓存使用的话可以不需要持久化