redis的数据持久化就是为了保障数据安全性问题。将内存数据存储到磁盘当中,即持久化问题。Redis提供了两种方式去保障数据的持久化问题。
RDB(Redis Data Base):内存快照
内存快照:就是指内存中数据在某一时刻的状态记录。
RDB是Redis中默认的持久化方案。RDB持久化会将内存中的数据写入到磁盘中,在指定的目录下生产一个dump.rdb文件。Redis重启时会加载dump.rdb文件恢复数据。
Redis中提供了两个命令生成RDB文件。分别save和bgsave。
save:在主进程中执行,会导致阻塞
bgsave:创建一个子进程,用户写入RDB文件,避免了主线程的阻塞,该方式是RDB文件生成的默认配置
bgsave命令执行原理
1、执行bgsave命令
2、Redis中的父进程判断当前是否存在正在执行的子进程,如果存在,命令直接返回
3、父进程fork操作创建子进程
4、父进程完成fork操作之后,父进程可以继续接受并处理用户请求,而子进程负责将内存中的数据写入到磁盘中临时文件
5、当子进程完成所有数据写入后会用临时文件替换旧的RDB文件
触发RDB方式
1、手动触发:用户执行save或者bgsave命令
2、被动触发
根据自己配置的规则进行自动快照,就是持久化数据的时机
格式:save <seconds> <changes>
# save 3600 1 //每3600秒至少1个key发生改变,产生快照
# save 300 100 //每300秒至少10个key发生变换,产生快照
# save 60 10000//每60秒至少10000个key发生改变,产生快照
优点
1、RDB加载Redis恢复数据远远快于AOF的方式
2、使用单独的子进程来进程持久化,主进程不会进行任何的IO操作,保证Redis的高性能
缺点
1、RDB方式数据无法做到实时持久化,可能会存在数据丢失问题
2、存在格式不兼容问题,RDB文件使用特定二进制格式保存,Redis在版本升级后,可能存在老版本Redis无法兼容新版本RDB格式问题
AOF(Append Only File)增量日志
AOF持久化,以独立的日志的方式记录每次写命令,redis重启是会重新执行AOF文件中的命令达到回复数据的目的。AOF主要作用是解决数据持久化的实时性。默认情况下Redis没有开启AOF方式的持久化,可以通过appendonly参数启用:apendonly yes,开启AOF方式持久化每执行一条命令,Redis就会将命令写入到aof_buff缓冲区,AOF缓存去会根据对应的策略向磁盘做同步操作,默认情况在30秒就会执行一次同步操作,为了防止缓冲区数据的丢失。
AOF持久化执行流程:
1、所有的写入命令会追加到AOF缓冲区
2、AOF缓冲区根据对应的策略向磁盘同步
3、随着AOF文要件越来越大,需要定期对AOF文件进行重写,达到压缩文件体积的目的,AOF文件重写是吧Redis进程内的数据转化为写命令同步新AOF
4、当Redis进行重启时,可以加载AOF文件进行数据恢复
AOF保存文件:appendonly.aof
AOF缓冲区同步文件策略
AOF机制提供了三个选择,即通过appendfsync配置三个可选项
有三种方式,默认是每秒everysec执行一次
always:同步写回,每个写命令执行完,立马同步将日志写回磁盘,保证完全持久化,最慢
everysec:每秒写回:每个命令执行完,只是先把日志写到AOF文件的内存缓冲区,每隔一秒把缓冲区的数据写入磁盘
no:操作系统控制写回:每个命令执行完,先把日志写到AOF文件的内存缓冲区,由操作系统决定何时从缓冲区写回此判断,性能最好,持久化没法保证
优点
1、AOF可以更好的保护数据不丢失,可以配置AOFeverysec操作,每秒执行一次,如果Redis挂掉,最多丢失1秒的数据
2、AOF是以Append-only的模型写入,没有磁盘寻址的开销,写入性能比较高
缺点
1、对于同一份文件AOF文件比RDB数据快照要大
2、数据恢复比较慢
RDB VS AOF总结
RDB | AOF | |
过程 | ||
存储内容 | 键值对数据 | 写指令 |
占用存储空间 | 小(数据级:压缩) | 大(指令级:重写) |
文件格式 | 二进制文件 | 文本数据文件 |
存储速度 | 慢(全量) | 快(增量) |
恢复速度 | 快 | 慢 |
数据安全性 | 会丢失数据 | 依策略而定 (everysec理论丢失1秒数据) |
资源消耗 | 高/重量级 | 低/轻量级 |
启动优先级 | 低(默认) | 高 |