redis超详细篇5 redis持久化（RDB、AOF）

上一篇我们讲解了redis的事务相关知识，本篇带领大家了解系redis持久化

开篇

官网上讲了两种redis持久化方式
https://redis.io/topics/persistence#snapshotting

用的最多的也是RDB和AOP,其中AOF也是面试中常问的redis知识之一。

下面一一讲解下RDB以及AOF以及相关的区别

RDB

RDB全称：RedisDataBase
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是snapshot快照，它恢复时是将快照文件直接写到磁盘内
简单讲解下什么意思：比如说我们指定每10秒刷新下数据，redis内存每10秒将数据同步到一个临时区域，然后把临时区域的数据覆盖到dump.rdb文件。

你可能会问：为什么不直接同步到dump.rdb而要经过临时区域呢？
原因：如果直接同步没有经过处理，如果出现服务挂断等异常操作，整个数据会全部丢失

rdb优势

1.适合大规模的数据恢复
2.对数据完整性和一致性要求不高时更实用
3.节省磁盘空间
4.恢复速度更快

rdb劣势

1.fork的时候，内存中的数据被克隆了一份，大于2倍的膨胀率需要考虑
2.虽然redis在fork时使用了写时拷贝技术，但是如果数据庞大时，还是比较耗性能
3.在备份周期每隔一定时间做一次备份，如果redis意外宕机，会丢失最后一次快照的所有修改（这个好理解吧，就是每次都会备份，如果本次出意外，那么本次的数据就每次，上次的数据还存在。这也是为啥不直接使用同步的原因，有利有弊吧）

rdb的配置使用

既然讲到rdb的好处和坏处，那我们怎么使用rdb做数据持久化呢？
当然是修改配置文件：redis.conf
下面我们来认识下rdb比较重要的几个配置

dbfilename dump.rdb
在redis.conf文件中，我们可以看到rdb默认写入的是dump.rdb文件，存放在redis的同一级目录下

stop-writes-on-bgsave-error yes
这个命令表示：当redis无法写入磁盘时，直接关闭redis的写操作，我们推荐使用yes

rdbcompression yes
这个命令表示：对于存储到磁盘的快照，可以设置是否进行压缩存储，如果是的化，redis会采用LZF算法进行压缩，这个压缩比较消耗CPU，不过我们推荐使用yes

rdbchecksum yes
这个命令表示：检查数据完整性，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但这样做会增加大约10%的性能消耗，但是我们还是推荐使用yes

dump.rdb文件默认生成在redis的同一级目录，当然也可以在redis.conf中修改他的路径，不过我们还是用默认的吧，以下截图为效果

AOF

AOF全称：append of file，字面意思就是添加到文件
解释：以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容，将写指令从前到后执行一次来完成数据的恢复工作；

同样AOF的设置也是在redis.conf中

AOF配置

appendonly yes、
在配置中，AOF默认是不开启的，appendonly no，我们需要将他开启设置为yes

appendfilename "appendonly.aof"
aof生成的文件默认为appendonly.aof，不需要修改它，生成的目录也是redis的同一级目录下

AOF同步频率设置

appendfsync always
始终同步，每次redis的写入都会立刻计入日志，性能较差但数据完整性比较好
appendfsync everysec
每秒同步，每秒记录日志一次，如果宕机本秒的数据可能丢失
appendfsync no
redis不主动进行同步，把同步时机交给操作系统
具体用哪个，你要根据实际需求进行设置，我们redis.conf默认是：appendfsync everysec

设置完redis.conf之后，我们需要重启下配置才能生效,重载步骤
1.关闭redis进程
可以用ps -ef | grep redis 查看有多少进程，然后kill -9 进程号 删除
2.重载配置文件
redis-server redis.conf
3.重启redis
systemctrl restart redis

这时候查看redis目录，就可以看到生成了aof文件了

AOF持久化流程

1.客户端请求的命令会被append追加到AOF缓冲区内
2.AOF缓冲区根据AOF持久化策略【always、everysec、no】将操作同步到磁盘的AOF文件中
3.AOF文件大小超过重写策略或手动重写时，回对AOF文件rewrite重写，压缩文件容量

这边扩展下rewrite的一些小知识
Rewrite压缩
是什么：
AOF采用文件追加方式，文件会越来越大，为避免出现这种情况，新增了重写机制，当AOF文件的大小超过了所设定的阈值时，redis就会启动AOF的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
重写远离，如何实现重写
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename）,redis4.0版本后的重写是指 把rdb的快照，以二进制的形式附加新的aof头部，作为已有的历史数据，替换掉原来的流水账操作

到这可能小伙伴们又有问题了，既然提供了两种持久化，如果我们两个都选，最终redis到底采用哪个？

如果RDB和AOF同时开启，默认是读取AOF的数据（数据不会存在丢失）

RDB和AOF哪个好？

官方推荐两个都启用

如果对数据不敏感，可以选单独用RDB
不建议单独用AOF,因为可能会出现bug
如果只是做纯内存缓存，可以都不用

下一篇我们唠唠：redis主从相关知识