Redis 高可用之”持久化”「建议收藏」

大家好，我是考100分的小小码，祝大家学习进步，加薪顺利呀。今天说一说Redis 高可用之”持久化”「建议收藏」,希望您对编程的造诣更进一步.

在Redis中，实现高可用的技术主要包括：持久化、复制(读写分离)、哨兵、集群。

持久化：

持久化是最简单的高可用方法(有时甚至不被归为高可用手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
复制：

复制是高可用Redis的基础，哨兵和集群都是在复制的基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。

缺陷：故障恢复无法自动化，写操作无法负载均衡，存储能力受到单机的限制。
哨兵：

在复制的基础上，哨兵实现了自动化的故障恢复。

缺陷：写操作无法负载均衡；存储能力收到单机限制。
集群：

通过集群，Redis解决了操作无法负载均衡，以及存储能力收到单机限制的问题，实现了较为完善的高可用解决方案。

持久化的功能：Redis 是内存数据库，数据都是存储在内存中。

Redis 的持久化分为 RDB 和 AOF 持久化：

RDB持久化是将当前进程中的数据生成快照保存到硬盘中(因此也叫做快照持久化)，保存的文件后缀是RDB；

当Redis重新启动时，可以读取快照文件恢复数据。

触发条件：

手动触发：save命令和bgsave命令都可以生成 RDB 文件。

save命令会阻塞 Redis 服务进程，直到 RDB 文件创建完毕为止，在 Redis 服务器阻塞期间，服务器不能执行任何命令请求。

bgsave命令会创建一个子进程，由子进程来创建 RDB 文件，父进程(即 Redis 主进程) 继续处理请求。bgsave 命令执行过程中，只有fork(ork了进程，子进程中的redis连接没法用了，要重连) 子进程会阻塞服务器，而对于 save 命令，整个过程都会阻塞服务器。

在自动触发 RDB 持久化时，Redis 也会使用 bgsave 而不是 save 来进行持久化；下面介绍自动触发 RDB 持久化条件。

自动触发：最常见的情况是在配置文件中通过 save m n ，指定 m 秒内发生了 n 次变化时，会触发 bgsave。

在Redis 配置文件Redis.conf中，可以看到如下配置信息：

save 900 1  #当时间到 900 秒时，如果 Redis 数据发生了至少 1 次变化，则执行 bgsave。
save 300 10 
save 60 10000

代码100分

除了 save m n 以外，还有一些其他情况会触发 bgsave：

启动时加载

RDB 的载入工作实在服务器启动时自动执行的，并没有专门的命令。但是由于 AOF 的优先级更高，因此当 AOF 开启时，会优先载入 AOF 文件来恢复数据。

文件校验：

Redis 载入 RDB 文件时，会对 RDB 文件进行校验，如果文件损坏，则日志中会打印错误，Redis 启动失败。

RDB 持久化是将进程数据写入硬盘，而 AOF 持久化(即 Append Only File 持久化)，则是将 Redis 执行的每次写命令记录到单独的日志文件中，当 Redis 重启的时候再次执行 AOF 来恢复数据。

与 RDB 相比，AOF 实时性更好，因此已成为当前主流的持久化方案。

开启 AOF：Redis 服务器默认开启 RDB，关闭 AOF；要开启 AOF，需要在配置文件中配置：appendonly yes。

文件校验：

与载入 RDB 文件类似，Redis 载入 AOF 文件时，会对 AOF 文件进行校验，如果文件损坏，则日志中会打印错误，Redis 启动失败。

RDB 持久化：

优点：RDB 文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比 AOF 快很多。当然，与 AOF 相比，RDB 最重要的优点之一是对性能的影响相对较小。
缺点：RDB 文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此 AOF 持久化成为主流。

此外，RDB 需要满足特定的格式，兼容性差/

AOF 持久化：

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/10283.html