持久化

利用永久性的储存介质进行保存，在特定的时间将保存的数据进行恢复的工作机制

RDB

• 手动执行一次保存（在工作空间生成一个2进制的dump.rdb文件） save

  

• 保存后，下一次启动redis直接会恢复对应数据

• save 指令执行会阻塞当前的Redis服务器，直到RDB过程完成为止，有可能会造成长时间的阻塞，线上环境不建议使用

bgsave

• 后台储存过程中如果出现错误现象，是否停止保存操作（默认开启） stop-writes-on-bgsave-error yes

RDB启动方式

• 在conf文件中配置 save second changes 满足时间范围内key的变化数量达到指定数量进行持久化，默认使用 bgsave

rdb特殊启动形式

• 服务器运行过程中重启 debug reload
• 关闭服务器时指定保存数据 shutdown save

RDB的优点

• RDB是一个紧凑的二进制文件，储存效率较高
• RDB内部储存的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度比AOF快很多
• 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复

RDB缺点

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
• bgsave 指令每次运行都需要执行fork操作创建子进程，要牺牲掉一些性能
• Redis 的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本之间的数据格式无法兼容的现象
• 储存数据量大，效率低（基于快照思想，每次读写全部数据，当数据量大时，效率低），io性能低

AOF

AOF持久化：以独立日志方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的，与RDB相比可以简单的描述为改记录数据为记录数据的产生过程

AOF 写数据三种策略

• always 每次写入操作均同步到AOF文件中，数据0误差，性能低
• everysec 每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能高，建议使用（默认），系统忽然宕机时丢失一秒数据
• no 操作系统控制每次同步到AOF文件的周期，不可控、

AOF功能打开

• 配置文件 添加以下配置

  appendonly yes (默认no)
  appendfsync always (everysec || no)
  appendfilename 保存的文件名
  

AOF重写

• 手动重写 bgrewriteaof
• 自动重写配置

auto-aof-rewrite-min-size size // 按大小重写
auto-aof-rewrite-percentage percentage // 按比例重写

RDB与AOF区别

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7yISzJlo-1603876134211)(C:\Users\86188\AppData\Roaming\Typora\typora-user-images\image-20201027112853609.png)]