深入了解Redis(6)-持久化原理

　　Redis是一个内存数据库，数据保存在内存中。但我们都知道存储在内存中的数据会因为外部因素而丢失，所以Redis会把数据持久化到磁盘中，至于是如何持久化呢？

一、RDB

1.手动触发

  • save：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。
  • bgsave：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

2.自动触发

  • 根据redis.conf配置里的save m n定时触发（用的是BGSAVE）

  • 主从复制时，主节点自动触发

  • 执行Debug Relaod

  • 执行Shutdown且没有开启AOF持久化

# 在几秒内改动了多少数据就触发持久化
# 想禁用的话不设置save   或者save ""
save 900 1
save 300 10
save 60 10000
# 备份进程出错主进程停止写入操作
stop-writes-on-bgsave-error yes
# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu更值钱
rdbcompression yes

3.优缺点

优点：

  • 只会生成一个文件，方便操作，文件小
  • 相对AOF来说，恢复大数据集的速度快
  • 在RDB持久化开始时，只会fork一个子线程处理所有的持久化工作，不会影响到父系线程

缺点：

  • 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
  • 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

二、AOF

　　全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

  • 记录除了查询以外的所有变更数据库状态的指令

  • 以append的形式追加保存到AOF文件中（增量）

  • 日志重写解决AOF文件不断增大的问题，原理如下

    • 调用fork，创建一个子进程

    • 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件

    • 主进程持续将新的变动同时写到内存和原来的AOF里

    • 主进程获取子进程重写AOF完成信号，往新AOF同步增量变动

    • 使用新的AOF文件替换掉旧的AOF文件

# 默认关闭若要开启将no改为yes
appendonly no
# append文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# always一旦缓存区内容发生变化就写入AOF文件中
appendfsync always
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 将写入文件的操作交由操作系统决定
appendfsync no
# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。
auto-aof-rewrite-percentage 100
# 当AOF文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb

优点：

  • AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
  • AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
  • AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
  • AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。

缺点：

  • AOF日志文件相对于RDB来说会更大
  • AOF开启后，支持的写QPS会比RDB支持的写QPS低
　　通过对比可以看出单独使用AOF和RDB都存在不少都问题，所以在redis4.0之后，带来了新的持久化选项——混合持久化。

三、RDB-AOF混合持久化

　　如果开启了混合持久化，aof在重写时，不再是单纯将内存数据转换为RESP命令写入aof文件，而是将重写这一刻之前的内存做rdb快照处理，并且将rdb快照内容和增量的aof修改内存数据的命令存在一起，都写入新的aof文件，新的aof文件一开始不叫appendonly.aof，等到重写完成后，新的aof文件才会进行改名，原子的覆盖原有的aof文件，完成新旧两个aof文件的替换。
于是在redis重启的时候，可以先加载rdb文件，然后再重放增量的aof日志就可以完全替代之前的aof全量文件重放，因此重启效率大幅得到提高。
　　简单说就是BGSAVE做镜像全量持久化，AOF做增量持久化。
注：图来自网络

如果redis没有升级到4.0，优先选择 RDB 还是 AOF 呢?

分析对比两种方式并做了测试后，发现这是两种不同风格的持久化方式。那么应该如何选择呢?

  • 对于企业级的中大型应用，如果不想牺牲数据完整性但是又希望保持高效率，那么你应该同时使用 RDB 和 AOF 两种方式。
  • 如果你不打算耗费精力在这个地方，只需要保证数据完整性，那么优先考虑使用 AOF 方式。
  • RDB 方式非常适合大规模的数据恢复，如果业务对数据完整性和一致性要求不高，RDB 是很好的选择。

posted on 2020-09-29 15:37  家有四只胖加菲  阅读(814)  评论(0)  编辑  收藏  举报

导航