Redis持久化存储

Redis持久化

Redis是一个内存数据库，当redis服务器重启，获取电脑重启，数据会丢失，我们可以将redis内存中的数据持久化保存到硬盘的文件中。目前Redis支持的存储机制有RDB和AOF。

RDB机制

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB的过程分为手动触发和自动触发。

触发机制：

1.通过save与bgsave命令手动触发

• save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间的阻塞，线上环境不建议使用。
• bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短（微秒级别）。

2.通过配置文件自动触发
redis的配置文件redis.windwos.conf中有一下默认内容：

#900秒内，至少有一个key进行了修改，就进行持久化操作
save 900 1
#300秒内，至少有10个key进行了修改，就进行持久化操作
save 300 10
#60秒内，至少有1000个key进行了修改，就进行持久化操作
save 60 10000

流程说明：
1.父进程执行fork操作创建子进程
2.子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原来文件进行原子替换。
3.进程发送信号给父进程表示完成，父进程更新统计信息。

整个过程主进程不进行任何io操作，保证了性能，如果进行大规模数据恢复，RDB和AOP都可以进行数据恢复，RDB数据恢复完整性不敏感，RDB更加高效，缺点时最后一次持久化后的数据可能丢失，默认使用的就是RDB，一般情况不需要修改这个配置。

RDB文件处理：

RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定，默认为一个dump.rdb文件(在生产环境中最好对dump.rdb文件进行备份)。可以通过执行config set dir {newDir}和config set dbfilename {newFileName}运行期动态执行，当下次运行时会保存到新目录。

如果redis加载的RDB文件损坏时拒绝启动，可以使用Redis提供的redis-check-dump工具检测RDB文件并获得对应的错误报告。

RDB优点：

• RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适合备份：父进程正常处理用户请求，fork分支一个子进程进行备份。
• 适合大规模的数据恢复，如果服务器宕机了，不要删除rdb文件，重启自然在目录下，自动会读取，并且数据恢复速度远大于AOF方式。

RDB缺点：

• RDB并不能做到实时持久化，存储需要一定的时间间隔，可以自行修改设置。如果redis意外宕机，最后一次的修改数据会丢失。
• fork进程的时候，会占用一定的内存空间。
• RDB使用特定的二进制格式保存，可能存在新老版本不兼容问题。

AOF机制

AOF（append only file）持久化： 以独立日志的方式记录每次执行的命令（除读操作外），重启时重新执行AOF文件中的命令来恢复文件。（aof默认是文件无限追加，大小会不断扩张，如果是文件过大就需要写很久）

开启AOF需要我们设置配置：appendonly yes，默认不打开。文件名通过appendfilename配置设置，默认文件名为appendonly.aof。

执行流程：

• 命令写入（append）：所有命令会追加到aof_buf（缓冲区）中。
• 文件同步（sync）：AOF缓冲区根据对应的策略向硬盘做同步操作。
• 文件重写（rewrite）：随着文件越来越大，需要定期对AOF文件进行重写，达到压缩目的。
• 重启加载（load）：重启时，可以加载AOF文件进行数据恢复

AOF文件损坏：

加载损坏的AOF文件时会拒绝启动，并打印日志。我们可以先备份文件，后采用redis-check-aof --fix命令修复，修复后使用diff -u对比数据的差异，找出丢失的数据，有些可以进行人工修复。

AOF可能会出现结尾保存不完整的情况，比如机器断电导致结尾命令没有写全。Redis提供了aof-load-truncated配置来兼容这种情况，默认开启。这样在加载出问题时会继续启动，并打印警告日志。