基础

• 数据持久化是主从复制、故障恢复的基础

• 数据持久化也可以做数据备份

  方式

  RDB

• Redis Database Backupfile

• 产生一个数据快照文件
• 命令
  • save，会阻塞进程，不推荐使用
  • bgsave，不阻塞进程，推荐使用
• 优点
  • RDB备份快照文件是被压缩写入的，体积比整个实例内存要小
  • 实例宕机恢复时，加载RDB文件的速度很快，能够快速恢复
• 不足
  • 某一时刻生成的备份快照文件，数据不一定完整
  • 生成RDB文件会消耗大量CPU和内存资源
    • 采用COW技术，即CopyOnWrite技术即fork系统调用
    • fork系统调用会产生一个子进程，共享父进程内存地址空间，
    • 父进程处理写命令时会重新分配新的内存地址空间，不再与子进程共享即COW（写时复制）
    • 生成RDB文件时，不仅消耗CPU资源，还有可能需要占用最多一倍的内存空间
    • 通过info命令查看fork子进程耗时，从而合理设置生成RDB的时机

• 适用场景

  • 数据库备份（生成RDB+备份RDB）

    # 最近15分钟内 至少产生1次写入
    save 900 1
    # 最近5分钟内 至少产生10次写入
    save 300 10
    # 最近1分钟内 至少产生10000次写入
    save 60 10000

  • 主从全量同步数据

  • 对于丢失数据不敏感的业务场景，实例宕机后快速恢复

AOF

• Append Only File
• 实时追加命令的日志文件，记录每个写命令的详细信息
• 优点
  • 相比RDB更及时，更完整
• 缺点
  • 随着时间增长，AOF文件越来越大
    • 可以通过AOF重写，在文件很大时自动触发重写
    • 重写会扫描整个实例的数据，重新生成一个AOF文件达到瘦身的效果
  • AOF文件刷盘增加磁盘IO，可能影响Redis性能
    • 如果每次写入都进行刷盘，会阻塞进程，影响性能
    • 通常选择每秒刷盘，既保证了良好的性能，又保证数据最多丢失1s
• 适用场景
  • 同时存在RDB和AOF，Redis优先使用AOF文件进行恢复
  • 可以最大可能降低数据丢失的风险，适用于对数据很敏感的业务场景 ```

    开启AOF

    appendonly yes

AOF文件名

appendfilename “appendonly.aof”

文件刷盘方式

appendfsync always：每次写入都刷盘，对性能影响最大，占用磁盘IO比较高，数据安全性最高 appendfsync everysec：1秒刷一次盘，对性能影响相对较小，节点宕机时最多丢失1秒的数据 appendfsync no：按照操作系统的机制刷盘，对性能影响最小，数据安全性低，节点宕机丢失数据取决于操作系统刷盘机制

AOF重写

AOF文件距离上次文件增长超过多少百分比则触发重写

auto-aof-rewrite-percentage 100

AOF文件体积最小多大以上才触发重写

auto-aof-rewrite-min-size 64mb ```

对比