概念

1.Redis数据持久化

  • 默认情况下Redis是将数据保存在内存中的, 保存在内存中的数据有一个特点, 那就是机器重启之后数据就会丢失
  • 所以为了避免服务器重启死机等问题发生的时候, Redis中保存的数据丢失, Redis提供了数据持久化功能

2.什么是数据持久化

  • 数据持久化就是将内存中的数据写入到磁盘中
  • Redis和大部分主流数据库(MySQL/MongoDB/...)一样, 支持RDB和AOF持久化

RDB

1.RDB(快照)

将内存中所有内容写入到一个文件中

2.触发生成RDB三种机制

  • 手动执行save命令

    • 同步执行
    • 如果已经存在旧的RDB文件, 会利用新的覆盖旧的

  • 手动执行bgsave命令

    • 异步执行
    • 如果已经存在旧的RDB文件, 会利用新的覆盖旧的

  • 通过配置文件自动生成

    • 通过配置文件指定自动生成条件, 一旦满足条件就会自动执行bgsave生成RDB文件
      dir ./ #RDB文件保存的路径

    dbfilename dump.rdb #RDB文件的名称
    #save 900 1 #自动生成条件
    #save 300 10
    #save 60 10000
    stop-writes-on-bgsave-error yes #bgsave发生错误是否停止写入
    rdbcompression yes #是否采用压缩模式写入
    rdbchecksum yes #是否对生成的RDB文件进行校验

  • 自动生成弊端

    • 无法控制生成的频率, 如果频率过高会导致性能消耗较大
  • 推荐配置
    dir /rdbdiskpath #由于备份是比较占用磁盘空的, 所以推荐使用一个比较大的磁盘路径

dbfilename dump-${prot}.rdb #由于一台服务器上可能部署多个Redis, 所以可以给RDB文件添加端口号作为区分
stop-writes-on-bgsave-error yes #bgsave发生错误是否停止写入
rdbcompression yes #是否采用压缩模式写入
rdbchecksum yes #是否对生成的RDB文件进行校验
-->
<!--
1.RDB存在的问题

  • 不可控、数据丢失

    • 服务器宕机之前的数据, 如果未写入RDB文件就会丢失
      示例: set name lnj

    save or bgsave or 自动保存
    set name zs
    set name ls
    set name ww
    宕机

  • 耗时、耗性能

    • RDB是一次性把内存中所有的内容写入到磁盘中, 是一个比较重的操作
      如果需要写入的数据比较多, 那么就比较耗时
    • RDB每次都是把内存中的所有内容全部写入到磁盘中,
      哪怕内存中的数据已经写入过了也会再次完整写入,

    重复写入相同的数据, 也比较浪费I/O资源

    • 如果通过save命令写入, 会阻塞后续命令执行
      如果是通过bgsave写入, 不会阻塞后续命令执行,

    会开启子进程去专门负责写入, 但是开启子进程会消耗内存空间

AOF

1.AOF(日志)

将每一条操作Redis的指令都写入到文件中

2.触发生成AOF三种机制

  • always

    • 每条命令都写入一条命令到文件中
    • 优点: 不会丢失数据
    • 缺点: 磁盘I/O消耗较大

  • everysec

    • 每隔1秒写入一次, 也就是先收集1秒钟的命令, 然后再一次性写入到文件中
    • 优点: 磁盘I/O消耗相对较小
    • 缺点: 可能丢失1秒数据

  • no

    • 让操作系统决定什么时候写入, 操作系统想什么时候写入就什么时候写入
    • 不可控, 可能丢失大量数据

3.AOF重写

AOF文件重写

  • 随着时间的推移AOF文件会越来越大

    • 文件越来越大带来的问题就是-磁盘消耗越来越大
    • 文件越来越大带来的问题就是-写入速度会越来越慢
    • 文件越来越大带来的问题就是-恢复的时间越来越慢
    • ... ...

  • 所以AOF提供了重写的机制

    • 我们可以对AOF文件中保存的内容进行优化
    • 从而降低文件的体积
    • 从而提升文件的恢复速度

  • 在AOF的重写机制中

    • 可以将自动去除冗余命令
    • 可以自动删除没有用的命令
    • ... ...

  • 例如:

    • 优化前: set name lnj; set name zs; set name ls;
    • 优化后: set name ls;
    • 优化前: incr count; incr count; incr count; incr count;
    • 优化后: set count 4;
    • 优化前: expire name 3
    • 优化后: 3秒后由于数据已经被删除, 所以这条命令不用保存
    • ... ...

触发AOF重写两种机制

  • bgrewriteaof命令

    • 开启一个新的子进程, 根据内容中的数据生成命令写入到AOF文件中
  • 配置文件设置
    auto-aof-rewrite-min-size 200mb #AOF文件体积达到多大时进行重写

auto-aof-rewrite-percentage 100 #对比上一次重写后, 增长了百分之多少再次进行重写

                              #例如上一次重写后大小是100MB, 如果设置为50, 那么下一次就是增长0.5倍(150M)之后再重写
                              #例如上一次重写后大小是100MB, 如果设置为100, 那么下一次就是增长两倍(200M)之后再重写

AOF推荐配置

  • AOF推荐配置
    appendonly yes #是否使用AOF

appendfilename "appendonly-${prot}.aof" #AOF文件名称
appendfsync everysec #写入命令的同步机制
dir /rdbdiskpath #保存AOF文件路径
auto-aof-rewrite-min-size 64mb #AOF文件重写体积
auto-aof-rewrite-percentage 100 #AOF文件增长率
no-appendfsync-on-rewrite yes #AOF重写时是否正常写入当前操作的命令

RDB和AOF对比

  • AOF优先级高于RDB

    • 如果Redis服务器同时开启了RDB和AOF, 那么宕机重启之后会优先从AOF中恢复数据

  • RDB体积小于AOF

    • 由于RDB在备份的时候会对数据进行压缩, 而AOF是逐条保存命令, 所以RDB体积比AOF小

  • RDB恢复速度比AOF恢复速度快

    • 由于AOF是通过逐条执行命令的方式恢复数据, 而RDB是通过加载预先保存的数据恢复数据
      所以RDB的恢复速度比AOF快

  • AOF数据安全性高于RDB

    • 由于AOF可以逐条写入命令, 而RDB只能定期备份数据, 所以AOF数据安全性高于RDB
  • 所以综上所述, 两者各有所长, 两者不是替代关系而是互补关系
Last modification：July 28th, 2020 at 03:57 pm
© 允许规范转载
来杯coffee吧