redis持久化机制

redis持久化机制

redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据也会丢失，所以redis提供了持久化功能：rdb、aof

RDB(Redis DataBase)

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化的数据可能会丢失

fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，并作为原进程的子进程；在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了写时复制技术：一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程

redis配置文件中rdb的一些相关配置

dbfilename

# rdb备份文件名称,默认为dump.rdb,eg:
dbfilename dump.rdb

dir

# rdb文件的保存路径,默认为Redis启动时命令行所在的目录下,eg:
dir ./

save

# rdb机制触发规则,eg:

# 3600s内1个key发生变化则触发rdb机制 
save 3600 1
# 300s内100个key发生变化则触发rdb机制 
save 300 100
# 60s内10000个key发生变化则触发rdb机制 
save 60 10000

stop-writes-on-bgsave-error

# 当Redis无法写入磁盘,直接关掉Redis的写操作,推荐yes,eg:
stop-writes-on-bgsave-error yes

rdbcompression

# 对于存储到磁盘中的快照,可以设置是否进行压缩存储;如果是的话,redis会采用LZF算法进行压缩;如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能;推荐yes,eg:
rdbcompression yes

rdbchecksum

# 在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能,推荐yes,eg:
rdbchecksum yes

redis默认的持久化机制就是RDB，一般情况下不需要修改这个配置，RDB保存的文件是dump.rdb，默认保存在bin目录下

rdb触发机制

• 满足配置文件save条件的情况下，会自动触发RDB规则
• 执行flushall命令，也会触发RDB规则
• 退出redis，也会产生dump.rdb文件

恢复备份数据，只需要将dump.rdb文件放在redis启动目录（bin）就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据

优点

• 适合大规模的数据恢复
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
• 节省磁盘空间

缺点

• 需要一定的时间间隔进程操作，如果redis意外宕机了，这个最后一次修改的数据就没有了
• fork进程的时候，会占用一定的内存空间

AOF(Append Only File)

将我们的所有命令都记录下来，恢复的时候就把这个文件包含的命令全部再执行一遍

以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只许追加文件，不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次来完成数据的恢复工作

aof持久化流程

• 客户端的请求写命令会被append追加到AOF缓冲区内
• AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
• AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
• Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

redis配置文件中aof的一些相关配置

appendonly

# 是否开启aof,yes-开启,no-关闭;eg:
appendonly no

appendfilename

# aof备份文件名称,默认为appendonly.aof,eg:
appendfilename "appendonly.aof"

appendfsync

# aof机制触发规则,eg:

# 始终同步,每次Redis的写入都会立刻记入日志,性能较差但数据完整性比较好
appendfsync always
# 每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失(redis默认)
appendfsync everysec
# redis不主动进行同步,把同步时机交给操作系统
appendfsync no

Rewrite压缩（重写机制）

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把 rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作

相关配置

no-appendfsync-on-rewrite

# 触发重写机制重写aof文件时不写入aof文件只写入缓存,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据(降低数据安全性,提高性能)
no-appendfsync-on-rewrite yes
# 触发重写机制重写aof文件时把数据往磁盘里刷,可能会发生阻塞(数据安全,但是性能降低)
no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage

# 设置重写后的基准值为超过上次重写的指定百分比,eg:文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB
auto-aof-rewrite-percentage 100
# 设置重写的基准值,达到这个值开始重写
auto-aof-rewrite-min-size 64mb

重写流程

• bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行
• 主进程fork出子进程执行重写操作，保证主进程不会阻塞
• 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失
• 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息；主进程把aof_rewrite_buf中的数据写入到新的AOF文件
• 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写

redis默认AOF保存的文件是appendonly.aof，默认也是保存在bin目录下

redis默认是不开启AOF的，需要修改配置文件将appendonly设置为yes手动开启

AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载

优点

• 数据的完整性更好

缺点

• 相对于数据文件来说，AOF远远大于RDB
• 因为AOF需要进行写操作，运行效率低，修复的速度比RDB慢
• 存在个别bug

aof文件修复

如果appendonly.aof文件有错，redis是启动不了的，我们需要修复这个文件；redis给我们提供了一个修复工具，在redis安装目录的bin文件夹下执行命令以下命令进行修复：

redis-check-aof --fix appendonly.aof

注意：如果同时开启两种持久化方式，redis会优先载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；而且RDB的数据不实时，同时启动两者是服务器重启也只会找AOF文件