Reids持久化

Redis数据持久化

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

什么是数据持久化

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

🦄什么是RDB

  • RDB称之为快照，也就是将内存中保存的数据原封不动的写入到磁盘中

🐤什么是AOF

  • AOF称之为日志，它会将用户操作的指令写入到磁盘中

区别就是一个写入数据，一个写入指令

RDB快照

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

🐤触发生成RDB三种机制

  • 手动执行save命令
  • save是同步执行
  • 如果已经存在旧的RDB文件，会利用新的覆盖旧的

  • 手动执行bgsave命令
  • 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文件进行校验

RDB存在的问题

不可控、数据丢失

  • 服务器宕机之前的数据，如果未写入RDB文件就会丢失

示例

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

耗时、耗性能

  • RDB是一次性把内存中所有的内容写入到磁盘中，是一个比较重的操作，如果需要写入的数据比较多，那么就比较耗时
  • RDB每次都是把内存中的所有内容全部写入到磁盘中，哪怕内存中的数据已经写入过了也会再次完整写入，重复写入相同的数据，也比较浪费IO资源
  • 如果通过save命令写入，会阻塞后续命令执行，如果是通过bgsave写入，不会阻塞后续命令执行，会开启子进程去专门负责写入，但是开启子进程会消耗内存空间

AOF日志

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

🐤触发生成AOF三种机制

  • always
    • 每条命令都写入一条命令到文件中
    • 优点：不会丢失数据
    • 缺点：磁盘IO消耗较大
  • everysec
    • 每隔1秒写入一次，也就是先收集1秒钟的命令，然后再一次性写入到文件中
    • 优点：磁盘IO消耗相对较小
    • 缺点：可能丢失1秒数据
  • no
    • 让操作系统决定什么时候写入，操作系统想什么时候写入就什么时候写入
    • 不可控，可能丢失大量数据

AOF文件重写

  • 随着时间的推移AOF文件会越来越大
  • 文件越来越大带来的问题就是，磁盘消耗越来越大
  • 文件越来越大带来的问题就是，写入速度会越来越慢
  • 文件越来越大带来的问题就是，恢复的时间越来越慢

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

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

🦄在AOF的重写机制中

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

🐸例如

  • 优化前：set name BNTang; 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推荐配置

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重写时是否正常写入当前操作的命令，如果企业注重安全性就设置为no，就是在重写的时候在期间的操作也写进去，注重性能的话就设置为yes，重写期间的命令不写入，重写完毕之后在写入重写期间的命令

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

所以综上所述，两者各有所长，两者不是替代关系而是互补关系

posted @ 2020-08-08 13:57  BNTang  阅读(87)  评论(0)  编辑  收藏  举报