前言:
说到redis的持久化，大家可能就想到了RDB和AOF两种方式； 下面就这两种方案的意义以及两种持久化方案的工作原理。
持久化的意义
- redis的持久化意义在于故障恢复，数据恢复。 如果redis服务器挂了，遇到了灾难性的故障，redis不可用了；如果只是放在内存中，那么数据可能就没有了；如果我们通过持久化将数据持久化到磁盘中，然后定期同步到云存储服务器中，那么可以尽可能保证数据不会全部丢失，能够恢复一部分的数据。
- 还有一点，如果你的redis整个集群挂了，如果没有做持久化，数据没有备份，那么大量的其你去过来，缓存全部不能命中，也就是说在redis中找不到数据，这个时候可能就会出现缓存的雪崩问题，所有的请求直接打到数据库中。如果我们做了持久化，redis挂了，我们就可以恢复一部分redis中的数据，也就可以避免缓存雪崩的问题。
- 当然如果想要redis仅仅作为纯内存的缓存来用，就不需要持久化了。
RDB持久化机制介绍
优势：
1.对数据执行周期性的进行持久化。RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据。
2.对redis对外提供的读写服务，影响非常小，可以让redis保持高性能；因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
3.相比对AOF机制，如果数据量比较大，RDB的启动效率会更好。
劣势：
由于是周期性的持久化，所以如果要求数量完整性要求高的场景,可能使用AOF比较好一点。另外如果在生成快照的时候，文件比较大的时候，可能会导致本身提供的服务有停顿。
AOF持久化机制介绍
优势：
数据的安全性高，AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集
AOF可以更好的保护数据的完整性，一般是每个一秒就会有后台进程执行一次fsync操作；日志文件以append-only的模式写入，没有磁盘寻址的开销，写入性能高。
劣势：
因为AOF记得是指令日志，AOF的日志文件比RDB的快照会更大一点，不过这点可以忽略不计，因为现在存储的成本越来越低了。
AOF 可能比 RDB 慢，这取决于准确的 fsync 策略。通常 fsync 设置为每秒一次的话性能仍然很高，如果关闭 fsync，即使在很高的负载下也和 RDB 一样的快。
RDB和AOF如何取舍
1.通常来说，你应该同时使用这两种持久化方法。综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复
2.如果你很关注你的数据，但是仍然可以接受灾难时有几分钟的数据丢失，你可以单独使用 RDB。
如何配置RDB持久化机制
在redis.conf文件中配置持久化策略;
根据检查点去check是否又变更，如果有，就生成一个新的dump.rdb文件；每次生成一个新的快照，都会覆盖之前的老快照。
主要参数解释如下：
save 900 1
每隔900s，如果有超过1key发生了变更，那么就生成一个新的dump.rdb文件
save 300 10
每隔300s，如果有超过10key发生了变更，那么就生成一个新的dump.rdb文件
save 60 10000
每隔60s，如果有超过10000个key发生了变更，那么就生成一个新的dump.rdb文件
那我们就可以手动去配置检查点：
save 3 1 我们设置一个每隔3秒钟。 我们可以看到如果我们设置了检查点，过了3秒就会在服务器自动生成dump.rdb； 异常关掉任务之后（kill进程），数据会自动恢复。
如果我们没有配置这个检查点，用默认的检查点，数据则会丢失。
注：如果是正常shutdown，redis会自动生成一份rdb的dump文件。
如何配置AOF策略
AOF持久化，默认是关闭的，默认打开RDB持久化
appendonly yes，可以打开AOF持久化机制；AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入os cache的，然后每隔一定时间再fsync一下
fsync总共有三种策略可以选择：
always: 每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低;
everysec: 每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高
no: redis负责将数据写入os cache就不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控
AOF rewrite:
redis中的数据会不断的被淘汰掉，但是对应的写入日志还在AOF中，AOF就一个，所以会越来越大。基于以上原因，AOF会在后台每隔一定的时间做rewrite操作；
在redis.conf中，可以配置rewrite策略
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
假设上次AOF rewirte之后为100Mb，然后接着写AOF的操作日志，如果发现增长的比例超过100% ，并且比64Mb大的话，则会再做一个rewrite，否则不会触发。
具体rewrite步骤：
（1）redis fork一个子进程
（2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志
（3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件
（4）子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中
（5）用新的日志文件替换掉旧的日志文件
AOF文件修复
如果机器宕机了，我们可以用redis-check-aof –fix命令来修复破损的AOF文件
AOF和RDB同时工作
（1）如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting
（2）如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite
（3）同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使AOF进行数据恢复，因为其中的日志更完整