Redis持久化

目录

持久化

RDB快照

 AOF(append-only-file)

  Aof重写

​编辑 RDB和AOF对比

Redis 4.0混合持久化

---

持久化

RDB快照

在默认情况下，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。

在redis.conf中默认有下面三条保存策略：

这个命令的意思是，在"N秒内数据集至少有M个键发生了变更"就会触发保存。

下面三个策略，满足任意一个都会触发。

也可以禁用保存策略使用：save ""

保存下来的数据会生成dump文件。有两个配置可以配置dump的文件名和目录。

默认的文件名是 dbfilename配置为 dump.rdb,存放的目录在安装目录下面：

 

会周期性检查save策略向这个文件中写数据。

还可以手动执行命令来保存快照，在客户端执行save/bgsave可以生成dump文件，每次执行命令都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有的rdb快照文件。

save/bgsave命令的同步在于，save是同步dump的，bgsave是异步的，save在dump数据的时候使用的是处理读写命令的那个线程来做的，会阻塞正常的读写请求，着对于性能来说很不友好，但是bgsave命令来说在生成快照的同时也可以正常处理命令。它借助一个叫写时复制（COW，Copy on Write）机制,bgsave子进程是由主线程fork生成的，可以共享主线程的所有内存数据，bgsave子进程运行之后，开始读取主线程的内存数据，并把它们写入RDB文件，此时，如果主线程对这些数据也是读操作，那么，主线程和bgsave子进程互不影响，但是，如果主线程要修改一块数据，那么，这块数据会被复制一份，生成该数据的副本。然后bgsave子进程会把这个副本数据写入rdb文件中，而这个过程中，主线程仍然可以直接修改原来的数据。

 AOF(append-only-file)

RDB因为有保存周期，如果redis宕机，可能丢失较多的数据，还有一个持久化的方式就是AOF，将修改的每一条指令记录到文件中appendonly.aof(先写入os cache,每隔一段时间fsync到磁盘)

在redis.conf配置文件中有如下的相关的如下配置：

appendonly no  #是否开启 Aof持久化，默认没有开启

appendfilename "appendonly.aof" #持久化的文件名

appendfsync always #追加策略  每条修改命令都追加到文件中
appendfsync everysec #追加策略 每秒追加一次，如果redis宕机 也只丢失1s的数据
appendfsync no  #不主动刷新到文件中去，让操作系统自己决定，什么时候空闲的时候刷新到文件中

 一般追加的策略是用appendfsync everysec,不用每条修改命令都追加上去。

打开AOF之后，也会在 dir目录下面生成那个appendonly.aof文件。

重启之后我在客户端执行了两个命令：

keys *

set now time

看下aof文件里面生成了啥：

 *2  表示下面的命令有两个参数

  $6 表示下面的这个字符串有6个字符  就是select , 在命令行对应的 keys

  $1 表示下面的这个字符有1个字符  就是 0.

  同理 set now time 变成的记录是下面的 *3 .............

  Aof重写

如果每执行一条命令，都写进aof文件里，可能aof文件中存在很多冗余的命令，比如：

 在aof文件中就写入了6条inc命令：

其实每条命令都写入显得冗余，只会让aof文件变得很大。上面的6次incr命令可以合成一个就是：

set inc 6 就可以了。

对于冗余命令的处理，redis中有aof文件重写的功能。

 

auto-aof-rewrite-min-size 64mb #aof至少要达到64MB才会自动重写，文件太小的话，恢复数据也很快，也不必要重写。

auto-aof-rewrite-percentage 100  # aof文件自上次重写后文件大小增长了100%后会再次重写。

我们这里可以通过命令行执行：bgrewriteaof来重写aof文件。aof重写会fork一个子进程去做和bgsave命令类似，不会对redis正常处理命令有多大影响。

 重写之后，6次的incr命令变成了一条 set inc 6.

 RDB和AOF对比

 生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件，优先选择aof文件，因为aof文件相对安全一点。

Redis 4.0混合持久化

 重启redis时，我们很少使用RDB来回复内存状态，因为会丢失大量的数据，通过使用aof日志重放来恢复。但是重放aof日志性能比rdb慢很多，在redis大量实例情况下启动花费很长的时间。Redis4.0为了解决这个问题引入了-混合持久化。

通过如下配置开启混合持久化：

配置成 yes即可。想要其生效必须开启aof。

 开启了混合持久之后，在aof重写，或者redis关闭的时候，不再单纯的将内存中的数据转成resp命令写入aof文gou件，而是将重写这一时刻之前的内存做RDB处理，并且将RDB快照和增量的aof修改内存数据的命令存在一起，都写入新的aof文件，新的aof文件一开始不叫appendonly.aof，等重写完新的aof文件才会进行改名，覆盖原来的aof文件，完成新旧两个aof文件的替换。

于是在redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志，就可以完全替代之前的AOF全量文件重放，因此重启效率大幅得到提升。

混合持久化AOF文件结构如下：

 我们具体看下：

上面配置改为yes之后重启redis服务。

假设现在aof文件中的内容如下：

触发aof重写。

 

 aof文件的内容已经变了，变成我们看不懂的二进制数据了。

 如果继续处理命令的话，则还是会向aof文件中追加字符串。

 Redis数据备份策略：

1.写crontab定时调度脚本，每小时都copy一份rdb或者aof的备份到一个目录中去，仅仅保留最近48小时候的备份。

2.每天都保留一份当日的数据备份到一个目录中去，可以保留最近一个月的备份。

3.每次copy备份的时候，都把太旧的备份都删了。

4.每天晚上将当前机器上的备份复制一份到其它机器上，以防止机器损坏。

对于数据恢复，只要把aof文件或者rdb文件放到redis的dir配置的目录下重启redis就可以了。