redis持久化

最新推荐文章于 2024-09-06 14:56:43 发布

一只叫狗的猫

最新推荐文章于 2024-09-06 14:56:43 发布

阅读量146

点赞数 1

分类专栏： # Redis

本文链接：https://blog.csdn.net/zgsxhdzxl/article/details/101194730

版权

Redis 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

RDB持久化

RDB 持久化是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化)，保存的文件后缀是 RDB；当 Redis 重新启动时，可以读取快照文件恢复数据。

手动触发

bgsave 和save都会生成rdb文件，save会阻塞redis服务器进程，直到rdb文件创建完毕，在此期间，服务器不能处理任何请求，所以这个save基本不会使用。bgsave会创建一个子进程，由子进程创建rdb文件，主进程则继续处理请求。

自动触发
修改redis.conf配置文件中的save m n，指定m秒内修改n次就会触发bgsave。实现原理是通过serverCron函数，dirty计数器和lasesave时间戳实现的。
serverCron是redis服务器周期性操作函数，默认每隔100ms执行一次，其中一个工作就是监视save m n条件是否满足，满足就bgsave。
dirty记录上一次执行bgsave\save后，服务器进行了多少次修改，持久化执行完成后，会将dirty重新置为0。

save 900 1
save 300 10
save 60 10000

其它配置

#当 bgsave 出现错误时，Redis 是否停止执行写命令；设置为 yes，则当硬盘出现问题时，可以及时发现，避免数据的大量丢失。
设置为 no，则 Redis 无视 bgsave 的错误继续执行写命令，当对 Redis 服务器的系统(尤其是硬盘)使用了监控时，该选项考虑设置为 no。
stop-writes-on-bgsave-error yes

#是否开启 RDB 文件的校验，在写入文件和读取文件时都起作用；关闭 checksum 在写入文件和启动文件时大约能带来 10% 的性能提升，但是数据损坏时无法发现
rdbchecksum yes

#是否开启 RDB 文件压缩。
rdbcompression yes

#文件路径
dir ./

# 文件名
dbfilename dump6379.rdb

#关闭rdb。将save后的值置空即可
save ""

执行流程：

Redis 父进程首先判断：当前是否在执行 save 或 bgsave/bgrewriteaof的子进程，如果在执行则 bgsave 命令直接返回。
bgsave/bgrewriteaof 的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
父进程执行 fork 操作创建子进程，这个过程中父进程是阻塞的，Redis 不能执行来自客户端的任何命令。
父进程 fork 后，bgsave 命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令。
子进程创建 RDB 文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换。
子进程发送信号给父进程表示完成，父进程更新统计信息

AOF

AOF是将redis执行的每次命令记录到单独的日志文件中，当redis重启时执行AOF文件中的命令来恢复数据。AOF实时性更好。并且AOF优先级较高，如果同时开启AOF和ROB，则会执行AOF。

开启AOF

aof默认关闭，ROB默认开启，配置文件中配置 appendonly yes ，会开启AOF。

重写触发

手动触发

直接调用bgrewriteaof 命令，该命令与bgsave类似，都是fork子进程工作，并且只有创建fork时阻塞

自动触发

   根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数，以及 aof_current_size 和 aof_base_size 状态确定触发时机。可以通过config get auto-aof-rewrite-min-size 查看具体的值。
   auto-aof-rewrite-min-size：执行 AOF 重写时，文件的最小体积，默认值为 64MB。
   auto-aof-rewrite-percentage：执行 AOF 重写时，当前 AOF 大小(即 aof_current_size)和上一次重写时 AOF 大小(aof_base_size)的比值。
   只有当 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 两个参数同时满足时，才会自动触发 AOF 重写，即 bgrewriteaof 操作。

其它配置

* appendonly no：是否开启 AOF。
* appendfilename "appendonly.aof"：AOF 文件名。
* dir ./：RDB 文件和 AOF 文件所在目录。
* appendfsync everysec：fsync 持久化策略。
* no-appendfsync-on-rewrite no：AOF 重写期间是否禁止 fsync；如果开启该选项，可以减轻文件重写时 CPU 和硬盘的负载（尤其是硬盘），但是可能会丢失 AOF 重写期间的数据；需要在负载和安全性之间进行平衡。
* auto-aof-rewrite-percentage 100：文件重写触发条件之一。
* auto-aof-rewrite-min-size 64mb：文件重写触发提交之一。
* aof-load-truncated yes：如果 AOF 文件结尾损坏，Redis 启动时是否仍载入 AOF 文件。

AOF 缓存区的同步文件策略由参数 appendfsync 控制，各个值的含义如下：
   1. always：命令写入 aof_buf 后立即调用系统 fsync 操作同步到 AOF 文件，fsync 完成后线程返回。这种情况下，每次有写命令都要同步到 AOF 文件，硬盘 IO 成为性能瓶颈，Redis 只能支持大约几百 TPS 写入，严重降低了 Redis 的性能。
   2. no：命令写入 aof_buf 后调用系统 write 操作，不对 AOF 文件做 fsync 同步；同步由操作系统负责，通常同步周期为 30 秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
   3. everysec：命令写入 aof_buf 后调用系统 write 操作，write 完成后线程返回；fsync 同步文件操作由专门的线程每秒调用一次。everysec 是前述两种策略的折中，是性能和数据安全性的平衡，因此是 Redis 的默认配置，也是我们推荐的配置。

执行流程

命令追加：

将redis命令追加到缓存区aof_buf。

文件写入（write）和文件同步(sync)

根据不同的策略将aof_buf 同步到硬盘

文件重写：定期重写aof,达到压缩的目的。

由于文件越来越大，所以需要重写aof文件，。AOF重写是将redis进程内的数据转化为写命令，同步到新的aof文件，不会对旧的aof文件进行任何读取、写入操作。
重写能够压缩aof文件，主要在于：过期的数据不会写入文件、无效的命令不会写入文件（例如重复设值）、多条命令合并。

RDB 和 AOF：

RDB 持久化

优点：RDB 文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比 AOF 快很多。当然，与 AOF 相比，RDB 最重要的优点之一是对性能的影响相对较小。

缺点：RDB 文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此 AOF 持久化成为主流。

此外，RDB 文件需要满足特定格式，兼容性差（如老版本的 Redis 不兼容新版本的 RDB 文件）。

AOF 持久化

与 RDB 持久化相对应，AOF 的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。

持久化策略选择

RDB做镜像全量持久化，AOF做增量持久化。因为RDB会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。在redis实例重启时，会使用RDB持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。

在多数情况下，我们都会配置主从环境，slave 的存在既可以实现数据的热备，也可以进行读写分离分担 Redis 读请求，以及在 master 宕掉后继续提供服务。
master：完全关闭持久化（包括 RDB 和 AOF），这样可以让 master 的性能达到最好。
slave：关闭 RDB，开启 AOF（如果对数据安全要求不高，开启 RDB 关闭 AOF 也可以），并定时对持久化文件进行备份（如备份到其他文件夹，并标记好备份的时间）。然后关闭 AOF 的自动重写，然后添加定时任务，在每天 Redis 闲时（如凌晨 12 点）调用 bgrewriteaof。