Redis数据持久化（RDB、AOF）

1. 简介

  Redis作为内存型数据库，数据都保存在内存中，如果重启或意外宕机后，数据会全部丢失。因此，Redis提供了完善的持久化机制，将内存中的数据持久化到磁盘上，避免了完整性和安全性的问题，也方便进行数据备份和恢复。

2. 持久化方式

• RDB：产生一个数据快照文件
• AOF：实时追加命令的日志文件

3. RDB

  RDB（Redis Database Backup file），即Redis数据备份文件或Redis数据快照。通过执行save或bgsave命令让Redis在本地生成RDB快照文件，这个RDB文件包含了整个实例接近完整的数据内容。

• 优点
    内存小：RDB将数据压缩写入，因此要比整个实例内存小；
    恢复快：当宕机恢复时，可以快速加载RDB文件并恢复文件中的数据；
• 缺点
    数据不全：因为是某一时刻的数据对照，因此可能会数据不全；
    消耗大：生成RDB文件时会消耗大量的CPU和内存资源；
• 适用场景
    对丢失数据不敏感的业务场景；
    主从全量同步数据；
    数据库备份；
• 定时生成RDB

  # 最近1分钟内，至少生成1次
  save 60 1
  
  # 最近5分钟内，至少生成10次
  save 300 10
  
  # 最近15分钟内，至少生成10000次
  save 900 10000
  

• Copy On Write
    通过执行save或bgsave命令都可以生成RDB文件，前者为前台执行，即生成RDB文件时，会阻塞整个实例，在生成之前，任何请求都是无法处理的，对于数据量非常大的实例，生成RDBwen文件将非常耗时。因此，通常会使用bgsave命令在后台执行，这样Redis依旧可以处理客户端请求，不会阻塞整个实例。
    通过执行bgsave命令生成RDB文件采用操作系统的的Copy On Write技术，即fork系统调用。fork系统调用会产生一个子进程，它与父进程共享相同的内存地址空间，于是子进程在这一时刻就能拥有与父进程的相同的内存数据，操作系统将父进程的内存页表拷贝给子进程，如果整个Redis实例内存占用很大，那它的内存页表也会很大，在拷贝时就会非常耗时，同时这个过程也会消耗大量的CPU资源。在完成拷贝之前父进程处于阻塞状态，无法处理客户端请求。即fork系统调用完成之后，子进程把全部数据写入到RDB文件中；以此同时，父进程依旧处理客户端的请求，当在处理写命令时父进程会从操作系统申请新的内存地址空间，不再与子进程共享，这样父子进程的内存会分离开，父进程在新申请的内存地址中修改数据对子进程不受影响。
    由此可以看出，通过执行save或bgsave命令在生成RDB文件时，不仅消耗CPU资源，还有需要占用最多一倍的内存空间。因此，使用此方式时需要评估即fork系统调用耗时，并且保证Redis实例所在的机器拥有足够的CPU和内存资源，并合理设置生成RDB的时机。

4. AOF

  AOF（Append Only File）即追加日志文件。它与RDB不同的是，AOF中记录的是每一个命令的详细信息，包括完整的命令类型、参数等。只要产生写命令，就会实时写入到AOF文件中。

• 优点
    数据完整：AOF数据文件更新比较及时，比RDB保存更完整的数据，这样在数据恢复时能够恢复尽量完整的数据，降低丢失数据的风险。
• 缺点
    增加IO负担：随着时间增长，AOF文件会越来越大
  AOF文件刷盘会增加磁盘IO的负担，可能影响Redis的性能（开启每秒刷盘时）。
• 适用场景
    对丢失数据敏感的业务场景。
    Redis会优先使用AOF文件进行数据恢复。
• 刷盘方式
    开启AOF后，Redis会把每个写操作的命令记录到文件并持久化到磁盘中，为了保证数据文件的安全性，Redis还提供了三种文件刷盘的机制：
    （1）appendfsync always：每次写入都刷盘。对性能影响最大，占用磁盘IO比较高，数据安全性最高。
    （2）appendfsync everysec：1秒刷一次盘，对性能影响相对较小，节点宕机时最多丢失1秒的数据。
    （3）appendfsync no：按照操作系统的机制刷盘，对性能影响最小，数据安全性低，节点宕机丢失数据取决于操作系统刷盘机制。
• 开启AOF

  # 开启AOF
  appendonly yes
  
  # AOF文件名
  appendfilename "appendonly.aof"
  
  # 文件刷盘方式
  appendfsync everysec
  

• AOF重写
    Redis提供了AOF瘦身的功能，可以设置在AOF文件很大时，自动触发AOF重写，Redis会扫描整个实例的数据，重新生成一个AOF文件达成瘦身的效果。但这个重写过程也需要消耗大量的CPU资源。

  # AOF文件距离上次文件增长多少百分比时触发重写
  auto-aof-rewrite-percentage 100
  
  # AOF文件体积达到多少时触发重写
  auto-aof-rewrite-min-size 64mb
  

• 性能影响
    如果AOF的刷盘机制设置为每次写入都刷盘，那么会大大降低Redis的写入性能，因为每次写命令都需要写入文件并刷到磁盘中才会返回，当写入量很大时，会增加磁盘IO的负担。
    虽然Redis提供了实时刷盘的机制，但是在真正场景中使用的不多。通常我们会选择每秒刷盘这种方式，既能保证良好的写入性能，在实例宕机时最多丢失1秒的数据。

5. 总结

特性	RDB	AOF
持久化方式	生成某一时刻的数据快照文件	实时记录每一个写命令到文件
数据完整性	不完整，取决于备份周期	相对完整性高，取决于文件刷盘方式
文件大小	压缩二进制写入，文件较小	原始的操作命令，文件大
宕机恢复时间	快	慢
恢复优先级	低	高
持久化代价	高，消耗大量CPU和内存	低，只占用磁盘IO资源
使用场景	对丢数据不敏感的业务场景快速数据恢复；数据备份；主从全量复制	对于丢失数据敏感的场景