作为内存数据库，Redis 在数据存储与读取上的速度是毫不逊色的，这点毋庸置疑。但是对于内存来说，断电或遇到故障后数据就会丢失，这却是一个无法回避的问题。令人欣慰的是，基于这样的缺点，Redis 也提供了不同的持久化方案。
各位看官请随小莱接着往下看：
图注：思维导图
RDB持久化对于 Redis 持久化来说，其实就是将存储在内存中的数据写入到磁盘里，只不过写入的方式是有一定策略的。
那么我们先来看下第一种持久化，首先出场的是 RDB。
1、什么是RDB持久化英文名称是 Redis DataBase，它还有一个常用的名字：快照持久化。所谓快照，在这里指的是某一时刻的内存数据，而持久化则是将这一时刻的数据以二进制形式写入到磁盘里。
2、手动触发机制 （1）save 命令
你可能会问了，那我通过什么样的方式来实现持久化呢？不知道你有没有用过 save 这个命令，在 Redis 里担任的角色是用来手动触发持久化的。也就是说在 Redis 客户端操作 save 命令就可以将内存数据写入到磁盘里。
不过你可千万不要好奇，生产环境要是这么玩儿的话，数据量少还行，数量大的话那估计八成得凉凉。为什么这么说呢？你稍微了解下它的运行原理就知道了。
前面的文章中，我们提到了 Redis 处理命令的方式是以单线程形式来进行的。客户端的请求都会放入一个队列里。当执行 save 命令时，如果执行时间很长的话，后面的请求就会被阻塞，客户端发送的所有命令都会被拒绝。
这种方式生产场景要慎用！
（2）bgsave 命令还有一个 bgsave 命令。与 save 不同的是，执行过程中它并不会阻塞客户端的请求。而是将持久化工作交给子进程来执行，主进程仍负责客户端请求的处理工作。
RDB 持久化既可以通过手动触发，也可以通过服务器配置项来定期执行。
自动触发通常是 Redis 中配置文件来执行的。有这么个配置你需要了解下：
save m n其中 m 代表秒数，n 代表次数，放在一起表示的是 m 秒内发生 n 次变化时，会触发 bgsave。
了解了自动化配置，我们再来看下 Redis 配置文件 redis.conf 中的三个默认配置项：
save 900 1 表示的是时间900秒内，如果 Redis 中数据至少发生一次变化，就会执行 bgsave。后边两个就不用介绍了，一样的原理。
看到这三个配置项，不知道你会不会有疑问，这三个到底该执行哪一个？答案是设置多个 save m n 命令时，满足任何一个条件都会触发持久化。
4、RDB 文件恢复前面我们提到过了，持久化的目的就是为了解决内存异常导致的数据丢失问题。那么倘若如果真遇到了这样的情况，RDB 文件如何来实现数据恢复呢？
开启自动持久化后，数据会存储到名为 dump.rdb 的文件中。当 Redis 服务器重启时，检测到 dump.rdb 文件后，会自动加载进行数据恢复。
AOF持久化介绍完了 RDB 后，我们再来看一种叫作 AOF 的持久化方式。
1、什么是AOF持久化