Redis持久化

目录

引言

一 两种持久化方式

二 Redis持久化-RDB方式

三 Redis持久化-AOF方式

总结

引言

所谓持久化就是将Redis中的数据从内存保存到磁盘。

持久化的功能：Redis是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘；当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。

一 两种持久化方式

Redis持久化分为RDB持久化和AOF持久化：前者将当前数据保存到硬盘(原理是将Redis在内存中的数据库记录定时dump到磁盘上的RDB持久化)，后者则是将每次执行的写命令保存到硬盘(原理是将Redis的操作日志以追加的方式写入文件，类似于MySQL的binlog)：由于AOF持久化的实时性更好，即当前进程意外退出时丢失的数据更少，因此AOF时目前主流的持久化方式，不过RDB仍然有其用武之地。

RDB：将数据保存到磁盘上面(原理：定期的将Redis的数据dump到磁盘上面) 默认的持久化方式

AOF：将每次执行的写命令保存到硬盘(原理是将Redis的操作日志以追加的方式写入文件，类似于MySQL的binlog) ，AOF是主流的持久化方式，当数据丢失时，把日志记录的命令再执行一遍就好了。

二 Redis持久化-RDB方式

RDB的特点：在指定的时间间隔内，执行指定次数的写操作，达到上述条件则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件，Redis重启会通过加载dump.rdb文件恢复数据。

触发快照的方式：

1.执行shutdown命令，会触发快照

2.执行flushall命令，也会触发快照

3.手动执行save命令，也会触发快照

上述命令会更新dump.rdb

以save命令为例！

在执行完save命令后，dump.rdb文件就会更新！

4.在指定时间内，执行指定次数的写操作

这句话的意思就是说，当满足在指定的一段时间内，达到了指定的写操作次数，便会触发快照，对dump.rdb进行更新！这些东西都写在了配置文件里，默认情况下是这样的：

60s内 保证写10000次 就会触发一次快照！

300s内 保证写100次 也会触发一次快照！

3600s内 保证写1次 也会触发一次快照！

save time times 时间time与次数times都要满足，不然就触发不了快照。

测试：save 30 2， 要保证在30s以内执行2次写操作；保证时间30s要到达，写次数2次也要满足。

RDB方式的优点：

1.适合大规模的数据恢复，与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些

2.如果业务对数据完整性和一致性要求不高，RDB是很好的选择

RDB方式的缺点：

1.数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了

2.备份时占用内存，因为Redis在备份时会独立创建一个fork子进程，将数据写入到一个临时文件(此时内存中的数据是原来的两倍)，最后再将临时文件替换之前的备份文件

所以Redis的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的

三 Redis持久化-AOF方式

AOF即Append Only File

如前面介绍的，AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序将指令都执行一遍，就这么简单。

默认时没有开启AOF持久化方式的，通过设置配置文件可以打开，我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作(如SET等)， redis就会追加到AOF文件的末尾。默认的AOF持久化策略是每秒钟fsync一次(fsync是指把缓存中的写指令记录到磁盘中)，因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

可以自行查看配置文件了解：

上述的意思就是：

一直同步 每秒同步 从不同步

默认情况下，是每秒同步一次。最多会丢失1s的数据

Redis持久化-AOF重写(rewrite)

因为AOF的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加。AOF文件的体积也会变得越来越大。举个例子，如果你对一个计数器调用了100次INCR，那么仅仅是为了保存这个计数器的当前值，AOF文件就需要使用100条记录(entry)。然而在实际上，只需要使用一条set命令已经足以保存计数器的当前值了，其余99条记录实际上都是多余的。

为了处理这种情况，Redis支持一种有趣的特性：可以在不打断服务器客户端的情况下，对AOF文件进行重建(rebuild)。执行BGREWRITEAOF命令，Redis将生成一个新的AOF文件，这个文件包含重建当前数据集所需的最少命令。Redis2.2需要自己手动执行BGREWRITEAOF命令：Redis2.4则可以自动触发AOF重写，具体信息请查看配置文件。

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

auto-aof-rewrite-percentage 100   增加为上一次的100% 即一倍

auto-aof-rewrite-min-size 64mb     也要达到64mb

上述两个条件需要同时达到才会触发！

set k1 1
incr k1
//... 执行10000次
incr k1
get k1 # 10000

#等价于
set k1 10000
#这就是所谓的重写

下一次的写操作之后文件大小的增幅要达到100%，并且文件大小要达到64M，才能触发重写。

AOF方式的优点：

1.使用AOF会让你的Redis更加耐久：你可以使用不同的fsync策略：无fsync，每秒fsync，每次写的时候fsync，使用默认的每秒fsync策略，Redis的性能依然很好(fsync是由后台线程进行处理的，主线程会尽力处理客户端请求)，一旦出现故障，你最多丢失一秒的数据。

2.AOF文件是一个只进行追加的日志文件，所以不需要写入seek，即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令，你也可以使用redis-check-aof工具修复这些问题。

AOF方式的缺点：

对于大量数据恢复的时候，执行的命令的时间比较长。

总结

1.两种持久化的方式一般都是同时开启的，既能保证数据的完整性和一致性，也能保证大量数据恢复的时候时间比较快。

2.如果只开启AOF持久化的方式，并且被损坏了，此时不能启动成功的。

3.如果aof文件损坏了，是可以进行手动修复的。sudo redis-check-aof --fix appendonly.aof

4.如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式(只做缓存