1.如何配置RDB持久化
在Redis安装目录下，由个6379.conf，这个文件可以去配置持久化。
# save ""
save 900 1
save 300 10
save 60 10000
save 900 1的意思就是每隔900s，有超过1个key发生变化，产生就产生一个dump.rdb文件，这个文件就是当前redis内存中的数据快照，这中操作过程也被称为snapshotting，快照。
我们也可以根据自己的需求手动调用save或者bgsave命令。save设置多个，就会有多个快照检查点，每到一个检查点，就会check一下，是否由指定的key数量发生了变更，如果有，就生成一个新的dump.rdb文件。
2.RDB持久化机制的工作流程
第一步，redis根据配置检查是否需要生成rdb快照文件。
第二步，如果需要快照生成，就fork一个子进程出来。
第三步，子进程将数据dump到临时的rdb快照文件中，也就是dump.rdb。
第四步，完成rdb快照文件的生成之后，会替换掉之前的老快照。
3.RBD的数据恢复实验
啰嗦了这么多，我们还是来实操一遍，看看redis的RDB持久化是否真的像我们所说的一样的去执行持久化工作流程的。
（1）启动redis后，生成几条数据（具体操作就不赘述了，用set命令生成），然后通过redis-cli SHUTDOWN这种方式区停掉redis，然后重启redis，去看看数据还在不在（通过get命令查看）。按照我们之前学的，我们生成几条数据后，在save配置时间之内停掉redis，按理讲应该是没有数据的，但是大家如果区实操了一边，就会发现还是由数据的，而且在/var/redis/6379/dump.rdb中，还发现了dump.rdb文件，说明redis进行了持久化，才让数据不被丢失。这是为什么呢？其实，通过redis-cli SHUTDOWN这种方式区停掉redis，是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照。
（2）那我们用什么命令来模拟redis宕机了呢？用kill -9粗暴杀死redis进程。这样我们就可以发现，系统斌没有生成dump.rdb文件，说明redis并没有进行持久化。其实这里大家可能还有疑惑，RDB不进行持久化并不代表这AOF不进行持久化啊，其实在默认配置中RDB是开启，AOF是关闭，等下会在AOF配置中讲解到。
（3）为了测试方便，我们添加了一个save配置，save 10 1
（4）写入几条数据后，估摸着大概超过10s，我们可以发现redis产生了dump.rdb文件，我们用cat命令可以在这个文件中看到我们设置的数据。
（5）异常停掉redis进程，再重新启动redis，显然redis的数据还在。
4.如何配置AOF持久化
上面我们已经讲到，AOF的持久化默认是关闭的，RDB的持久化默认是打开的，我们可以修改6379.conf来管理它们。
appendonly yes
在实际生产环境中，为了确保数据的完整性，一般是要打开AOF。打开AOF持久化机制后，redis每接收到一条写命令，就会写入日志文件中，当然是先写入os cache，然后每隔一定时间再fsync一下。
这时候大家可能由疑问了，如果同时打开RDB和AOF持久化机制，会怎么样？
答案是AOF持久化优先，即使两者都开启了，在redis重启的时候，优先通过AOF进行数据恢复的，因为AOF的特性使得数据比较完整。
在配置文件中，我们还可以设置AOF的fsync策略。
#每次写入一条数据执行一次fsync，它能确保数据一条都不丢，但结果就是性能非常非常的差，吞吐量很低
# appendfsync always
#每隔一秒执行一次fsync，这个是最常用，生产环境一般都这么配置，性能很高，QPS还是可以上万的
appendfsync everysec
#不主动执行fsync ，redis将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据输入磁盘，不可控了
# appendfsync no
5.AOF的数据恢复实验
其实和RDB的操作流程差不多，只要把RDB持久化关了或者是在RDB快照还没生成之前，杀死redis进程（当然得确保AOF持久化开启），重新启动redis进程，看看数据是否恢复回来。
6.AOF rewrite
redis中的数据是有限的，很多数据可能会自动过期，可能会被用户删除，可能会被redis用缓存清除的算法清理掉。
redis中的数据会不断淘汰掉旧的，就一部分常用的数据会被自动保留到redis内存中。所以可能很多之前的已经被清理掉的数据，对用的写日志海停留在AOF中，AOF日志文件就一个，会不断的膨胀，到很大很大。
所以AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志；redis删掉了90w数据，还剩10w数据；这样redis会基于内存中当前的10w数据构建一套最新的日志，覆盖之前的老日志，确保AOF日志不会过大，保证和redis内存数据量一致。
在redis 2.4之前，还需要手动开发一些脚本，crontab什么巴拉巴拉的，通过BGREWRITEAOF命令区执行AOF rewrite，但是redis 2.4之后，会自动在6379.conf中，可以配置rewrite策略。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
这些参数是什么意思呢？
比如说上一次AOF rewrite之后，是128mb，然后就是接着128mb继续写AOF的日志，如果发现增长超过了256mb，就可能去触发一次write。
这只是可能触发，此时还要和第二个参数比较，256mb > 64mb，才会去触发rewrite。
rewrite的具体过程：
（1）当redis检测到需要rewrite的时候，redis fork一个子进程。
（2）子进程开始往一个新的临时的AOF文件中写入日志
（3）主进程在内存中写入日志，同时新的日志也继续写入旧的AOF文件中
（4）子进程写完之后，主进程将内存中的新日志再次追加到新的AOF文件中
（5）用新的日志文件替换掉旧的日志文件。
（我当时以为讲的挺明白了，后来回过头一想，可能这些具体过程堆新手不太友好，听起来好像很绕，这里再讲一下。意思就是，子进程在内存中写新的日志文件，不过是写在临时的AOF文件。这时候客户端还在进行写操作，那么主进程也在旧的AOF中写入日志。等到子进程写完了，主进程会将子进程写日志的期间将新日志追加到新的AOF文件中，然后用新的AOF来替换掉旧的AOF。）
7.AOF破损文件的修复
如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件破损。用redis-check-aof --fix命令来修复破损的AOF文件。8.RDB和AOF同时工作会怎么样
（1）如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite；如果redis在执行AOF rewrite，那么就不会执行RDB snapshotting操作。
（2）如果RDB在执行snapshotting，此时用户主动执行BGREWRITEAOF命令，那么要等到RDB快照生成完之后，才会执行AOF rewrite。
（3）同时有RDB snapshotting文件和AOF日志，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整，这点已经多次强调过了。
