redis持久化策略

redis提供了两种不同的持久化策略：RDB and AOF

 

1. RDB

1.1 什么是RDB

RDB全称Redis DataBase，是在指定时间间隔内将内存的数据集快照写到磁盘，也就是snapshot快照，它恢复时是将快照文件直接读到内存里

 

1.2 备份是如何进行的

redis 会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO 操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。
 
fork的作用是复制一个与当前进程一样的进程。新的进程所有数据数值都和原进程一样，但是是一个全新的进程，并作为原进程的子进程
在linux操作系统中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，linux中引入了“写时复制技术”
一般情况下父进程和子进程会共用一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制给子进程一份
 

1.3 持久化流程

 

 

1.4 优缺点

优点：

  • 适合大规模数据恢复
  • 对数据完整性和一致性要求不高使用
  • 节省磁盘空间
  • 恢复速度快

缺点：

  • fork时，内存中的数据被克隆了一份，大致两倍的膨胀需要考虑
  • 虽然 Redis 在 fork 时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
  • 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改

 

2. AOF

2.1 什么是AOF

AOF是以日志的形式来记录每个写操作（增量保存），将redis执行过的所有写指令记录下来，只允许追加文件但不可以改写文件，redis重启之后会读取该文件重新构建数据

redis重启之后就是根据日志文件的内容将写指令从头到尾执行一次以完成数据恢复的过程

 

2.2 AOF持久化流程

  • 客户端的请求写命令会被append追加到AOF缓冲区内
  • AOF缓冲区根据AOF持久化策略（always/everysec/no）将操作同步到磁盘的AOF文件中
  • AOF文件大小超过重写策略或者手动重写时，会对AOF文件rewrite，压缩AOF文件容量
  • redis服务重启时，会重新load加载AOF文件中的写操作以达到数据恢复的目的

 

2.3 AOF同步频率设置

  • always：始终同步，每次redis的写入都会被立刻记入日志，性能较差但数据完整性好
  • everysec：每秒同步，每秒记录一次日志，如果宕机，本秒数据可能丢失
  • appendfsync no：redis不主动同步，把同步时机交给操作系统

 

2.4 rewrite压缩

AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof
 
AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写（也是先写临时文件最后再 rename）
redis4.0 版本后的重写，是指上就是把 rdb 的快照，以二级制的形式附在新的 aof 头部，作为已有的历史数据，替换掉原来的流水账操作
 
no-appendfsync-on-rewrite：
  • no-appendfsync-on-rewrite = yes：不写入AOF文件，只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的内存。数据完整性低，但性能高
  • no-appendfsync-on-rewrite = no：还是会把数据刷到磁盘里，但是遇到重写操作，可能会发生阻塞。数据完整性高，但性能降低

 

2.4.1 重写的触发机制

redis会记录上一次重写时的AOF大小，默认配置是AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担，因此设定redis要满足一定的条件才可以触发重写：

  • auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写
  • auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB，达到这个值开始重写

如果redis的AOF当前大小 >= base_size + base_size * auto-aof-rewrite-percentage且当前大小 >= 64MB，redis会对AOF进行重写

 

2.4.2 重写流程

  1. bgrewriteaof触发，判断是否当前有bgsave或者bgrewriteaof在运行，如果有，等待该命令结束后再继续执行
  2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞
  3. 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf缓冲区保证原AOF文件完整性以及新的AOF文件生成期间的新的数据修改动作不会丢失
  4. 子进程写完新的AOF后，向主进程发信号，父进程更新统计信息
  5. 主进程把aof_rewrite_buf中的数据写入到新的AOF文件中
  6. 使用新的AOF文件覆盖原来的AOF文件，完成AOF重写

 

2.5 AOF特点

优势：

  • 备份机制更加稳健，丢失数据概率更低
  • 可读的日志文本，通过操作AOF文件，可以处理误操作

劣势：

  • 比起RDB占用更多磁盘空间
  • 恢复备份速度要慢
  • 每次读写都同步的话，有一定的性能压力
  • 存在个别bug，不能修复

 

3. 总结

  • RDB持久化方式能够在指定的时间间隔内对数据进行快照存储
  • AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF 命令以 redis 协议追加保存每次写的操作到文件末尾
  • redis还能对AOF进行重写，让文件不至于过大
  • 如果你只希望redis做简单的缓存，只在服务器运行的时候存在，可以不做任何持久化操作
  • 建议同时开启两种持久化方式
  • 在同时开启的情况下，当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据,，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整
  • 建议不要只使用AOF，RDB 更适合用于备份数据库

 

posted @ 2022-03-23 12:44  aganippe  阅读(580)  评论(0)  编辑  收藏  举报