redis的持久化RDB、AOF、RDB&AOF混合使用

---

前言

redis作为内存数据库，存在断电数据丢失的问题，所以redis有两种技术实现来保证数据的完整性。rdb和aof。分别代表内存数据库两种思路，全量快照保存和日志形式保存。

一、RDB

学习rdb最权威的方式就是去看他的redis.conf配置文件，里面有很多详细说明

rdb是全量保存当前时刻内存数据到磁盘。
从文档的描述可以看出，rdb保存的周期是根据这个公式来的
save
在多少时间内，key变化了多少次
就比如上面的三个配置，可以得出，
redis在60秒内变化了10000次则触发rdb写进磁盘
或者redis在300秒内key变化了10次
再或者redis在900秒内key变化了1次写磁盘

这里其实有个问题存在的
假设晚上12点redis需要将rdb文件写到磁盘，那么我们知道写磁盘涉及到IO，那么redis是不是会阻塞？
答案是，redis肯定不会阻塞，因为一旦阻塞，就会影响redis的使用。那么redis是怎么做的呢？
答案是，redis在这里通过linux的系统调用接口fork出一个子进程。fork为什么可以实现？
理由是fork的话，那么在内存中会消耗极少的空间来存储redis中对应key的引用指针，然后fork底层利用copy-on-write写时复制的方式实现高效。写时复制相当于java的copyonwriteList的原理，当你需要在redis主进程操作key的时候，在内存中会复制一份原来value值，然后把redis主进程的key的引用指针改写到这个新的内存空间，这样就不影响到fork出来的进程。写时复制是在大量工程中验证过得，因为很少发生大量对原来进程所有的引用重写更改的情况。所以fork的效率非常高。

但是如果单纯使用rdb，可以想象得到，在我进行rdb文件写磁盘的时候，同时用户对redis有key的操作的话，那这些数据就会丢失。要解决这个问题，就需要aof了。

二、AOF

通过aof的描述，可以知道aof相比rdb对于数据完整性更好
aof是实时记录用户对key的新增，修改，删除操作，然后将这些操作日志写在和rdb相同目录下的appendonly.aof文件中。
aof有三种方式写入磁盘aof文件中，分别是

#这是最安全的方式，用户每次对key的更改操作，redis都会调用linux内核直接flush到磁盘中，这种模式丢失数据最少，丢失一条数据
# appendfsync always

#redis会把数据先发送都linux内核缓存起来，时间每间隔一秒调用系统的flush写到磁盘，这种模式丢失数据中等，一秒的数据，小于一个缓冲区的大小
appendfsync everysec

#redis不管linux内核什么时候将数据flush 到磁盘，只要linux内核的数据缓存满了，linux内核会flush，这种模式丢失数据最多，最多一个缓冲区
# appendfsync no

aof还存在一个问题，如果持续往磁盘中aof文件中写入日志记录，随着时间增长，aof的文件也就变得巨大
为解决这个问题，redis有个重写的机制。
什么是重写？
就是将aof文件中，可以抵消的指令抵消掉，只留下精简的指令来就可以恢复当前内存中数据。举例，比如set k1 xx 然后set k1 yy。那么redis重写之后在aof文件中只会留下set k1 yy这个指令，因为前面的操作对于恢复当前内存数据没有帮助。
怎么样重写？
Redis提供两种方式重写，第一种是认为在redis客户端执行

127.0.0.1:6379> BGREWRITEAOF

第二种是通过redis自动的方式进行重写。

百分比100，是指redis会记录上次重写的aof文件的大小，当aof文件的大于等于上次重写文件大小的100%（可以改）同时重写时候文件的大小最少是64M（可以改），防止重写的aof文件偏小而频繁进行重写。

听起来，aof比rdb更好点，实际上，在redis4之前使用的是aof。即使你开启rdb也不生效。
但redis4之后就使用rdb和aof混合的方式。rdb负载在某个时刻把内存整个数据dump到磁盘中，aof记录redis从dump开始，对redis key的更改操作。一句话rdb全量，aof增量。
在数据进行重写的时候，redis会把rdb文件先进行重写进aof文件，然后把剩下的aof文件追加到重写的aof文件后面

总结

redis4之前使用aof的方式，会产生一个问题，就是aof重写的时间过长。恢复较慢
redis5之后使用rdb和aof的方式，重写的时候先把rdb文件先重写，然后把aof文件追加到重写的文件中，速度较快