Redis两种持久化方式：
1》RDB（snapshotting快照）
这种方式是将内存中的数据，以快照的方式写入到二进制文件中，存放默认文件是【dump.rbd】。
可以通过配置文件来配置这个持久的方式，说白了就是持久化频率，缓存数据我多久做一个持久化，每次持久化多少数据。
主要就是通过遍历所有缓存数据，通过【save】，全部持久化到一个【.rdb】格式结尾的文件中。
Save 900 1 //900秒后有1个key执行save Save 300 10 //300秒后有10个key执行save Save 60 10000 //60秒后有10000个key执行save
1》redis根据配置去尝试生成一个【.rdb】快照 2》redis-server会fork一个子进程 3》子进程将数据dump到一个临时【.rdb】文件中 4》然后通过临时文件来覆盖替换之前的持久化文件，并且每一次生一个新的临时文件都会做替换
如果redis服务一不小心宕掉的话，那么最后一次save持久化之后的数据，有可能全部丢失掉。
2》AOF（Append-onlyfile）
AOF就是将Redis每一次写命令都追加到持久化文件中，然后重启系统的时候，都会运行这个文件中的写命令。
// 表示Redis写操作后不回有【fsync()】操作调用，而是有操作系统自动调度刷新磁盘，性能是最好的 Appendfsync no // 表示Redis每次写操作后都会手动调用【fsync()】，将数据强制写入操盘，性能是最慢的，但是持久化效果最好 Appendfsync always // 表示每秒同步一次，即每秒强制写一次，在性能和持久化方面做了很好的这种 Appendfsync Everysec
一般Redis中数据是有限的，很多数据都会自动过期，或者被用户删除，又或者被Redis的清除算法清理，从而淘汰。
Redis中数据会不断淘汰旧的，只有一部分常用的数据会存放在内存中。
所以可能之前很多被清理的数据，都保留在AOF日志中，因为AOF日志只有一个，会不断的膨胀变大，
所以AOF会每隔一段时间，进行一次【rewrite】操作。举个例子：
比如AOF日志中已经存放了100w的数据指令，但我们的Redis中，由于过期或被用户删除，
实际上只剩下了10w数据，此时基于这10w数据我们重新构建一个新的日志并覆盖之前的AOF日志，
从而确保日志文件不会过大，并与内存中尽量一致。
/** 比如说上一次AOF rewrite之后，是128mb，然后就会接着128mb继续写AOF的日志， 如果发现增长的比例，超过了之前的100%，256mb，就可能会去触发一次rewrite 但是此时还要去跟min-size，64mb去比较，256mb > 64mb，才会去触发rewrite **/ auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
1》Redis-Server先fork一个子进程； 2》子进程基于当前的内存数据，构建日志，开始往新的临时AOF文件中写入日志； 3》Redis主进程，接到客服端的写操作时，继续往旧的AOF日志中追加数据，此时Redis中有两个日志文件，一个是子进程创建的临时日志，一个是主进程的AOF日志 4》子进程写完创建完临时AOF日志后，将Redis主进程新追加的日志写入到临时日志中； 5》用临时日志覆盖主进程的旧AOF日志
如果一个业务的并发上万，那么AOF日志系统可以说是非常庞大的，所以恢复重建功能就会很漫长
Redis中的AOF和RDB如何选择呢：
1》不要仅仅使用RDB，那样会导致丢失数据； 2》也不要仅仅使用AOF，如果AOF中出现指令bug或文件损坏，那么可能会造成数据恢复失败； 3》综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 因为RDB更具有健壮性，用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复
原文：https://www.cnblogs.com/boluopabo/p/13061467.html