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

时间 2020-09-30

标签深刻了解 redis 持久原理栏目 Redis 繁體版

原文原文链接

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

1、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秒钟。

2、AOF

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

记录除了查询之外的全部变动数据库状态的指令异步
以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以后，带来了新的持久化选项——混合持久化。

3、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 是很好的选择。