Redis中的数据是保存在内存中的，内存虽然读取速度相比较磁盘要快几个数量级，但如果出现了宕机、掉电等异常情况，内存中的数据就会完全丢失。我们需要一种机制来保障Redis中的数据，即使出现了宕机等异常情况，也可以进行恢复，也就是将内存中的数据保存到磁盘等存储介质中，这就是我们说的持久化。
Redis主要提供了RDB和AOF两种持久化的机制。
RDB
RDB就是相当于给当前所有的数据拍一个快照，在磁盘中进行保存，Redis可以根据这个文件恢复数据。要开启RDB持久化，我们需要在配置文件中新增以下配置：
进入执行目录，执行命令./redis-server /usr/local/redis/redis-stable/conf/rdb.conf 启动redis服务
手工修改5次数据，触发60秒内5个KEY修改的条件，自动生成RDB文件：
除了自动触发外，我们可以手工执行bgsave或者save命令，让Redis马上进行RDB文件的生成
1、手工执行bgsave命令，redis会fork一个子线程异步去进行RDB持久化工作，持久化过程中redis能够正常处理请求（如果redis内存占用过高，可能会导致fork的时间过长，导致响应时间变长，需合理评估redis的容量）：
2、手工执行save命令，redis会阻塞新的请求，全力进行RDB持久化工作，生产环境几乎不会进行save操作，为了持久化而牺牲可用性，相当于丢了西瓜捡了芝麻。
AOF
Redis每次写入命令都会写入aof_buf缓冲区，再根据写入磁盘的策略进行持久化
新建一个aof.conf配置文件，其中核心配置如下：
启动redis服务器： ./redis-server /usr/local/redis/redis-stable/conf/aof.conf
并在启动后执行写入命令
aof日志文件会记录每次数据写入的命令，这样redis就可以通过重新执行AOF文件中的命令，来恢复数据。
随着Redis数据的不断写入，AOF文件也会越来越大，这样会导致两个问题？一是越大的AOF文件越不利于Redis进行数据恢复，二是AOF文件中存在需要无效数据。
key为a的这个数据经过多次修改最终被删除，理论上我们已经不需要a了，但是aof文件中还是记录了修改a的指令，这样重放AOF文件时还有重新执行set命令，这是一种无效的浪费，因此Redis提供了AOF文件的重写操作。
1、手工执行bgrewriteaof命令，可以看到执行完成后AOF文件进行了重写
2、在配置文件中配置AOF自动重写
#Redis会记住上次重写的文件大小，如果文件超过了上次重写大小的50%则进行自动重写
auto-aof-rewrite-percentage 50
#文件大小至少超过1mb，才有可能触发自动重写
auto-aof-rewrite-min-size 1mb
通过不断重写数据，触发AOF自动重写：
为什么AOF文件目录中有RDB文件？
因为自Redis4之后，Redis重写默认开启了混合模式，新增的数据会优先写入AOF文件，当触发重写后会重写为RDB格式，结合了RDB体积小易恢复和AOF数据全不易丢失的优点。
生产环境RDB和AOF的取舍？
1、AOF作为RDB的补充，如果不是完全无法容忍数据丢失，可以关闭AOF，通过集群备份的方式进行持久化
2、根据业务场景制定监控策略，定时、分场景进行RDB备份
