Redis持久化

最新推荐文章于 2024-10-10 00:08:36 发布

WYQ525

最新推荐文章于 2024-10-10 00:08:36 发布

阅读量477

点赞数 21

文章标签： redis java 数据库

本文链接：https://blog.csdn.net/ddccaaxXasac/article/details/139410238

版权

1、什么是持久化，为什么要持久化

众所周知，redis是用于存储数据的，作为内存数据库，其数据的安全性和稳定性是尤为重要的。假设服务器发生故障，导致redis中的数据都丢失了，这会是严重的事故。因此，了解Redis持久化的原理，对于Redis保障数据的完整性是至关重要的。

2、持久化方式

目前主要有两种持久化方式，RDB和AOF

2.1、快照RDB

RDB是redis默认的持久化方式，它将 Redis 在内存中的数据写入到硬盘中，生成一个快照文件。在指定的时间间隔内将内存中的数据集快照写入磁盘( Snapshot )，它恢复时是将快照文件直接读到内存里。快照文件中保存的是二进制文件，其数据非常的紧密。并且在 Redis 重启时可以迅速地加载数据。相比于AOF，RDB文件一般会更小。

优点：快速，简单，适用于大规模的数据备份

缺点：数据可能会丢失，因为RDB是在指定的时间间隔内执行，或者是手动去触发，如果在某个时间服务器宕机，而RDB又没有达到执行的条件，这时在RDB上次执行之后，到服务器宕机之前的数据会丢失。

RDB 持久化触发有两种方式：自动和手动。

手动：手动方式通过 save 命令或 bgsave 命令进行。

自动：自动方式则是在配置文件中设置，满足条件时自动触发。

使用save命令会阻塞进程，直到RDB文件创建完毕，才会执行新的命令。而bgsave不会阻塞进程。

自动方式是指通过服务器配置文件的 save 选项，来让 Redis 每隔一段时间自动执行 bgsave ，本质上还是通过 bgsave 命令去实现。

配置文件的 save 选项允许配置多个条件，只要其中任何一个条件满足，就会触发 bgsave。

即："N 秒内数据集至少有 M 个改动" 这一条件被满足时。

举个例子:

save 900 1
save 300 10

那么只要满足以下三个条件中的任意一个，bgsave 命令就会被执行:

服务器在 900秒之内，对数据库进行了至少 1次修改。
服务器在 300秒之内，对数据库进行了至少 10次修改。

如果用户没有主动设置 save 选项，那么服务器会为 save 选项设置默认条件。

2.2、AOF

AOF是通过追加文件的方式记录历史，以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

优点：安全，详细

缺点：文件会越来越大，效率低于RDB

AOF采用文件追加的方式，文件会越来越大，为了避免这种情况的发生，为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时， Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

Redis的 AOF 重写机制指的是将 AOF 文件中的冗余命令删除，以减小 AOF 文件的大小并提高读写性能的过程。

实际上，AOF 文件重写并不需要对现有的AOF 文件进行任何读取、分析或者写入操作。

AOF重写是通过读取服务器当前的数据库状态来实现的。当AOF文件大小超过阈值时，会将原文件压缩，新的AOF文件会提取现有的数据库，将数据库解析为redis语句，并保存。

具体来说，Redis执行AOF重写可以分为以下几个步骤：

开始AOF重写过程，向客户端返回一个提示信息。
创建一个临时文件，并将当前数据库中的键值对写入到临时文件中。
在创建的临时文件中将所有的写命令都转换成Redis内部的表示格式，即使用一系列的Redis命令来表示一个操作，例如使用SET命令来表示对某个键进行赋值操作。
对临时文件进行压缩，去掉多余的空格和换行符等，减小文件体积。
将压缩后的内容写入到新的AOF文件中。
停止写入命令到旧的AOF文件，并将新的AOF文件的文件名替换为旧的AOF文件的文件名。
结束AOF重写过程，并向客户端发送完成提示信息。

2.3、混合持久化

在过去， Redis 用户通常会因为 RDB 持久化和 AOF 持久化之间不同的优缺点而陷入两难的选择当中：

RDB 持久化能够快速地储存和恢复数据，但是在服务器停机时可能会丢失大量数据。
AOF 持久化能够有效地提高数据的安全性，但是在储存和恢复数据方面却要耗费大量的时间。

为了让用户能够同时拥有上述两种持久化的优点， Redis 4.0 推出了一个“鱼和熊掌兼得”的持久化方案 —— RDB-AOF 混合持久化。

这种持久化能够通过 AOF 重写操作创建出一个同时包含 RDB 数据和 AOF 数据的 AOF 文件，其中 RDB 数据位于 AOF 文件的开头，它们储存了服务器开始执行重写操作时的数据库状态。至于那些在重写操作执行之后执行的 Redis 命令，则会继续以 AOF 格式追加到 AOF 文件的末尾，也即是 RDB 数据之后。

也就是说当开启混合持久化之后，AOF文件中的内容：前半部分是二进制的RDB内容，后面跟着AOF增加的数据，AOF位于两次RDB之间。