Redis持久化

 

 

在 Redis 中存在两种方式的备份 ：

　　RDB 快照(snapshotting), 是备份当前瞬间 Redis在内存中的数据记录。Redis的默认方式。采用RDB持久化时服务器只会保存一个RDB文件,方便维护。

　　

　　触发机制-三种方式

• save（同步）

1. 发送执行一条save命令，自动生成RDB文件

2. 对数据进行完整的备份，对其他的客户端造成阻塞作用

3. 存储策略创建一个临时的新的备份文件，完全备份后替换新的老的备份文件

4. 因为是完全备份所以复杂度为O(N)

　　

• bgsave（异步）

　　

• 自动

1. 自动不是一种很好的方式

2. 无法提前预知将要到来的访问量

3. 频繁的读写磁盘对磁盘造成很大的压力

4. 策略的定制尤为重要

　　

　　触发机制-不可忽视的方式

• 全量复制（主从，主自动生成RDB文件）

• debug reload（不清空数据重启）

• shutdown（RDB文件的生成）

　　RDB存在的问题

• 耗时、耗性能

　　

1. O(n)数据：耗时
2. fork（），消耗内存，copy-on-write策略
3. DISK I/O：I/O性能的消耗

• 不可控、丢失数据

　　

RDB总结

• 在进行大规模的数据恢复的时候选择，RDB性能比AOF要好

• 1.RDB是Redis内存到硬盘的快照，用于持久化

• 2.save通常会阻塞Redis

• 3.bgsave不会阻塞Redis，但是会fork新的进程占用内存

• 4.save自动配置满足任意一个结果就会执行

• 5.对于触发机制需要注意

　　AOF 只追加文件（ Append-Only File , AOF ） ， 其作用就是当 Redis执行写命令后，在一定的条件下将执行过的写命令依次保存在 Redis 的文件中 ， 将来就可以依次执行那些保存的命令恢复 Redis 的数据。

　　对于RDB 快照备份而言， 如果当前 Redis 的数据量大，备份可能造成 Redis 卡顿，但是恢复重启是 比较快速的

　　对于 AOF 备份而言，只是追加写入命令，所以备份一般不会造成 Redis 卡顿 ， 但是恢复重启要执行更多 的命令,备份文件可能也很大 ， 这是要注意的地方

　　在 Redis 中允许使用其中的一种、同时使用两种，或者两种都不用，所以具体使用何种方式进行备份和持久化是用户可以通过配置决定的

################################ SNAPSHOTTING  ################################

save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbchecksum yes
dbfilename dump.rdb

############################## APPEND ONLY MODE ##############################
appendonly no
appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec
# appendfsync no ..
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes

　　RDB 快照的原理及配置

　　RDB 快照原理：redis主进程fork一个子进程，fork出来的子进程将内存的数据集dump到临时的RDB中，当子进程对临时的RDB文件写入完毕，redis用新的RDB文件代替旧的RDB文件。

save 900 1
save 300 10
save 60 10000

　　这 3 个配置项的含义分别为 ：

　　当 900 秒执行 1 个写命令时，启用快照备份。
　　当 300 秒执行 10 个写命令时，启用快照备份 。
　　当 60 秒内执行 10000 个写命令时，启用快照备份。
　　配置的意思是，当重启服务器时数据是可能会丢失的，如果数据量小的时候，你会丢失5分钟以内的数据；如果数据量大的时候，你会丢失一分钟以内的数据。如果想避免这种情况发生，那么可以save后重启服务器。一般都是应对突发状况，所以手工执行是比较鸡肋的做法。

stop-writes-on-bgsave-error yes

　　Redis 执行 save 命令的时候，将禁止写入命令。

　　bgsave 命令，是一个异步保存命令，也就是系统将启动另外一条进程，
　　把 Redis 的数据保存到对应的数据文件中 。它和 save 命令最大的不同是它不会阻塞客户端的写入，也就是在执行 bgsave 的时候，允许客户端继续读／写 redis。

　　在默认情况下，如国Redis 执行 bgsave 失败后， Redis 将停止接受写操作，这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘 ， 否则就会没人注意到灾难的发生，如果后台保存进程重新启动工作， Redis 也将自动允许写操作。然而如果安装了靠谱的监控，可能不希望 Redis 这样做，那么你可以将其修改为 no 。

