redis持久化

前言

温故而知新！学习本来就是一个不断重复记忆，不断加深理解的过程。本篇对于已经学习过的redis知识点做个记录。

两种不同的持久化方法

• 快照方式

优点：它将存在于某一时刻的所有数据都写入到硬盘里面。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器作为副本，还可以将快照留在原地以便重启服务器时使用。

缺点：由于创建快照是有时间间隔的，如果在某一次创建快照期间，系统，redis或者硬件发生崩溃，那么Redis将丢失最近一次创建快照之后写入的所有数据。

创建快照的方法：

1.客户端向Redis发送BGSAVE命令来创建一个快照，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。

2.客户端可以向Redis发送SAVE命令创建快照，但是在创建快照期间不再响应其他任何命令。一般不常用这个命令。

3.可以通过设置save配置选项，比如save 60 1000，表示从第一次创建快照之后开始算起，当60秒之内有1000次写入时，Redis就会自动触发BGSAVE命令。如果设置多个save配置，那么当任意一个save配置选项条件被满足时，Redis就会触发一次BGSAVE命令。

4.当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，SAVE命令执行完毕后关闭服务器。

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

常用配置：

//当60秒内，执行至少1000条写操作会执行BGSAVE命令
save 60 1000
//即当bgsave快照操作出错时是否停止写数据到磁盘，如果为yes这样后面写错做均会失败，为了不影响后续写操作，故需将该项值改为no 
stop-writes-on-bgsave-error no
//指定存储至本地数据库时是否压缩数据，默认是yes，redis采用LZF压缩，如果为了节省CPU时间可以关闭该选项，但会导致数据库文件变的巨大
rdbcompression yes
//设置持久化文件名
dbfilename dump.rdb

• AOF持久化

如果不能忍受快照所造成的短期数据丢失，那么可以使用AOF尽快的将数据保存到硬盘里面。AOF是将被执行的命令写入到AOF文件的末尾，因此，只要Redis从头到尾执行一遍文件所包含的所有命令，就可以恢复所有的数据。

//打开AOF
appendonly yes 
//配置保存命令的频率
appendfsync always 每个redis写命令都要写入硬盘，但会严重降低Redis速度
appendfsync everysec 每秒进行一次同步，将多个写命令写入到磁盘
appendfsync no 让操作系统决定该何时同步

如果使用appendfsync always，那么对于固态硬盘来说可能会发生写入放大问题，因为要不断对硬盘进行写入操作，所以会使Redis速度大大降低，所以建议一般使用appendfsync everysec比较好。

重写/压缩AOF文件

既然AOF速度又快，丢失文件数量也小，那么为什么不直接使用这种而不把快照方式舍去呢？那是因为AOF因为一直将写命令拼写到文件末尾，导致文件一直增大，甚至会占满整个磁盘。并且，当Redis使用AOF文件进行数据恢复的时候，由于文件太大，导致恢复时间非常长。

• 解决方式

用户可以向Redis发送BGREWRITEAOF命令，该命令会移除AOF中冗余的命令，使文件尽可能的小。同时它的机制和BGSAVE命令相似：fork()出一个子进程用来处理相关操作。

相关配置如下：

//在开启aof前提下，如果aof文件大于64mb并且比上一次增长了100%，那么会进行一次BGREWRITEAOF操作
//auto-aof-rewrite-percentage可以设置大于100，防止rewriete过于频繁，但是恢复时间会变长
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

最后尽管有这两种自动持久化方案，但是还是需要经常手动备份数据到多个地方！