持久化的两种方式 RDB与AOF

概述

Abstract

RDB和AOF持久化的由来？
因为Redis中的数据是基于内存的，所以如果出现服务器断电或者服务器宕机，那么Redis中存放的数据就会直接丢失。RDB和AOF就是针对Redis提供的两种持久化机制，可以将Redis中的数据持久化到磁盘中。当Redis实例故障重启后，就可以根据备份的文件来进行数据的恢复

RDB

• 概述:
  • RDB全称Redis Database Backup file，也被叫做Redis数据快照，简单来说就是把内存中所有的数据都记录在磁盘中，当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前的运行目录（RDB可以理解为U盘拷贝，将Redis中的数据直接进行复制操作）。每次触发RDB的时候，就会重新生成一个新的RDB文件，覆盖旧的RDB文件文件，这样就可以确保备份得到最新的数据。
• RDB的触发策略：
  1. 关闭Redis实例的时候，redis会在关闭之前主动的进行一次RDB（关闭不是宕机，宕机则数据丢失）
  2. 当你使用save/bgsave命令的时候，redis也会进行内存数据的持久化
  3. 通过配置文件的配置触发：redis.conf配置文件
     • 在配置文件redis.conf指定如下的选项：

       # 900s内至少达到一条写命令
       save 900 1
       # 300s内至少达至10条写命令
       save 300 10
       # 60s内至少达到10000条写命令
       save 60 10000
       

     • 之后在启动服务器时加载配置文件。

       # 启动服务器加载配置文件
       redis-server redis.conf
       

• save/bgsave的不同

  • 前面说到可以使用save命令或者bgsave命令来触发RDB，那么两者有什么区别呢？
    • 如果使用的是save命令，数据备份就是由主线程来操作的，由于Redis是单线程的，所以如果使用save命令来进行内存的数据备份，那么在数据备份的时候redis是无法响应用户的请求的。当需要备份的数据非常大的时候，就可能导致请求被阻塞超时的情况
    • 如果使用的是bgsave命令，那么实际上是主线程fork个子线程，让子线程来进行RDB操作，主线程只是在fork子线程的时候阻塞，之后便可以继续响应用户的请求。接下来子进程即可读取内存数据并进行持久化，生成新的RDB文件替换旧的RDB文件

• RDB缺点：

  • RDB执行间隔时间长，两次RDB之间写入数据有丢失风险
  • fork子进程、压缩、写出RDB文件都比较耗时

• RDB优点：

  • 使用RDB文件进行数据的恢复速度快、效率高（类似于文件拷贝）
  • 相比于AOF持久化的文件，RDB的文件更小

• RDB的相关配置：

  • 在redis.conf配置RDB文件压缩

    # 表示的是是否开启压缩，不建议开启，虽然节省空间，但是会耗费CPU
    rdbcompression yes
    

  • 在redis.conf配置RDB文件名

    # 默认的rdb文件名称
    dbfilename dump.rdb
    

  • 在redis.conf配置rdb文件存放路径

    dir ./
    

  • 在redis.conf配置触发策略

    # 900s内至少达到一条写命令
    save 900 1
    # 300s内至少达至10条写命令
    save 300 10
    # 60s内至少达到10000条写命令
    save 60 10000
    

AOF

Abstract

概述：
AOF的全称叫做Append Only File（追加文件）Redis处理的每一个命令都会记录在AOF文件中，可以看做是命令日志文件（AOF存放的不是数据本身而是执行redis写操作的命令，类似于存放insert/update等这类命令而不是数据）

• 触发策略：根据配置文件触发redis.conf
  • 每执行一次命令，立即记录到AOF文件（性能最差，是有主进程执行）

    appendfsync always
    

• 写命令执行完先放入AOF缓存区，然后每间隔1s将缓冲区中的数据写到AOF文件，默认设置（性能较好，但是可能丢失1s内的数据）

  appendfsync everysec
  

• 写命令执行完先放入AOF缓冲区中，由操作系统决定合适写回磁盘（可靠性比较低，性能最好）

  appendfync no
  

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1s数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

• AOF的重写机制：

  • 由于AOF记录的是命令，那么当执行了很多命令的时候，就会记录到很多的冗余命令，例如：

    # 添加key1的值
    set key1 v1
    # 修改key1的值
    set key1 v2
    # 删除key1的值
    del key1
    

  • 实际上key1最后被删除了，那么所有关于key1的命令实际上都是没有作用的，但是AOF中却记录了所有的命令，这样就会导致AOF文件很大而且存放了很多冗余命令。
  • 通过使用bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果，执行完该指令后，所以的冗余指令就会被删除，达到AOF文件压缩的效果。

• AOF优点：

  • 通过配置，可以使得备份的数据更加完整安全
  • 每次进行AOF时占用的CPU资源较少（因为是追加，RDB则是全部重新复制一遍）
• AOF缺点：
  • 通过使用AOF文件进行恢复的速度较慢，需要依次执行所有指令
  • AOF文件可能会比RDB大得多，记录的是所有的写操作
• AOF配置：
  • 在redis.conf配置AOF开启

    # 表示的是开启，默认是no
    appendonly yes
    

  • 在redis.conf配置AOF文件名

    # 这里表示的是AOF文件名称
    appendfilename "appendonly.aof"
    

  • 在redis.conf配置重写触发策略

    # AOF文件比上次文件增长超过百分之百则触发重写
    auto-aof-rewrite-percentage 100
    # AOF文件体积最小多大以上才能触发重写
    auto-aof-rewrite-min-size 64mb
    

RDB和AOF的对比

Method	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积较小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全要求较高常见

总结

• 默认方式开启的是RDB，AOF默认是关闭的
• 在实际使用中，一般不会单独的开启其中的一个，一般都会使用两者结合的方式一并使用。RDB根据有容灾性，可以周期性的进行RDB得到指定时间点的备份文件。AOF则数据更加的完整，仅仅有非常少的数据的丢失。