Redis进阶 - Redis持久化

原文首更地址,阅读效果更佳!

Redis进阶 - Redis持久化 | CoderMast编程桅杆icon-default.png?t=N5K3https://www.codermast.com/database/redis/redis-advance-persistence.html

单点Redis的问题

  • 数据丢失问题:Redis 是内存存储,服务重启可能会丢失数据。通过实现 Redis 数据持久化解决。
  • 并发能力问题:单节点 Redis 并发能力虽然不错,但是也无法满足如 618 这样的高并发场景。搭建主从集群,实现读写分离解决。
  • 故障恢复问题:如果 Redis 宕机,则服务不可用,需要一种自动的故障恢复手段。利用 Redis 哨兵,实现健康检测和自动恢复。
  • 存储能力问题:Redis 基于内存,单点能存储的数据量难以满足海量数据需求。搭建分片集群,利用插槽机制实现动态扩容。

#RDB持久化

RDB 全称为 Redis Database Backup file (Redis 数据备份文件),也被叫做 Redis 数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当 Redis 实例故障重启后,从磁盘读取快照文件,恢复数据。

快照文件称为 RDB 文件,默认是保存在当前运行目录。

  • save命令:创建 RDB 快照,由 Redis 主进程来执行,会阻塞所有命令。RDB 是需要写入磁盘中,IO 操作较慢。
  • bgsave命令:开启子进程执行 RDB ,避免主进程受到影响。

Redis 停机时会执行一次 RDB 。

默认情况下会在当前目录生成一个 dump.rdb 的文件,下一次启动 Redis 时,默认会加载这个文件,恢复 Redis 数据。

Redis 内部有触发 RDB 的机制,可以在 redis.conf 文件中找到,格式如下:

save 900 1      // 900 秒内,如果至少有 1 个 key 被修改,则执行 bgsave
save 300 10     // 300 秒内,如果至少有 10 个 key 被修改,则执行 bgsave
save 60 10000   // 60 秒内,如果至少有 10000 个 key 被修改,则执行 bgsave
save ""         // 表示禁用 RDB

rdbcompression yes  // 是否压缩,建议不开启,压缩也会消耗 CPU ,磁盘空间相对廉价
dbfilename dump.rdb // RDB 文件名称
dir ./              // 文件保存的路径目录

bgsave 开始时会 fork 主进程得到子进程,子进程共享主进程的内存数据。完成 fork 后读取内存数据并写入 RDB 文件。

fork 过程是阻塞的,此时 Redis 无法响应客户端请求。fork 的速度是非常快的,因为 fork 只复制了对应的页表,而不是复制真实的数据,类似于只复制数据的索引。

fork 采用的是 copy-on-write 技术:

  • 当主进程执行读操作时,访问共享内存
  • 当主进程执行写操作时,则会拷贝一份数据,执行写操作。

Redis进阶 - Redis持久化_第1张图片

 

极端情况

当子进程写新的 RDB 文件时,此时主进程大量修改数据,则需要对数据进行拷贝,当主进程需要对所有的数据都进行修改时,则需要两倍原来的内存,故我们在配置 Redis 服务时,不能将所有的实际内存分配给 Redis ,需要预留一部分缓冲空间。

RDB 持久化小结:

RDB 方式 bgsave 的流程:

  1. fork 主进程得到一个子进程,共享内存空间
  2. 子进程读取内存数据并写入新的 RDB 文件
  3. 用新的 RDB 文件替换旧的 RDB 文件

RDB 会在什么时候执行?save 60 1000代表什么含义?

  • 默认是在 Redis 服务停止时执行 RDB。
  • save 60 10000代表60秒内至少执行 1000 次修改则触发 RDB

RDB 的缺点?

  • RDB 执行间隔时间长,两次 RDB 之间写入数据有丢失的风险
  • fork 子进程、压缩、写出 RDB 文件都比较耗时

#AOF持久化

AOF 全称为 Append Only File(追加文件)。Redis 处理的每一个写命令都会记录在 AOF 文件,可以看做是命令日志文件。

AOF 默认是关闭的,需要修改 redis.conf 配置文件来开启 AOF

appendonly yes  // 是否开启 AOF 功能,默认是关闭的
appendfilename "appendonly.aof" // AOF 的文件名称

AOF 的命令记录的频率也可以通过 redis.conf 文件来进行配置:

appendfsync always      // 表示每执行一次写命令,立刻记录到 AOF 文件中 
appendfsync everysec    // 写命令执行完先放入 AOF 缓冲区,然后每隔 1 秒将缓冲区数据写入到 AOF 文件,是默认方案
appendfsync no          // 写命令执行完先放入 AOF 缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
配置项 刷盘时机 优点 缺点
Always 同步刷盘 可靠性高,几乎不丢数据 性能影响大
everysec 每秒刷盘 性能适中 最多丢失1秒数据
no 操作系统控制 性能最好 可靠性差,可能丢失大量数据

AOF 是记录命令,AOF 文件会比 RDB 文件大很多。而且 AOF 会记录对同一个 key 的 多次写操作,但只有最后一次写操作才有意义。通过执行 bgrewriteaof 命令,可以让 AOF 文件执行重写功能,用最少的命令达到相同效果。

 

Redis 也会在触发阈值时自动去重写 AOF 文件。阈值也可以在 redis.conf 中配置:

auto-aof-rewrite-percentage 100 // AOF 文件比上次文件增长多少百分比,则触发重写
auto-aof-rewrite-min-size 64mb  // AOF 文件体积最小多大以上才触发重写

#RDB与AOF对比

RDB和AOF各有自己的优缺点,如果对数据安全性要求较高,在实际开发中往往会结合两者来使用。

持久化方式 数据完整性 文件大小 宕机恢复速度 数据恢复优先级 系统资源占用 使用场景
RDB 定时对整个内存做快照 不完整,两次备份之间会丢失 会有压缩,文件体积小 很快 低,因为数据完整性不如AOF 高,大量CPU和内存消耗
AOF 记录每一次执行的命令 相对完整,取决于刷盘策略 记录命令,文件体积很大 高,因为数据完整性更高 低,主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源

你可能感兴趣的:(Redis,redis,java,数据库)