rdbchecksum yes

　　是否对 rbd 文件进行检验，如果是将对 rdb 文件检验。从 dbfilename的配置可以知道， rdb 文件实际是 Redis 持久化的数据文件 

dbfilename dump.rdb

　　是数据文件。当采用快照模式备份（持久化）时， Redis 将使用它保存数据，将来可以使用它恢复数据

AOF追加文件的配置

appendonly no

　　如果 appendonly 配置为 no，则不启用 AOF 方式进行备份。如果 appendonly 配置为 yes,则以 AOF 方式备份 Redis 数据，那么 Redis 会按照配置，在特定的时候执行追加命令，用以备份数据。

appendfilename "appendonly.aof"

　　定义追加 的写入文件为 appendonly.aof， 采用 AOF 追加文件备份的时候命令都会写到这里

# appendfsync always
appendfsyn everysec
# appendfsync no

　　AOF 文件和 Redis 命令是同步频率的 ， 假设配置为 always ， 其含义为当 Red is 执行命令的时候，则 同时同步到 AOF 文件 ， 这样会使得 Redis 同步刷新 AOF 文件， 造成缓慢。

　　采用 no 的时候，则 由客户端调用命令执行备份， Redis 本身不备份文件。
　　对于采用 always 配置的时候 ， 每次命令都会持久化，好处在于安全，坏处在于每次都持久化性能较差。采用 everysec 则每秒同步 ， 安全性不如 always ， 备份可能会丢失1秒 以内的命令 ， 但是隐患也不大 ， 安全度 尚可，性能可以得到保障。采用 no ， 则性能有所保障 ， 但是由于失去备份， 安全性比较差。建议采用默认配置everysec ， 在保证性能的同时，也在一定程度上保证安全性。

no-appendfsync-on-rewrite no

　　是否在后台 AOF 文件 rewrite （重写）期间调用 fsync ， 默认为 no ， 表示要调用fsync （无论后台是否有子进程在刷盘）。 Redis 在后台写 RDB 文件或重写 AOF 文件期间会存在大量磁盘I/O ， 此时， 在某些 Linux 系统中 ，调用 fsync 可能会阻塞。

auto-aof-rewrite-percentage 100

　　Redis 重写 AOF 文件的条件 ， 默认为 100，表示与上次 rewrite 的 AOF 文件大小相比，当前 AOF 文件增长量超过上次 AOF 文件大小的 100%时，就会触发 backgroundrewrite 。若配置为 0 ， 则会禁用自动 rewrite 

auto-aof-rewrite-min-size 64mb

　　指定触发 rewrite 的 AOF 文件大小 。若 AOF 文件小于该值，即使当前文件的增量比例达到 auto-aof-rewrite-percentage 的配置值，也不会触发自动 rewrite 。即这两个配置项同时满足时，才会触发 rewrite.

aof-load-truncated yes

　　Redis 在恢复时会忽略最后一条可能存在问题的指令 ， 默认为 yes 。 即在 AOF 写入时，可能存在指令写错的问题（突然断电、写了一半） ， 这种情况下 yes 会 log 并继续，而 no会直接恢复失败 。

 　　

　　重写的作用

• 减少硬盘占用量

• 加速恢复速度

• 通俗：将过期的没用的可以合并优化的空的，化减成一个简单的AOF文件

　　AOF重写实现的两种方式

• bgrewriteaof -> 类似bgsave：调用fork()子进程完成AOF重写的过程，类似RDB

　　　

　　

　　自动触发机制 -> 同时满足

1. 当前文件尺寸>原来的文件尺寸
2. (当前的文件尺寸-上一次文件尺寸)/上一次尺寸>设置的增长率

　　

　　RDB与AOF的对比

　　

　　两个的参考策略

• 小分片：max_mem最大内存设置一个量一般都是4G，产生小的开销。

• 缓存或是存储

• 监控（硬盘、内存、负载、网络）

• 足够大的内存

参考：

原文：https://blog.csdn.net/yangshangwei/article/details/82889828