Redis如何让数据持久化
redis 简单来说有三种持久化策略：
- RDB持久化
- AOF持久化
- RDB-AOF混合持久化
- RDB持久化
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
可以对Redis进行设置，让它在“N秒内数据集至少有N个改动”， 这一条件被满足时，自动保存一次数据集。比如说：让Redis满足“60秒内至少有1000个键被改动”这一个条件时，自动保存一次数据集。修改redis 配置文件如下 （配置文件文件为 redis.conf）：
save 60 1000当然，也可以手动进行RDB持久化操作，进入redis直接输入如下:
save | 阻塞Redis的服务器进程，直到RDB文件被创建完毕
bgsave | Fork出一个子进程来创建RDB文件，不阻塞服务器进程
lastsave | 指令可以查看最近的备份时间- AOF持久化 （Append-Only-File）
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
可以配置redis多久才将命令持久化到磁盘一次。修改redis 配置文件如下：
appendfsync always | 每次有新命令追加到aof文件时就执行一个持久化，非常慢但是安全
appendfsync everysec | 每秒执行一次持久化，足够快（和使用rdb持久化差不多）并且在故障时只会丢失1秒钟的数据
appendfsync no | 从不持久化，将数据交给操作系统来处理。redis处理命令速度加快但是不安全。默认情况下 ，每秒执行一次fsync， 这种fsync策略可以兼顾安全性和速度。
rdb和aof的区别：
redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof文件一般来说数据更安全一点。
- RDB和AOF的优缺点
RDB优点：全量数据快照，文件小，恢复快
RDB缺点：无法保存最近一次快照之后的数据，数据量大会由于I/O严重影响性能
AOF优点：可读性搞，适合保存增量数据，数据不一丢失
AOF缺点：文件体积大，恢复时间长
- RDB-AOF混合持久化
重启redis恢复数据集时，很少会使用rdb来恢复内存状态，因为会丢失大量数据。通常会使用aof日志恢复数据，但是重放aof日志性能相对rdb来说要慢很多，这样在redis实例很大的情况下，启动需要花费很长时间。Redis4.0为了解决这个问题，带来了新的持久化选项——混合持久化。要开启混合持久化则修改redis 配置文件如下：
aof-use-rdb-preamble yes如果开启了混合持久化，aof在重写时，不再是单纯将内存数据转换为RESP命令写入aof文件，而是将重写这一刻之前的内存做rdb快照处理，并且将rdb快照内容和增量的aof修改内存数据的命令存在一起，都写入新的aof文件，新的aof文件一开始不叫appendonly.aof，等到重写完成后，新的aof文件才会进行改名，原子的覆盖原有的aof文件，完成新旧两个aof文件的替换。
于是在redis重启的时候，可以先加载rdb文件，然后再重放增量的aof日志就可以完全替代之前的aof全量文件重放，因此重启效率大幅得到提高。
