Redis持久化有两种方式：快照持久化（RDB）和AOF

果肉冻憨皮

已于 2022-06-21 11:47:39 修改

阅读量451

点赞数

分类专栏： Linux 文章标签： redis 缓存数据库

于 2021-12-09 14:03:22 首次发布

本文链接：https://blog.csdn.net/weixin_44106059/article/details/121803915

版权

Linux 专栏收录该内容

17 篇文章 0 订阅

订阅专栏

RDB

Redis默认快照持久化
禁用RDB，编辑 redis.conf 把 sava " " 的注释符号去掉
修改redis.conf文件制定快照持久化（RDB）存储规则

快照出错的时候是否继续执行写命令
是否对快照文件进行压缩
RDB文件的是否效验
生成的快照的文件名
是否同步删除RDB文件
生成的RDB的文件的位置(默认当前目录下)
当不满足备份条件时，执行命令SAVA（属于阻塞命令）或BGSAVE（在后台执行保存操作）,可快照持久化生成EDB文件

触发快照持久化的情景

4.1 在redis运行过程中，我们可以向redis发送一条save命令来创建一个快照，save是一个阻塞命令，redis在接收到save命令之后，开始执行备份操作之后，在备份操作执行完毕之前，将不再处理其他请求，其他请求将被挂起，因此这个命令我们用的不多。save命令执行如下：

 127.0.0.1:6379> SAVE
    OK

4.2 在redis运行过程中，我们也可以发送一条bgsave命令来创建一个快照，不同于save命令，bgsave命令会fork一个子进程，然后这个子进程负责执行将快照写入硬盘，而父进程则继续处理客户端发来的请求，这样就不会导致客户端命令阻塞了。如下：

127.0.0.1:6379> BGSAVE
Background saving started

4.3 如果我们在redis.conf中配置了如下选项：

save 900 1
save 300 10
save 60 10000

那么当条件满足时，比如900秒内有一个key被操作了，那么redis就会自动触发bgsava命令进行备份。我们可以根据实际需求在redis.conf中配置多个这种触发规则。

4.4 还有一种情况也会触发save命令，那就是我们执行shutdown命令时，当我们用shutdown命令关闭redis时，此时也会执行一个save命令进行备份操作，并在备份操作完成后将服务器关闭。

4.5 还有一种特殊情况也会触发bgsave命令，就是在主从备份的时候。当从机连接上主机后，会发送一条sync命令来开始一次复制操作，此时主机会开始一次bgsave操作，并在bgsave操作结束后向从机发送快照数据实现数据同步。

快照持久化的缺点

快照持久化有一些缺点，比如save命令会发生阻塞，bgsave虽然不会发生阻塞，但是fork一个子进程又要耗费资源，在一些极端情况下，fork子进程的时间甚至超过数据备份的时间。定期的持久化也会让我们存在数据丢失的风险，最坏的情况我们可能丢失掉最近一次备份到当下的数据，具体丢失多久的数据，要看我们项目的承受能力，我们可以根据项目的承受能力配饰save参数

案例

开启bgsave
删除rdb文件
编写测试代码

public class JedisDemo3 {

    public static void main(String[] args) {
        Redis redis = new Redis();
        redis.excute(jedis -> {
            for (int i = 0; i < 10001; i++) {
                jedis.set("k"+i,"v"+i);
            }
        });
    }
}

运行代码并验证

AOF

关闭RDB
开启AOF
AOF相关属性

AOF备份文件名
在dir修改AOF文件的位置也可以
备份规则：.appendfsync表示备份的时机，always表示每执行一个命令就备份一次，everysec表示每秒备份一次，no表示将备份时机交给操作系统。
对aof文件进行压缩时，是否执行同步操作
rewrite压缩策略

验证

生成aof文件

因为aof文件是可读的（rdb文件是二进制文件），查看文件

归纳：

1.如果redis只做缓存服务器，那么可以不使用任何持久化方式。

2.同时开启两种持久化方式，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；RDB的数据不完整时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

3.因为RDB文件只用作后备用途，建议只在slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

4.如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

5.如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。