一、为什么要持久化？
Redis持久化，就是将内存中的数据存储到硬盘中。

1，为了防止系统故障导致数据丢失；
2，为了重用数据；比如，一些大计算的结果，存储到硬盘中，避免重复计算，方便使用。

二、持久化的方式
Redis提供了两种不同的方式将内存中的数据存储到硬盘中。
1，快照（snapshotting）：将某一时刻的所有数据存储到硬盘；
2，追加文件（append-only file  AOF）：在执行写命令时，将被执行的写命令复制到硬盘中。

这2种方式，可以同时使用，也可以单独使用，甚至可以都不使用。

快照持久化配置参数

save 60 1000
stop-writes-on-bgsave-error no
rdbcompression yes
dbfilename dump.rdb 

dir ./

AOF持久化配置参数

appendonly no 
appendfsync everysec
auto-sof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
appendfilename appendonly.aof

dir ./  

三、快照持久化
Redis将某个时间点存储在内存中的数据保存到硬盘，即数据快照持久化。

快照可以用作数据备份；可以用作复制到其他Redis服务器作为副本；可以用作重启服务器的启动数据。

如果Redis、系统、硬件任何一个出现故障，那么Redis将丢失最近一次快照之后的数据。

3.1，配置参数说明

save 90 1 #90秒内，至少有1个key被写入时就触发 
save 30 10 #30秒内，至少有10个key被写入时就触发 
save 60 1000 #60秒后保存，至少有1000个key被写入时就触发
stop-writes-on-bgsave-error yes #最近一次save操作失败则停止写操作 
rdbcompression yes #启用压缩 
rdbchecksum yes #启用CRC64校验码，当然这个会影响一部份性能 
dbfilename dump.rdb #指定存储数据的文件名 

dir ./  #指定工作目录，rdb文件和aof文件都会存放在这个目录中，默认为当前目录

3.2，创建快照的方式
1，客户端通过执行BGSAVE命令。当发起BGSAVE命令时，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。

2，客户端通过执行SAVE命令。与BGSAVE的区别是，SAVE命令发起之后，不创建子进程，Redis在创建完成快照之前不响应命令请求。一般在内存不足够创建子进程的情况下使用。

3，通过save配置。比如 save 60 1000 ，那么从redis最近一次创建快照之后开始计算，当 60s 内完成 1000 次写入 的时候，Redis自动触发BGSAVE。如果用户设置了多个save配置，那么当任何一个条件被满足时，都会触发BGSAVE。

4，Redis接收到SHUTDOWN命令、或者标准的TERM命令。自动触发SAVE命令。

5，Redis服务器同步。当一个Redis服务器连接另一个Redis服务器，并向对方发送SYNC命令开始复制操作的时候，如果主服务器目前没有在执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE，那么主服务器会执行BGSAVE操作。

四、AOF持久化
AOF持久化就是将被执行的写命令写到AOF文件的末尾，以此来记录数据的变化。所以，Redis只要从头到尾重新执行一次AOF文件包含的所有命令，就可以恢复AOF文件所记录的数据集。

appendfsync everysec #每秒同步一次
auto-sof-rewrite-percentage 100  
auto-aof-rewrite-min-size 64mb #当AOF文件大于64mb，并且aof文件比上次重写之后的体积大了至少一倍，Redis执行BGREWRITEAOF命令
appendfilename appendonly.aof #持久化文件

dir ./  #指定工作目录，rdb文件和aof文件都会存放在这个目录中，默认为当前目录

4.1，appendfsync
同步频率
1）always：每个Redis写命令都要同步写入磁盘。系统发生崩溃时数据丢失减到最少。但是对硬盘大量的写入，会严重降低Redis的速度。

2）everysec：每秒执行一次同步，显示地将多个写命令同步到硬盘。Redis每秒同步一次AOF文件时的性能和不使用任何持久化特性的性能相差无几，并且可以保证即使系统崩溃，最多丢失一秒内的数据。

3）no：Redis将不对AOF文件执行任何的显示同步操作，让操作系统来决定应该何时对AOF文件进行同步。不会对Redis性能带来影响，但系统崩溃会丢失不定量的数据。一般不推荐使用。

4.2，AOF最好吗？

AOF可以将丢失数据的时间控制在1秒内，又可以在极短的时间内完成定期的持久化，我们有什么理由不使用AOF持久化呢？

1）因为AOF会不断地将被执行的命令写入AOF文件，所以随着Redis不断的运行，AOF文件体积也会不断的增长，在极端情况下，AOF文件会用完整个磁盘。

2）Redis重启之后要通过执行AOF文件来还原数据集，如果AOF文件体积非常大，那么还原操作执行的时间就会非常长。

4.3，BGREWRITEAOF
为了解决AOF文件体积增大的问题，可以使用BGREWRITEAOF命令进行重写。这个命令会通过移除AOF文件中冗余的命令来重写（rewrite）AOF文件，使AOF文件尽可能的小。

BGREWRITEAOF的工作原理和BGSAVE类似，会创建一个子进程，然后由子进程负责对AOF文件进行重写。

4.4，自动的BGREWRITEAOF

和快照持久化通过设置save选项一样，AOF持久化可以通过设置auto-sof-rewrite-percentage和auto-aof-rewrite-min-size来自动执行BGREWRITEAOF。

比如设置了auto-sof-rewrite-percentage 100和 auto-aof-rewrite-min-size 64mb ，那么当AOF文件大于64mb，并且AOF文件比上次重写之后的体积大了至少一倍，Redis自动执行BGREWRITEAOF命令。

如果AOF重写执行的过于频繁，可以考虑将auto-sof-rewrite-percentage选项的值设置为100以上。

五、总结
无论是AOF持久化还是快照持久化，将数据持久化到硬盘都是必要的，但是还要将持久化的数据进行备份，最好备份到不同地方，避免数据丢失发生事故。

随着负载量的上升，或者数据完整性越来越重要，还需要使用复制特性。

扫一扫，通过微信也能学习