redis为开发这提供高效稳定快速的数据缓存方案，但是redis不能无限制的将数据放到内存中，遇到服务器宕机，那么缓存中的所有数据将丢失，那么为了避免这种情况redis提供了两种方式做持久化将数据存储到硬盘，一种是RDB（快照） 一种是AOF。
二者的区别：
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
对内存中数据库状态进行快照
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
把每条写命令都写入文件，类似于mysql的binlog日志
二者优缺点：
RDB优点：
1. 通过合理的配置，可以让Redis每隔一段时间就保存一次数据库副本，也可以很方便地将数据还原到特定的时间点。
2. RDB文件相比AOF占用的空间更小，恢复数据的速度也更快。
3. 如果创建RDB文件时出现了错误，Redis不会将它用于替换原来的文件，所以出错时不会影响到之前保存的版本。
4. 适合大规模的数据恢复，如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
RDB缺点：
1. 如果硬件、系统、Redis三者其中之一出现问题而崩溃，Redis会丢失全部数据，保留下来的数据只有上一个时间点创建的快照。如果数据对于应用程序来说非常重要，那么出现错误时的损失会非常大。
2. fork子进程占用的内存随着数据库中数据的增加而增加，耗费的时间也会越来越多
AOF 优点：
1. 该机制可以带来更高的数据安全性，即数据持久性。 数据的完整性和一致性更高
2. 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。3. 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4. AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。我们也可以通过该文件完成数据的重建。
AOF 缺点：
1. 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。 因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。
2. 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
常用配置：
RDB持久化配置：
Redis会将数据集的快照dump到dump.rdb文件中。我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
AOF持久化配置：
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
redis 持久化的两种方式和恢复：
如果同时启动了AOF和ROB方式，AOF优先，启动时只加载AOF文件恢复数时之家在
ROB方式：
ROB文件的载入工作是在服务器启动时自动执行的，没有专门用于载入ROB文件命令，只要Redis服务器再启动时检测到ROB文件存在，它就会自动载入ROB的文件，在服务器载入的期间，会一直处于阻塞状态，知道载入工作完成为止
AOF方式：
服务器在启动时，通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据，具体库状态过程：
1. 载入AOF文件
2. 创建模拟客户端
3. 从AOF文件中读取一条命令
4. 使用模拟客户端执行命令
5. 循环读取并执行命令，直到全部完成
RDB与AOF如何选择：
一般来说，如果想达到足以媲美PostgreSQL的数据安全性，应该同时使用两种持久化方式。
有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug。
如果可以承受输分钟内的数据丢失，可以只使用RDB持久化。
RDB快照步骤：
第一步：vim 修改持久化配置时间，120秒内修改5次则持久化一次。
第二步：重启服务使配置生效。
第三步：分别set 5个key，过两分钟后，在bin的当前目录下会自动生产一个dump.rdb文件。（set key6 是为了验证shutdown有触发RDB快照的作用）
第四步：将当前的dump.rdb 备份一份（模拟线上工作）。
第五步：执行FLUSHALL命令清空数据库数据（模拟数据丢失）。
第六步：重启Redis服务，数据是空的因为FLUSHALL也有触发RDB快照的功能。
第七步：将备份的 dump_bk.rdb 替换 dump.rdb 然后重新Redis。其他命令：
keys * 匹配数据库中所有 key
save 阻塞触发RDB快照，使其备份数据
FLUSHALL 清空整个 Redis 服务器的数据(几乎不用)
SHUTDOWN 关机（很少用）
AOF操作步骤：
AOF Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
第一步：修改配置文件开启AOF持久化配置。打开 redis.conf 文件开启需要手动把appendonly no改为yes
第二步：重启Redis服务，并进入Redis 自带的客户端中。
第三步：保存值，然后模拟数据丢失，关闭Redis服务。
第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题）。
第五步：修改appendonly.aof，模拟文件异常情况。
第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。
第七步：校验appendonly.aof 文件。重启Redis 服务后正常。
AOF的重写机制：
AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。
