redis 持久化

Posted 2022-04-21 fanggege

redis 是基于内存运行的数据库，所有数据加载在内存中进行读写，所以数据库重启以后不做持久化策略前提下数据会全部消失。

redis必须使用数据持久化吗？如果我们的Redis服务器只作为缓存使用，Redis中存储的所有数据都是从其他地方同步过来的备份，那么就没必要开启数据持久化的选项。

Redis提供了将数据定期自动持久化至硬盘的能力，包括RDB和AOF两种方案，两种方案分别有其长处和短板，可以配合起来同时运行，确保数据的稳定性。

RDB持久化方式

Redis会定期保存数据快照至一个rbd文件中，并在启动时自动加载rdb文件，恢复之前保存的数据。

触发机制

手动触发：

save 和  bgsave命令

save　　操作在Redis主线程中工作，因此会阻塞其他请求操作，应该避免使用。

bgSave　是调用Fork,产生子进程，父进程继续处理请求。子进程将数据写入临时文件，并在写完后，替换原有的.rdb文件。Fork发生时，父子进程内存共享，所以为了不影响子进程做数据快照，在这期间修改的数据，将会被复制一份，而不进共享内存。所以说，RDB所持久化的数据，是Fork发生时的数据。在这样的条件下进行持久化数据，如果因为某些情况宕机，则会丢失一段时间的数据。如果你的实际情况对数据丢失没那么敏感，丢失的也可以从传统数据库中获取或者说丢失部分也无所谓，那么你可以选择RDB持久化方式。

 

自动触发：

配置文件中配置如下：　　　　　　　　#注释3个save 即表示关闭rdb持久化策略

save 900 1
save 300 10
save 60 100　　　　　　　　　　　　 　　 #每60秒检查一次数据变更情况，如果发生了100次或以上的数据变更，则进行RDB快照保存。Redis默认开启RDB快照。

stop-writes-on-bgsave-error yes　　　#在开启RDB且最近一次bgsave执行失败的情况下，如果该参数为yes，则Redis会阻止客户端的写入，直到bgsave执行成功。

rdbcompression yes　　　　　　　　　　　#使用LZF算法压缩字符对象。

rdbchecksum yes　　　　　　　　　　　　 #从RDB V5开始，在保存RDB文件时，会在文件末尾添加CRC64校验和，这样，能较容易的判断文件是否被损坏。但同时，对于带有校验和的RDB文件的保存和加                                                                           载，会有10%的性能损耗。

dbfilename dump.rdb　　　　　　　　    #RDB文件名
dir ./　　　　　　　　　　　　　　　　　　#RDB文件保存的目录

 

AOF 持久化方式

采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。AOF默认是关闭的，如要开启，进行如下配置：appendonly yes

AOF的工作流程：

1. 所有的写入命令追加到 aof_buf缓冲区中。

2. AOF会根据对应的策略向磁盘做同步操作。刷盘策略由appendfsync参数决定。

3. 定期对AOF文件进行重写。重写策略由auto-aof-rewrite-percentage，auto-aof-rewrite-min-size两个参数决定。

配置解析：

appendonly 　　　　yes　　　　　　　　　　　　#yes 表示开启，默认为No
appendfilename   "appendonly.aof"　　　　 #记录写操作的日志文件名称
appendfsync 　　  everysec　　　　　　　　　#同步数据的策略，everysec 每秒，always 有写就同步，实时的，no 大概30s一次。
no-appendfsync-on-rewrite   no　　　　　　#
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size   64mb
aof-load-truncated 　　　　   yes

AOF 重写机制：

随着AOF不断地记录写操作日志，因为所有的操作都会记录，所以必定会出现一些无用的日志。大量无用的日志会让AOF文件过大，也会让数据恢复的时间过长。不过Redis提供了AOF rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。

重写条件：

1. 手动触发

     直接调用bgrewriteaof命令

2. 自动触发

    与auto-aof-rewrite-percentage，auto-aof-rewrite-min-size两个参数有关。

    触发条件，aof_current_size > auto-aof-rewrite-min-size 并且 (aof_current_size  - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage。

    其中，aof_current_size是当前AOF文件大小，aof_base_size 是上一次重写后AOF文件的大小，这两部分的信息可从info Persistence处获取。

 

总结比较

RDB的优点：

对性能影响最小。如前文所述，Redis在保存RDB快照时会fork出子进程进行，几乎不影响Redis处理客户端请求的效率。每次快照会生成一个完整的数据快照文件，所以可以辅以其他手段保存多个时间点的快照（例如把每天0点的快照备份至其他存储媒介中），作为非常可靠的灾难恢复手段。使用RDB文件进行数据恢复比使用AOF要快很多。

RDB的缺点：

快照是定期生成的，所以在Redis crash时或多或少会丢失一部分数据。如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力。

 

AOF的优点：

最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据。AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。

AOF的缺点：

AOF文件通常比RDB文件更大性能消耗比RDB高数据恢复速度比RDB慢

最后：

不过大多数应用场景下，建议至少开启RDB方式的数据持久化。Redis 对于数据备份是非常友好的， 因为你可以在服务器运行的时候对 RDB 文件进行复制： RDB 文件一旦被创建， 就不会进行任何修改。 当服务器要创建一个新的 RDB 文件时， 它先将文件的内容保存在一个临时文件里面， 当临时文件写入完毕时， 程序才使用 rename(2) 原子地用临时文件替换原来的 RDB 文件。

 

参考：https://baijiahao.baidu.com/s?id=1611955931705092609&wfr=spider&for=pc

https://www.cnblogs.com/tdws/p/5754706.html

 

https://www.cnblogs.com/ivictor/p/9749465.html