【Redis-Series】二、Redis的两种持久化机制RDB/AOF

Redis的两种持久化机制RDB/AOF

前言：众所周知，redis是一种把数据存储在内存中的一种nosql数据库，读写速度远远超过Mysql、Oracle等关系型数据库，但是一旦我们的redis数据库节点的服务器宕机，那么也会面临缓存数据丢失的问题。本文就是介绍一下解决方案，那就是对redis的数据进行持久化，Redis的持久化机制有两种：RDB和AOF

RDB: 每隔一段时间，把内存中的数据写入磁盘的临时文件dump.rdb，作为快照，恢复的时候把快照文件读进内存。

优势：

• 每隔一段时间备份，全量备份；
• 灾备简单，可以远程传输；
• 子进程备份的时候，主进程不会有任何io操作（不会有写入修改或删除），保证备份数据的的完整性；
• 相对AOF来说，当有更大文件的时候可以快速重启恢复。

劣势：

• 发生故障时，有可能会丢失最后一次的备份数据；
• 子进程所占用的内存比会和父进程一模一样，如会造成CPU负担；
• 由于定时全量备份是重量级操作，所以对于实时备份，就无法处理了。

AOF： 以日志的形式来记录用户请求的写操作。读操作不会记录，因为写操作才会存存储。 文件以追加的形式而不是修改的形式。redis的aof恢复其实就是把追加的文件从开始到结尾读取执行写操作。同时，如果用户不小心误操作了 flushall 命令，aof文件也会记录。

优势：

• AOF更加耐用，可以以秒级别为单位备份，如果发生问题，也只会丢失最后一秒的数据，大大增加了可靠性和数据完整性；
• 以log日志形式追加，如果磁盘满了，会执行 redis-check-aof 工具；
• 当数据太大的时候，redis可以在后台自动重写aof。当redis继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客户端操作；
• AOF 日志包含的所有写操作，会更加便于redis的解析恢复。。

劣势：

• 相同的数据，同一份数据，AOF比RDB大；
• 针对不同的同步机制，AOF会比RDB慢，因为AOF每秒都会备份做写操作，这样相对与RDB来说就略低；
• AOF发生过bug，就是数据恢复的时候数据不完整，这样显得AOF会比较脆弱，容易出现bug，因为AOF没有RDB那么简单,每次Redis重写AOF时，都会从数据集中包含的实际数据开始从头开始重新创建AOF，与始终附加AOF文件（或重写为读取旧AOF而不是读取内存中的数据）相比，提高了对错误的抵抗力。

上面介绍了一下两种持久化机制，其实redis本身默认为我们开启了rdb持久化机制，而aof需要手动开启，RDB和AOF同时开启的情况下，会只加载AOF。
下面介绍一下两种方式的配置文件的内容：
打开redis.conf文件进行查看和配置，我放在了/usr/local/redis/路径下
RDB配置文件内容:

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#   save <seconds> <changes> 
#   after 900 sec (15 min) if at least 1 key changed
#   当键值发生一次更改会在15分钟后进行保存
#   after 300 sec (5 min) if at least 10 keys changed
#   当键值发生十次更改会在5分钟后进行保存
#   after 60 sec if at least 10000 keys changed
#   当键值发生1W次更改会在1分钟后进行保存
#   当然了也可以根据自己的业务需求去配置，比如说发生2次更改在3s后进行保存
#	例子：save 3 2
save 900 1
save 300 10
save 60 10000

#当保存失败的时候，停止写操作，设为yes可以保证数据的一致性。
stop-writes-on-bgsave-error yes

# no/yes对临时文件进行压缩，设为yes会消耗一些CUP
rdbcompression yes

#自从5版本以后，Rdb会有一个CRC64的校验，无论是在保存还是加载RDB文件的时候。
rdbchecksum yes

# rdb的文件名称，默认dump.rdb
dbfilename dump.rdb

# rdb文件存储的位置
dir /usr/local/redis/working

AOF配置文件内容:

############################## APPEND ONLY MODE ###############################

#Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，
#每次启动时#Redis都会先把这个文件的数据读入内存里，
#先忽略RDB文件。若开启rdb则将no改为yes
appendonly yes

# aof文件名称
appendfilename "appendonly.aof"

#aof持久化策略
# always，客户端每次的写操作都会被记录
# appendfsync always
# everysec，每秒记录一次写操作
appendfsync everysec
#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快
# appendfsync no

#重写的时候是否同步，设置为no则是为不同步，可以保证数据的一致性，
#设置为yes就是在重写的时候进行同步，可能会导致数据的不一致。
no-appendfsync-on-rewrite no

#aof自动重写配置。下面两个条件要同时满足才会执行重写操作
#100为百分比，就是如果当前的aof达到上次重写后的aof文件的一倍（比如上次是1G，则这个文件要达到2G），
#并且文件大小达到64mb才会进行重写操作。如果没有进行过重写操作,
#则使用默认初始化的大小作为上次aof文件的大小。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

#如果选择的是yes，当截断的aof文件被导入的时候，
#会自动发布一个log给客户端然后load。如果是#no，
#用户必须手动redis-check-aof修复AOF文件才可以
aof-load-truncated yes

#加载redis时，可以识别AOF文件以“redis”开头。
#字符串并加载带前缀的RDB文件，然后继续加载AOF尾巴
aof-use-rdb-preamble yes

那么该如何选择两个持久化策略呢？
官方文档给出的解释是：
如果业务系统不是很关心缓存数据的完整性，那么只使用RDB模式是完全OK的，如果你关心缓存数据的完整性，就要开启AOF模式，并且结合RDB模式一起使用，因为官方不建议只使用AOF模式。
当然了，官方解释说，将来可能会把两种持久化策略机制进行融合，大家一起期待吧！

本篇文章到此结束，以后陆续还会发布哨兵机制，redis集群，redis缓存击穿redis缓存穿透等博客。
【Redis-Series】:
一、Linux生产环境安装部署Redis
三、Redis的主从复制原理以及实现（图文详解）
四、Redis哨兵模式讲解及SpringBoot配置（图文详解）
五、Redis-Cluster集群模式讲解及SpringBoot配置（图文详解）
六、Redis击穿、穿透、雪崩讲解以及解决方案