Redis持久化策略（RDB\AOF）

RDB

将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb，而在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。

1、配置：

# 900s内至少达到一条写命令
save 900 1
# 300s内至少达至10条写命令
save 300 10
# 60s内至少达到10000条写命令
save 60 10000
# 是否压缩rdb文件
rdbcompression yes
# rdb文件的名称
dbfilename redis-6379.rdb
# rdb文件保存目录
dir ~/redis/

2、自动快照：

执行流程：

（1）Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；

（2）父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中

的临时文件RDB；

（3）当子进程写入完所有数据后会用该临时文件RDB替换旧的RDB文件，至此一次快照操作完

成。

3、手动快照：

save命令：由主进程进行快照操作，会阻塞住其他请求

bgsave命令：通过fork子进程进行快照操作。

4、RDB的几个优点

1. 与AOF方式相比，通过rdb文件恢复数据比较快。
2. rdb文件非常紧凑，适合于数据备份。
3. 通过RDB进行数据备，由于使用子进程生成，所以对Redis服务器性能影响较小。

5、RDB的几个缺点

1. 如果服务器宕机的话，采用RDB的方式会造成某个时段内数据的丢失，比如我们设置10分钟同步一次或5分钟达到1000次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。
2. 使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求。
3. 使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存。

AOF

AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以Redis协议追加保存到appendonly.aof文件末尾，Redis 重启会通过执行文件中保存的写命令在内存中重建整个数据库的内容，以达到恢复数据的目的。

1、配置

# 开启aof机制
appendonly yes
# aof文件名
appendfilename "appendonly.aof"
# 写入策略
appendfsync everysec
# appendfsync always	表示每个写操作都保存到aof文件中，不丢失数据，慢
# appendfsync everysec	每秒写入一次aof文件,最多可能会丢失1s的数据。
# appendfsync no		由操作系统来处理什么时候写入aof文件，最不安全，不推荐
# 保存目录
dir ~/redis/
# 重写aof文件
no-appendfsync-on-rewrite no	# 默认不重写，一般使用命令bgrewriteaof主动重写追加aof文件
auto-aof-rewrite-percentage 100	# 目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之100时会再次进行重写
auto-aof-rewrite-min-size 64mb  # 小于64mb时不会进行重写

2、aof文件重写

每次appendfsync后，文件就会越来越大，所以需要文件重写来压缩aof文件

3、aof文件损坏

服务器宕机时，aof文件会出现格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。

1. 备份现在aof文件，以防万一。

2. 使用redis-check-aof命令修复aof文件，该命令格式如下：

    redis-check-aof -fix appendonly.aof
   

4、优点：

• 数据安全性更高，AOF持久化可以配置appendfsync属性
• 通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof工具解决数据一致性问题。
• AOF机制的rewrite模式。

5、缺点：

• AOF文件比RDB文件大，且恢复速度慢；
• 数据集大的时候，比RDB启动效率低。
• 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。

rdb、aof混用

AOF重写日志时会将RDB持久化的内容写到AOF文件开头，于是在Redis重启时，可以先加载RDB的内容，再对增量的AOF日志进行重放，提升Redis重启的效率。