Redis 高可用之"持久化"

Redis高可用概述

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

• 持久化：

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

• 复制：

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

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

• 哨兵：

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

  缺陷：写操做没法负载均衡；存储能力收到单机限制。

• 集群：

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

Redis持久化概述

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

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

• 前者是将数据保存到硬盘。
• 后者是将每次执行的写命令保存到硬盘。

RDB 持久化

​ 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

除了 save m n 之外，还有一些其余状况会触发 bgsave：

• 在主从复制场景下，若是从节点执行全量复制操做，则主节点会执行 bgsave 命令，并将 RDB 文件发送给从节点。
• 执行 shutdown 命令时，也会自动执行 RDB 持久化。

启动时加载

​ RDB 的载入工做实在服务器启动时自动执行的，并无专门的命令。可是因为 AOF 的优先级更高，所以当 AOF 开启时，会优先载入 AOF 文件来恢复数据。

文件校验：

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

AOF 持久化

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

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

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

文件校验：

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

RDB与AOF的优缺点

RDB 持久化：

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

• 缺点：RDB 文件的致命缺点在于其数据快照的持久化方式决定了必然作不到实时持久化，而在数据愈来愈重要的今天，数据的大量丢失不少时候是没法接受的，所以 AOF 持久化成为主流。

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

AOF 持久化：

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