Redis 持久化

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个元素作为分界线

• 触发重写分为两种方式

  • 手动触发：

  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文件最小体积