【redis-2】redis持久化

最新推荐文章于 2025-06-02 23:10:13 发布

原创最新推荐文章于 2025-06-02 23:10:13 发布 · 123 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#1024程序员节

缓存专栏收录该内容

9 篇文章

订阅专栏

本文详细介绍了Redis的两种持久化方式：快照（snapshotting）和AOF（append-only file）。快照是通过配置触发或命令执行创建数据副本，而AOF记录每次写操作确保数据不丢失。AOF提供了多种同步频率，以平衡性能和安全性。自动重写机制用于压缩AOF文件，防止体积过大。合理选择和配置持久化方式对于数据安全至关重要。

redis持久化方式：快照snapshotting 和文件追加AOF(append-only file)

snapshotting：

一：配置：

save 60 1000 60s内，如果达到1000次写入，创建快照（可以开启多个save，满足任意一条件即可创建快照）

stop-writes-on-bgsave-error no 创建快照失败后是否仍然继续执行写命令

rdbcompression yes 是否对文件压缩

dbfilename dump.rdb 生成文件名为dump.rdb

二：创建快照的方法：

1、客户端向redis发送BGSAVE命令（WINDOWS平台不支持该命令），redis调用fork创建一个子进程负责将快照写入硬盘，父进程则继续处理命令请求。

2、客户端向redis发送SAVE命令，redis不会创建子进程处理，而是自己生成快照，期间不会响应其他命令，所以一般在没有足够内存去执行BGSAVE时才使用该命令。

3、配置文件中开启save（如配置中的第一条），则满足条件后redis会自动触发BGSAVE命令。

4、redis通过shutdown命令接收到关闭服务器请求时，会执行SAVE命令，阻塞所有客户端，不再接收客户端发送的任何命令，在SAVE命令执行完后关闭服务器。

5、一个redis连接另一个redis，并向对方发送SYNC命令开始一次复制操作时，如果主服务器目前没有在执行或是刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令。

三：说明：

1、如果频繁创建快照，会造成资源浪费；如果过于稀少，则有丢失大量数据的隐患。在使用配置文件时，一般会配置多个save条件。

2、SAVE和BGSAVE选择：

内存充足选BGSAVE，因为不会阻塞客户端。内存不充足选SAVE，因为BGSAVE创建子进程会占用内存，降低性能。

3、SAVE和BGSAVE具体说明：

当redis存储的数据量比较小，如几个G，使用BGSAVE快照一般没有问题，但是随着redis占用的内存越来越多，并且剩余空闲内存很少（或者redis运行在virtual machine上面），此时使用BGSAVE可能引发系统长时间停顿，或是大量使用虚拟内存，导致降低redis性能至无法使用。

为了防止redis创建子进程出现停顿，一方面可以关闭自动保存，选用手动发送BGSAVE，虽然也会造成停顿，但是我们可以控制停顿出现的时间；另一方面，使用SAVE命令，虽然会阻塞redis直到快照完成，但是不会创建子进程导致redis停顿，也不会有子进程争抢资源。

如果用户能够接受或者妥善处理快照持久化带来的数据丢失，那么快照是不错的选择。否则，应该使用AOF持久化。

AOF(append-only file):

一：配置：

appdendonly yes 是否使用AOF持久化

appendfsync everysec 每一秒同步一次（还可以配置为always—每个命令都同步一次，no—系统自己决定多久同步一次）

no-appendfsync-on-rewrite no 在对AOF压缩时，能否执行同步操作

auto-aof-rewrite-percentage 100 aof文件体积比上一次重写后的aof文件大了100%（1倍）后执行一次压缩

auto-aof-rewrite-min-size 64mb AOF文件的体积达到64MB后进行压缩

第4条和第5条要同时满足才会执行压缩。

二：appendfsync同步频率：

always: 每个命令都同步，数据丢失最少，但是严重降低redis性能。

no: 由操作系统自己决定，不解释了，这个一般不考虑。

everysec：每秒执行一次，最多丢失一秒内的数据。

三：重写/压缩AOF文件：

虽然AOF能做到基本不丢失数据，并在极短时间完成定期持久化，但是也有缺陷，就是AOF文件的体积。

随着redis不断写入操作命令到AOF文件，其体积会不断增大，到达一定程度后，还原操作的执行时间就会非常长。

解决方式：

用户可以向redis发送BGREWRITEAOF命令，该命令通过移除AOF文件中的冗余命令来生成新的AOF文件并删除原文件，使体积尽可能小。

BGREWRITEAOF原理和缺陷：

原理：类似于BGSAVE，redis创建子进程负责对AOF文件重写。

缺陷：1、创建子进程导致的性能问题和内存占用问题依然存在。2、更糟糕的是，如果不加以控制，AOF文件体积可能比快照文件的体积大好几倍，在进行重写和删除旧文件时候，也可能导致系统长时间挂起。

如果人为不好控制什么时候发送BGREWRITEAOF命令，可以在配置文件中通过配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 来自动执行该命令。

如配置中第4和第5条的配置，意思就是：在启用AOF持久化的前提下，如果AOF文件体积大于64MB，并且，该文件比上一次重写后的体积大了至少1倍（100%）的时候， redis将执行BGREWRITEAOF命令。

最后，为了数据不丢失，最好将持久化后的文件多备份，如果条件允许，最好备份在不同的服务器上。到这里，对redis的持久化作了一个较为全面的总结，以后有新的认识再深入。