1. Redis 持久化
将内存中的数据放在硬盘中实现数据的长久保存,避免因为进程退出导致的数据丢失问题,持久化在redis中分为两种方式rdb(快照)和aof(日志)
1) rdb
-
将当前的进程的数据拍成快照保存到硬盘,触发rdb的方式为手动触发或者自动触发
-
redis重启之后数据依旧存在,是因为在关闭redis时会触发持久化操作,将当前的数据保存为快照(/usr/src/redis*/dump.rbd) ,在开机时再次读取该文件总的内容恢复 数据库
-
dbfilename dump.rbd 设置rdb持久化文件文件名
-
dir ./ 读取和保存持久化文件位置 生成的位置根据启动的位置所生成
-
手动触发(命令触发)持久化
save 阻塞当前服务器,知道持久化完成后结束阻塞(生产环境弃用)
bgsave redis执行fork操作创建子进程,rdb持久化过程由子进程负责,完成子进程自动退出(生产环境使用)
1) 在m秒内存在N次修改,自动触发bgsave
2) 从服务器第一连接处服务器时,主服务器自动bgsave
3) 使用debug reload 进行操作,触发save操作
4) 执行shutdown 时,如果aof持久没有开启,自动bgsave
-
bgsave工作流程
- 1) 当执行bgsave时,父进程准备生成子进程,如果当前有在执行持久化的子进程,不做任何操作直接返回
- 2) 父进程通过fork操作生成子进程,fork过程数据重量级操作会阻塞很短时间
- 3) 当fork操作结束时,出现background saving started 信息之后,父进程不再阻塞,可以继续响应其他指令,持久化过程由子进程负责
- 4) 子进程创建rdb文件,根据父进程内存页生成文件,对原本的dump.rdb进行覆盖操作
- 5) 子进程发送结束信息给父进程表示完成,之后退出,父进程更新信息
-
如果硬盘写满的情况怎么办?
- 更改rdb文件的保存路径
- 更改rdb文件的文件
- 重写配置文件(使以上两条命令改为永久生效)
127.0.0.1:6379> config set dir /root
127.0.0.1:6379> config set dbfilename hahaha.rdb
config rewrite
-
rdb优点
- 1) rdb属于一个紧凑压缩的二进制文件,表示在某个时间节点的快照,适用于全量复制和备份场景
- 2) rdb持久化得到的文件加载速度要远高于aof文件
-
rdb缺点
- 1) rdb快照不能达到秒级别备份(fork操作数据重量及操作)
- 2) rdb文件已二进制形式存放,存在兼容问题
2) aof
-
为了解决rdb文件不能秒级别备份问题出现了aof持久化(日志)
-
aof 持久化以独立日志的方式进行记录数据,redis目前恢复数据实际上时在每次运行redis时读取持久话文件达到恢复数据的目的,且aof文件作为目前的主流持久化方式,应用广泛
-
开启aof持久化的方式
- 在配置文件中找到
appendonly yes
-
aof文件的工作流程
- 命令写入 》》 文件同步 》》 文件重写 》》 重启加载
- 1) 所有的命令追加到aod_buf缓冲区
- 2) aof缓冲区根据策略想硬盘进行同步
- 3) 随着aof文件越来越大,定期对aof文件进行重写
- 4) 重启服务器加载aof文件恢复数据
-
redis进行启动时会加载持久化文件进行恢复数据,aof文件优先级要高于rdb文件
-
aof采用文本的方式,为什么会会采用文本的方式?
- 1) 文本具有很好的兼容
- 2) 文本协议就很好的可读性,方便直接查看或者修改删除等操作
-
aof 根据策略向硬盘同步
- always 命令写入缓冲区后,直接同步到aof文件
- everysec 命令写入缓冲区后,aof文件调用write操作每秒执行一次,达到秒级别备份
- no 命令吸入缓冲区redis不做想aof文件同步操作,同步操作有操作系统负责
# appendfsync always ## 默认使用everysec
appendfsync everysec
# appendfsync no
-
aof 重写机制
- 随着日志越写越多,文件越来越大redis引用了重写机制,解决问题,重写的文件为什么变小?
- 1) 删除aof文件中无用的命令,del,hdel、srem
- 2) redis中已经过期的数据不会写入文件
- 3) 多条命令合并成一条,以64个元素作为分界线
- 随着日志越写越多,文件越来越大redis引用了重写机制,解决问题,重写的文件为什么变小?
-
触发重写分为两种方式
- 手动触发:
bgrewriteaof
-
手动触发工作流程
- 1) 父进程检测是否由子进程进行操作,如果没有创建子进程,如果有,不做任何操作
-
2) 父进程通过fork操作创建子进程,所有开销等同于bgsave
- 3) fork操作之后,父进程可以继续等待命令,所有修改根据aof的策略继续想硬盘同步,偶遇拥有写实复制技术,子进程共享父进程的物理内存,redis使用aof重写缓冲区保存新数据,方式aof文件生成时 数据丢失
-
4) 子进程生成新的aof文件,写入到硬盘中替换掉旧aof文件
- 5) aof完成之后,子进程告知父进程任务完成,父进程更新信息
- 6) 父进程将aof重写缓冲区的文件写入到新的aof文件中
- 7) 再次替换老的aof文件,完成重写
-
写实复制(copy-on-write)
- COW, 父进程和子进程共享页面而不是子进程复制页面, 之哟啊页面共享则不能修改,如果此时做出修改,会产生一个错误,内核将会把页面复制到新的页面中,并且进行标记为可写,原来的页面依然不可写,当其他程序试图修改时,内核检查执行写进程的页面是否是唯一属主,如果是,将标记该页面可写
-
自动触发
- auto-aof-rewrite-percentage 100 当前aof文件和上一次重写过后的aof文件的比值
- auto-aof-rewrite-min-size 64mb 重写过后的aof文件最小体积