这篇文章咱们来介绍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：

# 开启AOFappendonly 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...