这篇文章咱们来介绍 Redis 高可用相干的机制。Redis 要想实现高可用，次要有以下方面来保障：
- 数据长久化
- 主从复制
- 主动故障复原
- 集群化
这篇文章咱们先介绍 Redis 的高可用保障的根底：数据长久化。因为 Redis 的主从复制和主动故障复原，都须要依赖 Redis 长久化相干的货色。同时，Redis 的数据长久化也能够用来做数据备份，用来保障数据的安全性。
Redis 是一个内存数据库，它的数据都保留在内存中，如果实例宕机，那么数据则全副失落。如何保证数据的完整性和安全性也是进步服务高可用的重要机制之一。
Redis 提供了欠缺的长久化机制，能够把内存中的数据长久化到磁盘上，不便咱们进行备份数据和疾速复原数据。
这篇文章咱们就来剖析 Redis 的数据长久化是如何实现的？咱们常常听的 RDB 和 AOF 有什么区别？以及它们不同的应用场景。
长久化形式
Redis 提供的数据长久化形式次要有 2 种：
- RDB：产生一个数据快照文件
- AOF：实时追加命令的日志文件
它们别离对应了不同的应用场景，上面咱们就来顺次剖析。
RDB
介绍
RDB 全称 Redis Database Backup file（Redis 数据备份文件），也被叫做 Redis 数据快照。
咱们能够通过执行 save 或 bgsave 命令让 Redis 在本地生成 RDB 快照文件，这个 RDB 文件蕴含了整个实例靠近残缺的数据内容。 它的长处如下：
- RDB 文件数据是被压缩写入的，因而 RDB 文件的体积要比整个实例内存要小
- 当实例宕机复原时，加载 RDB 文件的速度很快，可能在很短时间内迅速复原文件中的数据
它的毛病也很显著：
- 因为是某一时刻的数据快照，因而它的数据并不全
- 生成 RDB 文件的代价是比拟大的，它会耗费大量的 CPU 和内存资源
因而 RDB 比拟实用于以下场景：
- 主从全量同步数据
- 数据库备份
- 对于失落数据不敏感的业务场景，实例宕机后疾速复原数据
Redis 主从全量同步数据就是应用 RDB 文件进行的，咱们会在前面的文章具体讲到。
由此能够看出，RDB 非常适合做数据备份，咱们能够定时让 Redis 生成 RDB 文件，而后备份这个快照文件即可。
定时生成 RDB
Redis 也提供了定时触发生成 RDB 文件的配置项：
# 最近 15 分钟内 至多产生 1 次写入
save 900 1
# 最近 5 分钟内 至多产生 10 次写入
save 300 10
# 最近 1 分钟内 至多产生 10000 次写入
save 60 10000
如果达到以上任意条件，则 Redis 会主动生成新的 RDB 文件，升高 RDB 数据内容与实例数据的差别。
Copy On Write
在 Redis 上执行 save 和 bgsave 命令都能够生成 RDB 文件，但前者是在前台执行的，也就是说在生成 RDB 文件时，会阻塞整个实例，在 RDB 未生成之前，任何申请都是无奈解决的，对于内存很大的实例，生成 RDB 文件十分耗时，显然这是咱们不能承受的。
所以通常咱们会抉择执行 bgsave 让 Redis 在后盾生成 RDB 文件，这样 Redis 仍旧能够解决客户端申请，不会阻塞整个实例。
但不是说后盾生成 RDB 就是没有代价的，Redis 为了实现后盾把内存数据的快照写入文件，采纳了操作系统提供的 Copy On Write 技术，也就是咱们熟知的 fork 零碎调用。
fork 零碎调用会产生一个子过程，它与父过程共享雷同的内存地址空间，这样子过程在这一时刻就能领有与父过程的雷同的内存数据。
尽管子过程与父过程共享同一块内存地址空间，但在 fork 子过程时，操作系统须要拷贝父过程的内存页表给子过程，如果整个 Redis 实例内存占用很大，那么它的内存页表也会很大，在拷贝时就会比拟耗时，同时这个过程会耗费大量的 CPU 资源。在实现拷贝之前父过程也处于阻塞状态，无奈解决客户端申请。
fork 执行完之后，子过程就能够扫描本身所有的内存数据，而后把全副数据写入到 RDB 文件中。
之后父过程仍旧解决客户端的申请，当在解决写命令时，父过程会重新分配新的内存地址空间，从操作系统申请新的内存应用，不再与子过程共享，这个过程就是 Copy On Write（写实复制）名字的由来。这样父子过程的内存就会逐步拆散，父过程申请新的内存空间并更改内存数据，子过程的内存数据不受影响。
由此能够看出，在生成 RDB 文件时，不仅耗费 CPU 资源，还有须要占用最多一倍的内存空间。
咱们在 Redis 执行 info 命令，能够看到 fork 子过程的耗时，能够通过这个耗时来评估 fork 工夫是否合乎预期。同时咱们应该保障 Redis 机器领有足够的 CPU 和内存资源，并正当设置生成 RDB 的机会。
AOF
介绍
AOF 全称为 Append Only File（追加日志文件）。它与 RDB 不同的是，AOF 中记录的是每一个命令的详细信息，包含残缺的命令类型、参数等。只有产生写命令，就会实时写入到 AOF 文件中。
咱们能够通过配置文件开启 AOF：
# 开启 AOF
appendonly yes
# AOF 文件名
appendfilename "appendonly.aof"
# 文件刷盘形式
appendfsync everysec
刷盘形式
开启 AOF 后，Redis 会把每个写操作的命令记录到文件并长久化到磁盘中，为了保障数据文件的安全性，Redis 还提供了文件刷盘的机会：
- appendfsync always：每次写入都刷盘，对性能影响最大，占用磁盘 IO 比拟高，数据安全性最高
- appendfsync everysec：1 秒刷一次盘，对性能影响绝对较小，节点宕机时最多失落 1 秒的数据
- appendfsync no：依照操作系统的机制刷盘，对性能影响最小，数据安全性低，节点宕机失落数据取决于操作系统刷盘机制
以上能够看出 AOF 绝对于 RDB 的长处是，AOF 数据文件更新比拟及时，比 RDB 保留更残缺的数据，这样在数据恢复时可能复原尽量残缺的数据，升高失落数据的危险。
如果同时存在 RDB 文件和 AOF 文件，Redis 会优先应用 AOF 文件进行数据恢复。
但它的毛病也很易见：
- 随着工夫增长，AOF 文件会越来越大
- AOF 文件刷盘会减少磁盘 IO 的累赘，可能影响 Redis 的性能（开启每秒刷盘时）
AOF 重写
针对第一种状况，Redis 提供了 AOF 瘦身的性能，能够设置在 AOF 文件很大时，主动触发 AOF 重写，Redis 会扫描整个实例的数据，从新生成一个 AOF 文件达成瘦身的成果。但这个重写过程也须要耗费大量的 CPU 资源。
# AOF 文件间隔上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF 文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
因为 AOF 能够最大可能升高失落数据的危险，所以它个别实用于对失落数据很敏感的业务场景，例如波及金钱交易的业务。
性能影响
如果 AOF 的刷盘机会设置为每次写入都刷盘，那么会大大降低 Redis 的写入性能，因为每次写命令都须要写入文件并刷到磁盘中才会返回，当写入量很大时，会减少磁盘 IO 的累赘。性能与数据安全不能兼得，尽管 Redis 提供了实时刷盘的机制，然而在真正场景中应用的不多。
通常咱们会抉择每秒刷盘这种形式，既能保障良好的写入性能，在实例宕机时最多失落 1 秒的数据，做到性能和平安的均衡。
总结
咱们对 RDB 和 AOF 的总结如下表。 咱们须要针对不同的业务场景抉择适合的长久化形式，也能够依据 RDB 和 AOF 的长处配合应用，保障 Redis 数据的安全性，又能够兼顾它的性能。
作者：Kaito
链接：http://kaito-kidd.com/2020/06…