Redis篇4-redis持久化RDB与AOF

概述

• redis提供两种内存数据持久化方式，RDB和AOF
• 官方说明：https://redis.io/topics/persistence
• RDB（RedisDatabase）
  • 使用Snapshot，即规律性（可配置）的将内存中的数据写入到快照文件（dump.rdb文件），恢复时直接从文件读取到内存。
  • redis会fork出一个子进程（即复制一个和当前进程一样的进程，新进程的数据数值都和原进程一致，并作为其子进程）来完成上述持久化。先将内存数据写入一个临时文件，等持久化全部完成，用这个临时文件代替上次持久化号的文件。整个过程中，主服务进程不进行IO操作，保证了性能。
  • 优点：数据恢复性能表现优于AOF，大规模数据的恢复且对完整性要求不高的场景，RDB方式要比AOF要简单高效。
  • 缺点：双倍消耗（主进程fork） ； 最新的数据可能丢失（突然宕机，没有持久化到）。
• AOF（Append Only File）
  • 弥补RDB最新数据可能丢失的缺点
  • 用文件（appenonly.aof）记录客户端的所有的写入操作，启动时读取该文件，按顺序重现所有的append，达到重现数据的目的。
  • 优点：数据完整性好；文件具有可读性，可进行数据分析。
  • 缺点：文件不断追加记录，很容易膨胀；恢复性能弱于RDB。
• 说明
  可以两者同时使用，当RDB文件和AOF文件同时存在，优先读取AOF文件。
  当AOF不存在或者读取出错时（写的时候突然断电），再读取RDB。
• 使用建议（看使用场景）
  • redis仅用于运行时缓存
    比如保存session或者token，则可以不用RDB和AOF，避免性能消耗和磁盘占用。
  • 不只是用于运行时缓存，而且分担了传统的数据库热点数据压力
    适当降低RDB触发频率（调整save-change）和AOF-rewite频率（调大rewrite-min-size）。
  • 使用 replication（主从复制）

---

RDB配置与操作

• RDB文件就是缓存数据的不同时刻的快照。
• 相关配置见redis.conf的SNAPSHOTTING配置块。
• RDB默认是开启的，这也是为什么默认shutdown掉redis-server后，重启（自动加载目标RDB文件）能有数据的原因（虽然数据可能不是最新版本）。

关键配置项

• save <seconds> <changes> 配置RDB写入触发策略
  • 默认以下三种触发策略：

    save 900 1 #900秒内发送一次修改
    save 300 10 #或 300秒内10次修改
    save 60 10000 #或 60秒10000次修改
    

  • 移除全部save项或者仅留一个save ""，可以禁用RDB写入，即不启用RDB（慎用）
  • 添加一个短时策略 save 20 3 ，20秒内3次
  • 重启服务，20s内连续定义3个键值，查看 dump.rdb（默认路径/usr/local/bin）已经更新

    set k1 v1
    set k2 v2
    set k3 v3
    get k1
    shudown
    

  • 重启服务，连接后 >get k1 可以得到 v1
  • 注1：生产上，运维人员一般会对这个RDB文件进行再备份到另一台机器（灾备机），防止这台机器直接坏掉（不是宕掉）。
  • 注2：使用shutdown模拟宕机是不准确的，shutdown执行会立即触发RDB备份（如果之前进行了flushdb/flushall的操作，RDB文件也就空了），并不是正常的RDB。而真正的宕机是不会shutdown的，RDB只进行到了上次周期触发。
• stop-writes-on-bgsave-error yes
  默认地，当后台RDB备份出错时，停止结束客户端的写入请求，for 持久化数据的完整性。
• rdbcompression yes 默认启用RDB文件压缩，设置为no可以微改善性能。
• rdbchecksum yes 默认启用RDB文件数据校验，设置为no可以较大提高性能。
• ...

RDB快照触发时机

• save <seconds> <changes> 配置策略
• save命令（阻塞写入操作） 和 bgsave命令（异步）

127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> lastsave
(integer) 1568094374

• flushall命令（dump.rdb文件清空，无意义，慎用）
• shutdown关闭连接时

---

AOF配置操作

• 相关配置见redis.conf的APPEND ONLY MODE配置块。
• AOF默认是关闭的 appendonly no，请修改修改以开启。

快速使用

• 新拷贝初始配置文件 cp /tmp/redis-5.0.5/redis.conf ./redis-aof.conf
• 修改 appendonly yes，禁掉RDB（注掉所有save change项）
• 重新运行服务 redis-server redis-aof.conf
• append 几个键值对
• 查看appendonly.aof文件 cat appendonly.aof 可以看到刚刚输入的命令
• 重启服务，验证数据恢复
• 注：flushdb和flushall都会被.aof文件记录

关键配置项

• appendfsync everysec aof文件写入策略，有三个选项
  • everysec 默认推荐选项，每秒写入，所以防不了1秒宕机事件..
  • always 每次写入命令都同步记录，影响性能但是数据完整性最好
  • no 不写入，极端不考虑
• auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb
  AOF缺点是文件会越来越大，特别是分布式集群redis环境下，.aof文件膨胀速度很快。
  • 对此redis提供了.aof文件“瘦身”方法：当文件大小到达一个阈值（默认是接近上次文件100%且大于64M，此配置可以看出公司的redis缓存压力程度），触发一个rewite操作（即分析上下文，合理精简）。
• no-appendfsync-on-rewrite no 是否在进行上述rewite操作时停止aof写入动作，为更好的数据完整性请保持默认的no，设置yes可以稍提升性能。
• ...

补充

• 当aof文件异常（突然宕机或断电，写入不规范），可以使用 Usage: redis-check-aof [--fix] <file.aof> 进行检查和修复
• RDB文件也是如此，工具程序目录：/usr/local/bin
• 同RDB文件，生产上一般也会对aof文件进行容灾再备份操作