目前Redis持久化的方式有两种： RDB 和 AOF
首先，我们应该明确持久化的数据有什么用？答案是用于重启后的数据恢复。
Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。
1.1 RDB
RDB就是Snapshot快照存储，是默认的持久化方式。可理解为半持久化模式，即按照一定的策略周期性的将数据保存到磁盘。对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。下面是默认的快照设置：
save 900 1 #当有一条Keys数据被改变时，900秒刷新到Disk一次
save 300 10 #当有10条Keys数据被改变时，300秒刷新到Disk一次
save 60 10000 #当有10000条Keys数据被改变时，60秒刷新到Disk一次Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的。当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。
同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。
- 第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。
- 第二次以及以后的同步实现是：Master将变量的快照直接实时依次发送给各个Slave。
但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。Redis的主从复制是建立在内存快照的持久化基础上的，只要有Slave就一定会有内存快照发生。
优点：
- 非常适合备份
- 非常适用于灾难恢复
- 存储性能高：存储数据时，父进程fork出一个子进程，父进程无需执行任何磁盘IO操作
不足：
- 一旦数据库出现问题，那么dump.rdb文件中保存的数据并不是全新的。从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。
- 当备份的数据集比较大时，可能会非常耗时，造成服务器停止处理客户端请求；
RDB备份方案
- 写crontab定时调度脚本去做数据备份
- 每一个小时都copy一份数据到指定目录，仅仅保留最近48小时的备份
- 每天都copy一份当日的数据到指定目录，这个目录记录一个月内的数据
- 每次copy数据的时候，都把太久的数据删除
- 每天晚上把当前的所有数据都copy一份到远程服务，当然可以加密。
每小时copy 一次备份，删除48小时之前的数据的脚本如下：
crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
(这条命令会自动保存在/var/spool/cron/username username表示用户名，
如果你是用root登陆操作这条命令的，那username则会是root)redis_rdb_copy_hourly.sh 文件内容如下
#!/bin/sh
cur_date = `date + %Y%m%d%H`（注意：这个不是单引号，而是 1前面那个键的点号`）
# 先删除当前已经过期的文件
rm -rf /usr/local/redis/snapshotting/hour/$cur_date
mkdir /usr/local/redis/snapshotting/hour/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/hour/$cur_date
del_date = 'date -d -48hour + %Y%m%d%H'
rm -rf /usr/local/redis/snapshotting/hour/$del_date
1.2 AOF
AOF(Append-Only File)比RDB方式有更好的持久化性。由于在使用AOF持久化方式时，Redis会将每一个收到的写命令都通过Write函数追加到文件中（默认appendonly.aof），类似于MySQL的binlog。当Redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
对应的设置参数为：
appendonly yes #启用AOF持久化方式
appendfilename appendonly.aof #AOF文件的名称，默认为appendonly.aof
# appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
# appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。问题：AOF的完全持久化方式同时也带来了另一个问题，持久化文件会变得越来越大。
比如我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。
重写机制
随着命令不断从AOF缓存中写入到AOF文件中，AOF文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制来压缩AOF文件。
AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。
AOF重写并不需要对原有AOF文件进行任何的读取，写入，分析等操作，这个功能是通过读取服务器当前的数据库状态来实现的。
例如：读取了key为list在数据库中的当前值为["C", "D", "E", "F", "G"]，然后用一条
RPUSH list "C" "D" "E" "F" "G"命令存储在AOF重写文件中，这样就能代替该key之前所有的写入命令；
比如说：
- 同一个key的多次写入命令
- 已删除、已过期的key的写命令
AOF重写的触发机制也分为手动触发和自动触发两种方式。
手动触发
执行bgrewriteaof命令直接触发AOF重写
自动触发
在redis.config配置文件中有两个配置项
no-appendfsync-on-rewrite yes #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。rewrite过程：
- 父进程fork一个子进程，并创建一个新的aof文件
- 子进程把内存中的数据往新的aof文件中写入数据
- 新进入的数据也会往旧的aof文件中写入，然后新的数据从内存中写入新的aof
- 删除旧的aof文件
Redis重启时加载持久化文件的顺序
- Redis重启的时候优先加载AOF文件，如果AOF文件不存在再去加载RDB文件。
- 如果AOF文件和RDB文件都不存在，那么直接启动。
- 不论加载AOF文件还是RDB文件，只要发生错误都会打印错误信息，并且启动失败。
如何选择？
- 通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
- 如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。
- 很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。
- 因此，我们希望可以在未来（长远计划）统一AOF和RDB成一种持久化模式。
参考：https://www.cnblogs.com/linguoguo/p/5430468.html、https://blog.csdn.net/simba_1986/article/details/77512917、https://www.cnblogs.com/drq1/p/9193982.html
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
