Redis持久化

最新推荐文章于 2024-05-21 19:41:45 发布

乔一屿七

最新推荐文章于 2024-05-21 19:41:45 发布

阅读量1.1k

点赞数 22

分类专栏：数据库文章标签： redis java mybatis

本文链接：https://blog.csdn.net/m0_73173239/article/details/137089286

版权

数据库专栏收录该内容

7 篇文章 0 订阅

订阅专栏

简单介绍

Redis持久化就是将Redis中的数据写入磁盘内，用于保证数据安全，或是为了保证数据同步。

Redis持久化的方式

快照方式（RDB)
AOF(append-only file)
AOF与RDB混合

RDB持久化

RDB持久化是 Redis创建快照来获得存储在内存中，某个时间点的数据的副本。

创建快照之后，快照可以留在原地，如果发生故障，那么重启服务器的时候使用。也可以将快照机型复制到其他服务器，从而创建具有相同数据的服务器副本。这也就是Redis的主从结构（如果一个服务器出现问题，还有其他的服务器往上顶）。主从结构可以提高Redis的性能。

RDB持久化是Redis的默认持久化方式。在redis.conf文件下有默认的配置。（代码来源于JavaGuide)。

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发bgsave命令创建快照。

在Redis中，有两个命令可以创建RDB快照文件

save 同步保存，但需要注意的是，他会阻碍主线程
bgsave 会额外创建一个子线程，由子线程去进行创建快照，同步保存。不会阻碍主线程。

RDB持久化的流程

AOF持久化

AOF持久化是将修改Redis中数据的指令放入AOF缓冲区之中，然后写入AOF文件（此时在系统内核缓冲区），最后再根据fsync策略来决定何时将系统内核区的数据同步到磁盘之中。

AOF持久化的流程：

流程部分内容来自JavaGuide

文件追加 （append）: Redis将修改Redis中数据的命令放入AOF缓冲区。
文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数（系统调用），write将数据写入到了系统内核缓冲区之后直接返回了（延迟写）。注意！！！此时并没有同步到磁盘。
文件同步（fsync策略）：AOF 缓冲区根据对应的持久化方式（ fsync 策略）向硬盘做同步操作。这一步需要调用 fsync 函数（系统调用）， fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

需要解释的是 fsync策略就是AOF持久化（同步到硬盘）的方式。

fsync：fsync用于强制刷新系统内核缓冲区（同步到到磁盘），确保写磁盘操作结束才会返回。

AOF持久化的方式

在 Redis 的配置文件中存在三种不同的 AOF 持久化方式（ fsync策略），它们分别是：

appendfsync always：主线程调用 write 执行写操作后，后台线程（ aof_fsync 线程）立即会调用 fsync 函数同步 AOF 文件（刷盘），fsync 完成后线程返回，这样会严重降低 Redis 的性能（write + fsync）。
appendfsync everysec：主线程调用 write 执行写操作后立即返回，由后台线程（ aof_fsync 线程）每秒钟调用 fsync 函数（系统调用）同步一次 AOF 文件（write+fsync，fsync间隔为 1 秒）
appendfsync no：主线程调用 write 执行写操作后立即返回，让操作系统决定何时进行同步，Linux 下一般为 30 秒一次（write但不fsync，fsync 的时机由操作系统决定）。

他们之间的不同就是什么时候将AOF文件同步到磁盘。

为了兼顾性能和安全，建议使用appendfsync everysec , 就算丢失数据，也最多只是会丢失1s前的内容。收到的性能影响也比较小。

如何选择AOF和RDB?

RDB更快

使用 RDB 文件恢复数据，直接解析还原数据即可，不需要一条一条地执行命令，速度非常快。而 AOF 则需要依次执行每个写命令，速度非常慢。也就是说，与 AOF 相比，恢复大数据集的时候，RDB 速度更快。

AOF更安全

RDB 的数据安全性不如 AOF，没有办法实时或者秒级持久化数据。生成 RDB 文件的过程是比较繁重的，虽然 BGSAVE 子进程写入 RDB 文件的工作不会阻塞主线程，但会对机器的 CPU 资源和内存资源产生影响，严重的情况下甚至会直接把 Redis 服务干宕机。AOF 支持秒级数据丢失（取决 fsync 策略，如果是 everysec，最多丢失 1 秒的数据），仅仅是追加命令到 AOF 文件，操作轻量。

综上：